[CRISP-TEAM] Draft Notes CRISP 4th Teleconference

Izumi Okutani izumi at nic.ad.jp
Wed Dec 24 02:44:24 CET 2014


Hi German,


Many thanks for the Notes.

I have made a few comments.

Changes are basically :
  - Clarify what we agreed about global PDP and Review Team
  - A couple of agenda items which should belong to 3, 4 and 6 are
    described in 5, so I suggested to move under appropriate agenda

(For future, I'll take a note to clearly state which agenda Item we are 
talking, so it's clear for the record)

Please see the details inline.

Thanks German!

> CRISP 4th  Teleconference held on Thursday December 18th 2014 (13:00 UTC)
> CRISP members present
>
> AFRINIC
> Alan P. Barrett, AB Ernest Byaruhanga, EB
>
> APNIC
> Izumi Okutani, IO Craig Ng, CN
>
> ARIN
> Michael Abejuala, MA John Sweeting, JS
>
> LACNIC
> Esteban Lescano, EL Nico Scheper, NS Andres Piazza, AP
>
> RIPE NCC
> Nurani Nimpuno, NN Paul Rendek, PR
> Draft Agenda for CRISP 4th  Teleconference
> 1. Agenda Review
>
> 2. Actions Review
> -­‐ Suggested text by Michael (global PDP)
> -­‐ Suggested text by Andrei (Review Committee)
>
> 3. Final check on the initial draft
> a) Confirmation on suggested revisions
> b) Considerations for future draft: including who will draft
>
> 4. Preparation for the announcement
> a) Confirm draft announcement
> b) Communications with respective RIR regions
> -­‐ mailing lists: role of RIR mailing lists
> -­‐ any other form of engagement
> 5. How we work to incorporate feedback
>
>
> 6. Reconfirm next steps & schedules
> a) Draft publish time (rough target)
> b) Reconfirm the next call date
>
> 7. AOB
>
> IO opened meeting at 9:02 IO welcomed participants
> IO Lets start with checking CRISP members present in the call.
>
> AB, CN, EB, JS MA, NN, PR and NS were present at the start of the call.
>
> 1. Agenda Review
>
> IO reviewed agenda content.
>
> No other items were added to the agenda.
>
> 2. Actions Review
> -­‐        Suggested text by Michael (global PDP)
> -­‐        Suggested text by Andrei (Review Committee)
>
> IO both actions are done.
>
> IO actual content of the suggested text for Review Committee is Andres no Andrei. IO asked GV to
> show the Michael’s suggested text in the WebEx platform.
> GV displayed section III of the document page 8. IO asked MA to explained the changes.
> MA I tried to incorporate Bill and Alan’s feedback into this language, I’ve taken out the part of
> commitment discussed yesterday all that language came out, I included the language regarding
> inherit conflict that was to reflect the conflict we identified yesterday between ICANN as the IANA
> functions operator, serving the both the role as a provider but also being in the role of ratifying
> body for global policy. My understanding was that we want to make very clear in this proposal we
> are suggesting that an amendment to the ASO MoU be made that would remove ICANN from the ratifying
> role, with other respects the gPDP would remain the same.  Something that I did add because in
> reviewing the ASO MoU, it wouldn’t necessarily become Global Policy upon each the RIR ratifying the
> proposed comment text but the ASO AC which still have to just review the process by which we did so
> and then at that point the proposed policy text would become global policy,  so that what I tried
> to capture on this.
>
>
> IZ thank your for incorporating Bill and Alan comments to the text.

IZ --> IO

IO thank your for incorporating Bill and Alan comments to the text.

