Re: [Ianaplan] Review of draft-ietf-ianaplan-icg-response-01

["Richard Hill" <[e-mail]>]

Many thanks to both Alissa and Eliot for this.

I largely (not not entirely) agree with Alissa's comments, and I almost entirely  agree with Eliot's proposed dispostions.

Here is where I differ from what Eliot has proposed.

Re "We will contintue to coordinate with ICANN regarding those changes", I would propose  "We will continue to coordinate with the IANA functions operator (at present ICANN) regarding those changes", or something along those lines.

Thanks again and best,
Richard
  -----Original Message-----
  From: Ianaplan [mailto:[e-mail]]On Behalf Of Eliot Lear
  Sent: samedi, 25. octobre 2014 08:36
  To: Alissa Cooper; [e-mail]
  Subject: Re: [Ianaplan] Review of draft-ietf-ianaplan-icg-response-01


  Hi Alissa,

  Thanks for your thorough review.  Please see below regarding proposed disposition of your comments.



  On 10/25/14, 1:35 AM, Alissa Cooper wrote:

    All,


    I’ve reviewed draft-ietf-ianaplan-icg-response-01 and my review comments are below. Many thanks to Eliot and others for your work on this.


    Alissa




    === Substantive comments ===


    == Response to Section I:


    "The IETF uses the IANA protocol parameter registries to implement such registries.”


    I don’t understand what the above sentence means.

  Yes, I caught this as well.  My proposal is as follows:


           The IETF uses the IANA
            protocol parameter registries to store this information  in a
            public location.





    =


    "The IANA protocol parameter registry operator maintains the protocol
       parameters registry for the IETF in accordance with all relevant IETF
       policies, in accordance with the Memorandum of Understanding"


    This is the first place where the MoU is mentioned, and it is simply called the MoU, which may not be descriptive enough. I would suggest 


    s/the Memorandum of Understanding/a Memorandum of Understanding established between the IETF and ICANN/


    and adding a citation to the MoU.

  Propose to change as suggested above unless there are objections.




    =


    "The protocol parameter registries are the product of IETF work.”


    This seems like an under-specified answer. For example, the IP address space registries could certainly be considered to be the product of IETF work. But I did not think it was the intent to cover them in this transition plan document. I apologize if there has been discussion of this on the list that I missed, but I feel like the answer to this question is specifically our opportunity to explain exactly what is covered by this particular transition plan, and “the product of IETF work” is a rather vague answer.

  That is covered in the earlier text to which you suggested an edit, and we are attempting to be concise.  The clear point we wish to bring forth, and this has been discussed, is that the protocol parameter registries are really an integral part of IETF standards.




    =


    "We will continue to coordinate with ICANN regarding those changes."


    In all of the bullets listed in this part of the response, I’m curious if we really mean “IANA functions operator” where we are presently using “ICANN."

  In this case, the GNSO, ccNSO, SSAC, and perhaps the ICANN board all may have an interest.  In fact we have a liaison manager who sits on the board for technical advice.




    =


    Why is the recently implemented audit not mentioned in response to the question about a description of the oversight mechanism?

  Happy to include, and would invite proposed text.






    == Response to Section II:


    "IETF Response: all policy sources relating to the protocol parameters registry have been specified in II.A."


    This is not really answering the question posed in the RFP. The question in the RFP is whether there are some policy sources described in answering Section II.A that are not covered by the oversight mechanisms to be described in response to Section II.B. I would suggest:


    “IETF Response: All policy sources relating to the protocol parameters registries are affected.”

  I have no objection to the change.





    == Response to Section III:


    "To address a desire by some members of the IETF community to have
       mechanisms that allow for additional dispute resolution between the
       IETF and the current IANA protocol registries operator, the IAOC is
       asked to conclude a supplemental agreement regarding jurisdiction and
       any necessary dispute resolution mechanisms that are mutually
       acceptable to the parties."


    First, I think the bit about “some members of the community” is unnecessary. This document with either have rough consensus or it won’t. Second, I think the asks to the IAOC should all follow the same standard, which is articulated in the prior paragraph — engaging the relevant parties to make [fill-in-the-blank] happen. So for this sentence, my suggested edit is:


    “The IAOC is asked to engage with the IANA functions operator regarding jurisdiction and
       any necessary dispute resolution mechanisms that are mutually
       acceptable to the parties."


    We should leave it up to the IAOC to decide how to effectuate this.

  I have removed "some members of".



    =


    "To address concerns regarding appropriate contingencies to transition to another operator, IAOC is asked to conclude a supplemental agreement that- 1. captures provisions C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract]; and"


    Similar to my comment above, I think this should align with the other bits about the IAOC, i.e.,


    "To address concerns regarding appropriate contingencies to transition to another operator, the IAOC is asked to engage with the IANA functions operator regarding: 1. maintaining the IANA functions operator's obligations established under provisions C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract]; and”

  I have no problem with the wording change above.



    =


    "requires the transfer of any associated marks and identifiers to a subsequent operator."


    I continue to be against the inclusion of this provision in the transition plan. It implicitly requires there to only ever be one operator in the future, and it is not in the IETF’s interest to force that to be the case. That may have been in NTIA’s interests, but we have different needs from NTIA. 



  Based on what you wrote above I had previously misunderstood your concern.  I propose a small change for this response with the expectation that we will engage others in the process of further developing a consolidated response:

  "requires the transfer of any associated marks and identifiers to subsequent operators."

  Clearly there will need to be additional discussion with the RIRs in particular about iana.org.




    == Response to Section IV:


    "What is necessary as part of transition is the completion of supplemental agreement(s) discussed in the previous section of this RFP.”


    Per my comments above, I don’t think we should specify the form of the output of the IAOC’s work. My suggestion:


    "What is necessary as part of transition is the completion of the IAOC’s engagements discussed in the previous section of this RFP to the satisfaction of the IAOC.”



  I do not believe this is sufficiently clear for our intent to be understood and prefer the original text.



    === Nits ===

  Thanks for catching them.  I've only left in the ones for which there is something to add.



    In general, I think we should use the term “protocol parameters registries” in the plural rather than the singular, and use it consistently throughout the document.


  I've made this change.  Please review in the next version as there were a lot of edits.


    s/No changes are required, as over the years/No changes are required. Over the years/

  This text has changed.

  Eliot