Planning for the IANA/NTIA Transition
charter-ietf-ianaplan-01
Yes
(Alissa Cooper)
(Jari Arkko)
No Objection
(Alia Atlas)
(Brian Haberman)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Spencer Dawkins)
(Stephen Farrell)
(Ted Lemon)
Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
Alissa Cooper Former IESG member
Yes
Yes
(for -00-03)
Unknown
Barry Leiba Former IESG member
Yes
Yes
(2014-08-20 for -00-03)
Unknown
I particularly like the changes that went into -03.
Jari Arkko Former IESG member
Yes
Yes
(for -00-00)
Unknown
Kathleen Moriarty Former IESG member
Yes
Yes
(2014-08-20 for -00-03)
Unknown
Thanks for all of the hard work on this. I support Adrian's comments and many of his detailed edits and it looks as though agreement is forming on his suggested changes.
Pete Resnick Former IESG member
Yes
Yes
(2014-08-20 for -00-03)
Unknown
I think this version of the charter is fine to go for external review. The following comment can be held for final approval (and it won't be blocking even then), but if other changes get made during internal review, please consider: In Tasks, the second and third paragraphs ("Given that we have a system today…" through "...may require additional documentation or agreements") seem like a really elaborate and somewhat obfuscated way of saying, "The WG shall not change the status quo". I think this could be simplified to: The document shall describe, either directly or by reference to existing documents, the different responsibilities and oversight roles of the IAB and IAOC, as well as the direct interactions between the IETF and the protocol parameters registry operator. The WG shall not change the current roles, responsibilities, and interactions in any substantive way. Rather, the WG is documenting the interactions that are not already explicitly called out in existing IETF documents, but which now need to be documented due to the elimination of the NTIA-ICANN contract. The WG may refer to the following documents, which will be presumed to continue to be in effect: [List of documents] That said, if the sponsoring AD and/or potential chairs think the more elaborate version is better (either because it gives more or less flexibility; I can't tell which it is), I certainly won't stand in the way. The current text is workable.
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-08-20 for -00-03)
Unknown
[updated to reflect a discussion with Pete about a paragraph he had written] I probably have no objection to this document going out for community review, but I think it is a shame that the current revision has had no discussion on the mailing list created to discuss the topic despite being very substantially different from the version previously posted there. Given the volume of my comments below, I suspect that reaching some form of stability in the text and getting buy-in from the majority of interested parties would be a good idea before embarking on the one week formal review. --- OLD The IETF stores parameters for protocols it defines in registries. These registries are maintained by the Internet Assigned Numbers Authority (IANA), and are the subject of the "IANA Considerations" section in many RFCs. NEW Regestries of parameter values for use in IETF protocols are stored and maintainted for the IETF by the Internet Assigned Numbers Authority (IANA), and are the subject of the "IANA Considerations" section in many RFCs. COMMENT Just trying to align the words. END OLD For a number of years, the IANA function has been provided by the Internet Corporation for Assigned Names and Numbers (ICANN). The IETF's relationship with IANA was formalized through a Memorandum of Understanding codified in 2000 with the publication of RFC 2860; over time processes and role definitions have evolved, and have been documented in supplemental agreements. NEW For a number of years, the IANA function has been provided by the Internet Corporation for Assigned Names and Numbers (ICANN). The IETF's relationship with IANA was formalized through a Memorandum of Understanding between the IETF and ICANN codified in 2000 with the publication of RFC 2860. Over time, processes and role definitions have evolved, and have been documented in supplemental agreements. COMMENT Useful to know between who the MoU was formed. Fixed some English. However: what is "the IANA function" referred to here? I think it is more that the maintenance of protocol regestries for the IETF described in the previous paragraph. END OLD ICANN has historically had a contract with the US Department of Commerce (DoC), undertaken through the National Telecommunications and Information Administration (NTIA). In March of 2014, NTIA announced its intention to complete the evolution begun in 1997, meaning that NTIA would not need to renew its contract with ICANN when that contract expires 30 September 2015. NTIA requested a transition proposal be prepared to outline the necessary arrangements. In the case of the IETF, we expect these arrangements to consist largely of the existing well-documented practices. COMMENT "Historically" implies in "the past". Using the Present Perfect Continuous ("has had") both indicates history and currency. Having a contract is one thing, saying what it was for may also be valuable ""... to provide the IANA function." "Complete the evolution begun in 1997" may be useful to someone, but not me! Either explain that evolution or don't mention it. I think that it is not necessary to mention it. On the other hand "evolution" and "transition" have no meaning without some context. "would not need to" is very ambiguous! Maybe it can't be avoided, but it isn't good. "A transition proposal" surely contains a proposal for transition, not the existing well-documented practices. Maybe, "In the case of the elements of the IANA function concerning the IETF protocol registries, it is likely that the existing well-documented practices will continue and no or little transition activity will be required." END OLD Tasks ===== The WG’s output is expected to be an IETF consensus document which describes the expected interaction between the IETF and the protocol parameters registries operator. COMMENT We have to recall that IANA maintains registries for other protocols and that ICANN has been adamant that it is allowed to do that. So we need to be clear we are not on that turf. Also, at this stage, we should not be "expecting" output. We should be saying what the WG is chartered to do. NEW Tasks ===== The IANAPLAN working group is chartered to produce an IETF consensus document that describes the expected interaction between the IETF and the operator of the registries that contain the protocol parameters for the IETF protocols. END OLD Given that we have a system today that works well for the IETF, minimal change in the oversight of the protocol parameters registries is preferred in all cases and no change is preferred when possible. With a view to addressing implications of moving the NTIA out of its current role with respect to IANA on the IETF protocol parameter registry function, the WG will focus on documenting and ensuring the continuation of the current arrangements. The working group will assume the following documents continue to be in effect: COMMENT "works well *for*the*IETF*" is likely to raise eyebrows. For whom does it not work well? Why doesn't the IETF care? I think we can just say that it works well. Do we need the passive voice? And maybe we don't need the didactic tone either. The "oversight" that is claimed to exist today is somewhat over- claimed :-( I think part of the trouble is that we might have a different view of what the word means from what the NTIA is thinking. There is: - setting criteria - measuring against criteria - requiring satsifaction of criteria (or enforcing contract) I think that the bit that is transitioning (in the case of protocol registries) is the third of these. We seem to be dodging that, yet that is exactly the bit where we are vulnerable to theft of control. NEW The system in place today for oversight of the IETF protocol registries component of the IANA function works well. The working group will address the implications of moving the NTIA out of its current role with respect to IANA on the IETF protocol parameters registry function in a way that ensures continuation of the current arrangements. The working group will assume the following documents continue to be in effect: END OLD - RFC 2850 (especially section 2(d)) - RFC 3777 and its updates - RFC 2860 - RFC 6220 - IETF-ICANN-MOU_2000 (http://iaoc.ietf.org/documents/IETF-ICANN-MOU_2000.pdf) - ICANN-IETF Supplemental Agreements (updated yearly since 2007, the 2014 version is available at http://iaoc.ietf.org/documents/2014-ICANN-IETF-MoU-Supplemental-Agreement-Executed.pdf) COMMENT Don't do "especially". Either the document is in effect or it is not. I wonder whether this list of documents should be marked as non- exclusive. END OLD This working group is chartered solely with respect to the planning needed for the transition. COMMENT What does this mean? I thought the working group was chartered to produce a document that described "the interaction between the IETF and the protocol parameters registries operator." END OLD Possible improvements outside that scope will be set aside for future consideration. Avoiding alterations in substantive outcomes should be the goal, even if eventual mechanisms required to address the removal of the overarching NTIA contract may require additional documentation or agreements. COMMENT "alterations in substantive outcomes" means what? Google tranlate renders "Changes in the content of the results" via German and "changes will result in significant" via Swahili. I think you are trying to say that the goal is to leave in place as many elements of existing processes and agreements as is possible. Would it be possible to say what the goal actually is? END OLD Should proposals made to the NTIA by other communities regarding the transition of other IANA functions affect the protocol parameter registries or the IETF, the WG will also review and comment on them. NEW Saying that the WG will comment implies that the WG will produce some form of output. I'm not sure what you have in mind. Saying that other proposal might affect the IETF is a very wide scope! You had previously screwed this tight to say the WG was only working on the protocol parameters part. This text opens it up to the full transition discussion. And you need to tighten "protocol parameters registries" to "IETF protocol parameters registries". END OLD The output document of the WG need not be the complete transition proposal regarding the oversight of the protocol parameters registries to be handed to the NTIA. Specifically, if that transition proposal requires documentation of some detailed terms of agreements or other details of procedures that are normally delegated to and handled by the IAB or IAOC, the IAB or IAOC can provide those details as part of the submission; the WG does not need to come to consensus on those parts of the submission. COMMENT But presumably you intend that the WG does come to consensus on the fact that it doesn't need to come to consensus? Possibly the following would work... NEW Some parts of the transition proposal may need to document detailed terms of agreements or other details of procedures that are normally delegated to and handled by the IAB or IAOC. The working group will not attempt to produce or discuss documentation for these details, but will request the IAB or IAOC to provide them ready for submission as part of the final proposal. END OLD The WG shall seek the expertise of the IAB IANA Strategy Program to formulate its output. It is expected that members of the IAB IANA Strategy Program will actively participate in the WG. Milestones ========== January 2015 -- complete protocol parameters registries proposal May 2015 -- review of other transition proposals, if needed Sept 2015 -- close COMMENT I should like to know to whom the WG delivers the complete proposal and in what form. I would also like clarity with regard to how the proposal delivered by the WG is considered complete if additional work from the IAB and IAOC is needed. Does that change the timeline? END
Alia Atlas Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(for -00-03)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(for -00-03)
Unknown