> AB (chat) I am comfortable with the new text about removing the ICANN Board’s role in gPDP
> ratification.
>
> IO I think Andrei had some comments on the text
>
> MA I think Andrei’s comments were in regards the original text, I think his concerns are addressed
> in the new text
>
> IO lets confirm with Andrei.
>
> NN I’m not going to try to speak on behalf of Andrei, I agree with the fact that ICANN has a dual
> role is not something new that we just discovered we were very aware of this. I think the concern
> raised here because ICANN has this dual role, which we don’t want to mix policy issue with the IANA
> functions, I think because of that, is important to keep them separate.  The other thing, I’m
> little concern, in fact very concern, are we saying  that the crisp group is proposing an amendment
> to the ASO MoU, if so I’m actually   asking if that is under our mandate, I don’t think that follow
> due process. I have two concerns one is mixing policy into this, which is exactly what we don't
> want to do. My second point is, I’m afraid we are undermining the existing bottom up process within
>   the RIR structure by adding to the CRISP mandate that we are proposing a change to the ASO MoU I
> don’t think is in the scope of this group, I don’t think is in the scope of the document. It
> doesn't mean I don't think the motivation behind putting this text is correct I totally agree with
> the concern that motivate inserting this text but I don't think this is the vehicle for that.  I
> hope that was clear.
>
> IO we should not mix policy with operations. We shouldn’t give the message that the NTIA has any
> kind of involvement or authority over the gPDP. This is very important. The second are we in the
> position to propose changes in the global policy, I can think we are but we have to be very careful
> wording this how we are phrasing to make sure I doesn't sound we try to make changes without using
> the usual processes.

The second, as CRISP Team, are we in the position to propose changes in 
the global policy?  We have to be very careful wording this how we are 
phrasing to make sure I doesn't sound we try to make changes without 
using the usual processes.

> AB yes, I think the CRISP team mandate is to propose changes to the way the RIR interact with the
> IANA operator, and also possible with ICANN so I think suggesting             changes to the
> existing documents is within the scope of what the CRISP can do however we need to be careful that
> changes have consensus from our communities.  We can’t bypass the bottom up process but I think we
> can suggest changes in almost anything.
>
> IO I think this address NN concern of your second point.
>
> NN I’m afraid I disagree. I don't actually think is in our mandate to propose changes on how IANA
> operates. I think we are suppose to define the relationship with the IANA operator, maybe we need
> to have a discussion on those things first because there are principles on what we are trying to
> achieve here. My second point I really don't think is the CRISP group is the correct body or the
> correct channel for changes to the ASO MoU I don’t want to be bureaucratic about things, the reason
> we follow correct process and channels are because we are a bottom-­‐up transparent inclusive
> community, we need to show that in all the way we interact with various bodies. The CRISP group is
> the wrong
>
>
> avenue to do this, I think we are undermining the exact bottom process that we are trying to
> strengthen through this process.
>
> IO firstly I think your question was that do we need to cover gPDP as a part of the CRISP team
> proposal considering the part we have to focus on something related to the IANA functions, that was
> your first point, the second point if I understood it correctly by mentioning about the MoU ASO in
> the document it would seem to imply that the CRISP team is coming up with changes that actually is
> something that we have to change through the usual bottom up process and it’s not the CRISP team to
> make decision over this it would seem we are not actually respecting the bottom process that should
> be developed from the community is that a fair understanding of your point Nurani.
>
> NN As a point clarification, I’m not asking the gPDP being discuss here, I’m trying to make a point
> here on the dual role if ICANN in the gPDP and the IANA operator and that it’s more important to
> separate both things. Otherwise you were more eloquent on what I was trying to say here.
>
> IO we want to separate these roles.

IO I agree we want to seperate these roles.

> IO I have an observation on ICANN having dual role. I’m not sure if it should be considered a
> controversial or conflicting role, in terms of the RIR, the RIR is the same at least in the case of
> APNIC, the policy itself is developed by the community but APNIC EC is the one actually approving
> the final policy, may be different in other regions,  and APNIC yet provide the number resource
> services,  APNIC exchanges contracts with their members that would say APNIC has a dual role.
>
> PR (chat) this is not across the RIR.
>
> IO it may be different depending on the RIR. I supposed the point is worth it.  Anybody has any
> comment or suggestion on addressing this point.

