Planning for the IANA/NTIA Transition
charter-ietf-ianaplan-01
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14
|
01 | (System) | Notify list changed from ianaplan@ietf.org, iana-strategy@i1b.org to iana-strategy@i1b.org |
2014-09-08
|
01 | Cindy Morgan | New version available: charter-ietf-ianaplan-01.txt |
2014-09-08
|
00-06 | Cindy Morgan | State changed to Approved from IESG review |
2014-09-08
|
00-06 | Cindy Morgan | IESG has approved the charter |
2014-09-08
|
00-06 | Cindy Morgan | Closed "Approve" ballot |
2014-09-08
|
00-06 | Cindy Morgan | Closed "Ready for external review" ballot |
2014-09-08
|
00-06 | Cindy Morgan | WG action text was changed |
2014-09-06
|
00-06 | Pete Resnick | [Ballot comment] Thanks for addressing my concerns. |
2014-09-06
|
00-06 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to Yes from Abstain |
2014-09-05
|
00-06 | Jari Arkko | New version available: charter-ietf-ianaplan-00-06.txt |
2014-09-05
|
00-05 | Jari Arkko | New version available: charter-ietf-ianaplan-00-05.txt |
2014-09-05
|
00-04 | Jari Arkko | Changed charter milestone "complete protocol parameters registries proposal", set description to "complete protocol parameters registries document" |
2014-09-04
|
00-04 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2014-09-04
|
00-04 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from No Record |
2014-09-04
|
00-04 | Ted Lemon | [Ballot comment] This isn't a strong objection, but I find this text a little unclear: Registries of parameter values for use in IETF protocols … [Ballot comment] This isn't a strong objection, but I find this text a little unclear: Registries 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. For a number of years, maintenance of the IETF protocol parameters registries has been provided by the Internet Corporation for Assigned Names and Numbers (ICANN). I think it would be clearer if the second paragraph started thusly: Registries 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. For a number of years, the IANA function has been provided by the Internet Corporation for Assigned Names and Numbers (ICANN). Otherwise you're repeating information from the first paragraph, and not directly describing the connection between IETF and ICANN. Of course any sensible person will make the connection, hence the weakness of this objection, but I don't think it's necessary to make the reader do this work. Rather than verbing a noun here with "to transition out of", why not say "to relinquish" or "to give up"? 2014, NTIA announced its intention to transition out of its current I think this is a worthwhile effort, although I agree with Pete that it could fail to work on a process level; I just don't see that as a reason not to try. |
2014-09-04
|
00-04 | Ted Lemon | Ballot comment text updated for Ted Lemon |
2014-09-04
|
00-04 | Adrian Farrel | [Ballot comment] Notwithstanding that "IETF consensus document" normally means "an RFC on which there has been IETF last call and where there is consensus for … [Ballot comment] Notwithstanding that "IETF consensus document" normally means "an RFC on which there has been IETF last call and where there is consensus for publication" I feel that The IANAPLAN working group is chartered to produce an IETF consensus document needs to be clarified since it leave ambiguity as to whether an RFC is the intended output. there are three options (pick one!) - "...that will be published as an RFC" - "...that may be published as an RFC" - "...that will be produced as an Internet-Draft and submitted to the ICANN thingy committee when consensus has been reached." --- In view of Joel's comment about timeliness, I wonder whether micro-management through the milestones might be helpful. |
2014-09-04
|
00-04 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2014-09-04
|
00-04 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-09-04
|
00-04 | Stephen Farrell | [Ballot comment] Overarching? When I look up, I do not see NTIA from here:-) I'd suggest deleting the word - it's not needed and gives … [Ballot comment] Overarching? When I look up, I do not see NTIA from here:-) I'd suggest deleting the word - it's not needed and gives the wrong impression IMO. |
2014-09-04
|
00-04 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2014-09-04
|
00-04 | Joel Jaeggli | [Ballot comment] my biggest concern with all if this is that it actually be timely enough to be useful. |
2014-09-04
|
00-04 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-09-03
|
00-04 | Pete Resnick | [Ballot comment] Sorry for the late review. I've got two concerns. Normally, if I was on the call, I would BLOCK for the moment so … [Ballot comment] Sorry for the late review. I've got two concerns. Normally, if I was on the call, I would BLOCK for the moment so that we could discuss these. But I'm highly unlikely to be on the call tomorrow. So I'm putting in an ABSTAIN, since barring other info I really think these should be dealt with. I hope I'll be able to get to email in the morning, see people's responses (or agreements to make changes) and I'll switch to YES. I may be able to sneak onto the call for a short bit. But if not, I don't want to block going forward if you feel like these issues have been properly addressed. I hope you will address these issues before approving the charter. 1: However, the mechanisms required to address the removal of the overarching NTIA contract may require additional documentation or agreements. This leaves the impression that the WG is chartered to create "additional documentation or agreements." I don't think that's true. I think you should probably add to this: The WG will identify, but not create, such required agreements. 2: OLD 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. This sort of undid the bit that was in -03 which said that the WG need not put these things into it's output RFC. I don't see any discussion on the list as to why this changed. Not only that, it (for the first time in the charter) refers to "the transition proposal". The work item at the top of "Tasks" is a "document that describes the expected interaction between the IETF and the operator". Now we're talking about "proposals". I suggest the following change: NEW Fully documenting the interaction between the IETF and the operator of IETF protocol parameters registries may require 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, either to be included as an appendix to the WG's output document, or in a separate document provided by the IAB or IAOC. I also think the first milestone should be updated similarly to not talk in terms of the "proposal". |
2014-09-03
|
00-04 | Pete Resnick | [Ballot Position Update] New position, Abstain, has been recorded for Pete Resnick |
2014-09-03
|
00-04 | Richard Barnes | [Ballot comment] This charter looks very well crafted and responsive to community input. Thanks to everyone for working on this. |
2014-09-03
|
00-04 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2014-09-03
|
00-04 | Jari Arkko | [Ballot comment] I have reviewed the e-mail thread during the external comment period, and believe that there are no required charter changes. The discussion, in … [Ballot comment] I have reviewed the e-mail thread during the external comment period, and believe that there are no required charter changes. The discussion, in my view at least, talked about ways the working group should operate rather than something that needs to be written in the charter text. Hence I believe this one is ready to go. |
2014-09-03
|
00-04 | Jari Arkko | Ballot comment text updated for Jari Arkko |
2014-09-03
|
00-04 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2014-09-02
|
00-04 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2014-09-02
|
00-04 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2014-09-02
|
00-04 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2014-09-02
|
00-04 | Jari Arkko | Created "Approve" ballot |
2014-09-02
|
00-04 | Jari Arkko | State changed to IESG review from External review |
2014-08-25
|
00-04 | Cindy Morgan | State changed to External review from Internal review |
2014-08-25
|
00-04 | Cindy Morgan | Telechat date has been changed to 2014-09-04 from 2014-08-21 |
2014-08-25
|
00-04 | Cindy Morgan | WG review text was changed |
2014-08-25
|
00-03 | Cindy Morgan | WG review text was changed |
2014-08-21
|
00-04 | Jari Arkko | New version available: charter-ietf-ianaplan-00-04.txt |
2014-08-21
|
00-03 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-08-21
|
00-03 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2014-08-21
|
00-03 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2014-08-21
|
00-03 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2014-08-21
|
00-03 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-08-20
|
00-03 | Kathleen Moriarty | [Ballot comment] Thanks for all of the hard work on this. I support Adrian's comments and many of his detailed edits and it looks as … [Ballot comment] 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. |
2014-08-20
|
00-03 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2014-08-20
|
00-03 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2014-08-20
|
00-03 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2014-08-20
|
00-03 | Jari Arkko | Notification list changed to ianaplan@ietf.org, iana-strategy@i1b.org from ianaplan@ietf.org |
2014-08-20
|
00-03 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-08-20
|
00-03 | Adrian Farrel | [Ballot comment] [updated to reflect a discussion with Pete about a paragraph he had written] I probably have no objection to this document going out … [Ballot comment] [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 |
2014-08-20
|
00-03 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2014-08-20
|
00-03 | Jari Arkko | Notification list changed to ianaplan@ietf.org |
2014-08-20
|
00-03 | Adrian Farrel | [Ballot comment] I probably have no objection to this document going out for community review, but I think it is a shame that the current … [Ballot comment] 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? 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 |
2014-08-20
|
00-03 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2014-08-20
|
00-03 | Pete Resnick | [Ballot comment] I think this version of the charter is fine to go for external review. The following comment can be held for final approval … [Ballot comment] 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. |
2014-08-20
|
00-03 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
2014-08-20
|
00-03 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-08-20
|
00-03 | Barry Leiba | [Ballot comment] I particularly like the changes that went into -03. |
2014-08-20
|
00-03 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2014-08-20
|
00-03 | Jari Arkko | New version available: charter-ietf-ianaplan-00-03.txt |
2014-08-20
|
00-02 | Jari Arkko | New version available: charter-ietf-ianaplan-00-02.txt |
2014-08-20
|
00-01 | Jari Arkko | New version available: charter-ietf-ianaplan-00-01.txt |
2014-08-20
|
00-00 | Barry Leiba | Responsible AD changed to Jari Arkko |
2014-08-20
|
00-00 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2014-08-19
|
00-00 | Barry Leiba | [Ballot comment] As I commented in the discussion: OLD The WG will review, comment on, evaluate, and if need be prepare text for a proposal … [Ballot comment] As I commented in the discussion: OLD The WG will review, comment on, evaluate, and if need be prepare text for a proposal about protocol parameters registries. NEW The WG will review, comment on, evaluate, and if need be prepare text for a proposal about the oversight of the part of the IANA function that administers the protocol parameters registries. END |
2014-08-19
|
00-00 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2014-08-18
|
00-00 | Cindy Morgan | Placed on agenda for telechat - 2014-08-21 |
2014-08-18
|
00-00 | Cindy Morgan | WG action text was changed |
2014-08-18
|
00-00 | Cindy Morgan | WG review text was changed |
2014-08-18
|
00-00 | Cindy Morgan | Created "Ready for external review" ballot |
2014-08-18
|
00-00 | Cindy Morgan | State changed to Internal review from Informal IESG review |
2014-08-18
|
00-00 | Cindy Morgan | Added charter milestone "close", due September 2015 |
2014-08-18
|
00-00 | Cindy Morgan | Added charter milestone "review of other transition proposals, if needed", due May 2015 |
2014-08-18
|
00-00 | Cindy Morgan | Added charter milestone "complete protocol parameters registries proposal", due January 2015 |
2014-08-18
|
00-00 | Cindy Morgan | State changed to Informal IESG review from Not currently under review |
2014-08-18
|
00-00 | Cindy Morgan | New version available: charter-ietf-ianaplan-00-00.txt |