IO Understood it may be different depending on the RIR. Anybody has any 
comment or suggestion on addressing this point.

> CN can I ask a question and maybe offer a possible solution. A question for NN where do you see the
> forum from that discussion would take place, the potential solution is that perhaps we can delay
> the references from this document, addressing this way, this submission is really intended to be
> high level description of SLA I think we all agreed in that, and I think me might focus maybe
> minutia detailed issues that doesn't necessarily have to come out now in this document, one of the
> potential solution could be that there is termination clause in the SLA that says for example if
> ICANN board make a decision related to gPDP in a way is inconsistent with the bottom up,
> transparent  accountable way for example then that give us the right to terminate  the contract
> that is potential solution a way out for us and that doesn't need to be said in the document that
> could came out when we negotiate the contract.
>
> IO that sounds a reasonable solution for me.
>
> JS we could identify that as a possible issue be looked and resolve by the proper channels, we see
> the conflict; we should recommend review it and correct it by the correct process.
>
>
> IO sounds a reasonable possibility.
>
> AB I’d like to correct something I said earlier, I thought we could change almost  anything but I
> re-­‐read the RFP I noticed that in section II it asks about the existing pre transition sources of
> policies that would include ICANN board, but in section III it asks about propose changes is asking
> propose changes only to the oversight mechanisms not to the sources of policies so what I said
> earlier is wrong we should not be changing the way the policy is made perhaps can be done somewhere
> else but I changed my mind whether or not can be done here.
>
> PR In light what NN and AB mentioned I have to say is out of the scope of this group and if you
> feel is something you want to identify from this process I think is smart to go back to your
> communities and identifying there. It should be taken through the community processes.  We are
> looking to the oversight contract not the gPDP. We must remain focus.
>
> IO regarding on JS just raised but when we sent messages to the communities should be worthy
> mention the issues.

IO I would like to confirm about an idea suggested by JS. When we send 
out announcement to the communities, would it be worth mentioning this 
issue.

> PR I’m not comfortable CRISP team making references to this. I think this should be brought forward
> to the communities.  I think this is a much better avenue, I’m not seeing a collective
> recommendation.
 >
> JS (Chat) outside the document works as well and each of us taking it back to our community is one
> way as well.
>
> IO maybe the way is that the document doesn’t include the observations and each of us who feels
> individually push this in your community and not proactively share it as team.

IO May be the way forward it that the document doesn’t include the 
observations about global PDP and each of us who see the need to share 
with the community can do it, when receiving questions related to this 
issue in your community but not proactively share it as CRISP team.

> JS makes sense to me.
>
> MA (chat) then it appears there is consensus that I can take it out of the draft.
>
> IO I think we can remove the whole paragraph and we focus in what affects the IANA functions. We
> are done with this part.

IO I think we can remove the whole paragraph on global PDP and we focus 
in what affects the IANA functions. We are done with this part.

No objections observed on removing the paragraph from Section III on 
global PDP.

> IO lets move to the second revision proposed by Andres.
>
> AP I have seen on the list that Andrei said that some of his concern where not addressed here. I
> proposed Andrei to provide a third version. At the moment I believe we are ok with the paragraph
> included in the document.
>
> NN Andrei’s mail that came in in the list it was not about this paragraph is was about another
> text; may I propose to move to that text? It’s a totally different issue.
>
> AP if you are suggesting moving on, are you ok with the paragraph on the Review Committee.
>
>
> MA (chat) I believe the question is if anyone has objection to the suggested text before we move
> on.
> NN (chat) which part of the text are we talking about?
>
> IO the paragraph that AP refers is second paragraph in page 8.
>
> NN I’m clear now I thought we were going back to the previous topic. NN I think you managed to
> capture the discussion very well we are comfortable with that if LACNIC feels addressing their
> concern we are happy to accept the text.
>
> IO anybody has any comments? CN (chat) I’m happy with it.

No objection observed on text provided by AP about Review Commitee to be 
included in Section III.

> IO I’d like to request MA to add Andrei text on references to the IETF. MA no problem in includes
> them in the next version.

IO Regarding the text suggested by Andrei on overlap with IETF for 
Section I, I’d like to request MA to add Andrei text on references to 
the IETF. This text had been agreed on the CRISP Team mailing list.

MA no problem in includes them in the next version.

> PR It’s important to include references to other bodies. AB Paul already said what I wanted to say.
> IO I think we have support for this.
>
> 3. Final check on the initial draft
> a) Confirmation on suggested revisions

----Move this from 5------
 > IO: Asked for comments about the relationship with the IETF.

IO: Based on the issues listed in 3a) in the agenda circulated (overlap, 
xxxx, xxxx [Please reflect what was circulated]), I'd like to go through 
whether they are all reflected in the draft.

Note: The topics listed are based on comments made on the CRISP Team 
mailing list.

 > AB: Underlined the importance of adding “Reserved or special values 
in the registries”
 >
 > MB: Accepted to do these changes and suggested to circulate the draft 
with suggested comments to
 > the mailing list so the members who are not in the call can send 
their feedback.
----Move this from 5------


> b) Considerations for future draft: including who will draft
>
> Not discussed in the Teleconference.


  Not discussed in the Teleconference. --> Delete

----Move this from 5------

 >
 > IO: Review all the aspects included in part4 “Final check on the 
initial draft” and asked for
 > comments. She asked for volunteers to work sorting the descriptions 
according to order of
 > questions.
 >
 > AB: Suggested to leave this topic to the second draft and suggested 
to clarify in the announcement
 > that there will be future changes.
 >
 > AB, MA and IO volunteered to work on this.

----Move this from 5------


> 4. Preparation for the announcement
> a) Confirm draft announcement
>
> IO: asked if there were any comments in relation to the draft already presented. There were no
> comments.
> IO: Suggested to share it in the global mailing list and asked GV to publish it in the NRO website.
>
>
> b) Communications with respective RIR regions
> -­‐ mailing lists: role of RIR mailing lists
>
>
> -­‐ any other form of engagement
>
>
> IO: Asked the RIRs representatives to forward the announcement to their regional lists

----Move this from 5-----------------

 > IO: Suggested two approaches:
 >
 > 1. CRISP Team look at comments received on the global mailing list 
and make sure that each team
 > member will share the general discussions and all the relevant 
aspects on the lists.
 > 2. Considerer the different RIRs´ mailing lists as well as the global 
mailing list.
 >
 > NN-­‐ She suggested to maintain the discussion on the global mailing 
list. Each region may discuss
 > as well in their own regional mailing lists and then come up all the 
information and comments to
 > the global mailing list. In addition,  all the CRISP team members 
should encourage each community
 > to participate in the global mailing list.
 >
 > JS: Agreed and added that it´s important to encourage people to use 
the official NRO list. “ We
 > should make sure that the feedback from the communities is posted in 
the NRO list”
----Move from 5 -----------------

> 5. How we work to incorporate feedback

  Not discussed in the Teleconference.

> IO: Confirmed that the announcement will be done on 19 December at  4PM UTC And that next call will
> take place on 22 December at 13 UTC.
>
>
> 6. Reconfirm next steps & schedules
> a) Draft publish time (rough target)
> b) Reconfirm the next call date
>
> Not discussed in the teleconference.

  Delete:  Not discussed in the Teleconference.

----Move from 5 -----------------
 > IO: Confirmed that the announcement will be done on 19 December at 
4PM UTC And that next call will
 > take place on 22 December at 13 UTC.

----Move from 5 -----------------

Cheers,
Izumi

(2014/12/23 11:58), German Valdez wrote:
> For your perusal.
>
> Cheers
>
> German
>
>
>
> _______________________________________________
> CRISP mailing list
> CRISP at nro.net
> https://www.nro.net/mailman/listinfo/crisp
>





More information about the CRISP mailing list