Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries
draft-ietf-ianaplan-icg-response-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2016-08-26
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2016-08-19
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2016-08-19
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-08-03
|
10 | (System) | RFC Editor state changed to EDIT from AUTH |
2016-07-28
|
10 | Eliot Lear | New version available: draft-ietf-ianaplan-icg-response-10.txt |
2015-10-14
|
09 | (System) | Notify list changed from ianaplan-chairs@ietf.org, ajs@anvilwalrusden.com to (None) |
2015-01-07
|
09 | (System) | RFC Editor state changed to AUTH from EDIT |
2015-01-07
|
09 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-01-07
|
09 | (System) | RFC Editor state changed to EDIT |
2015-01-07
|
09 | (System) | Announcement was received by RFC Editor |
2015-01-06
|
09 | (System) | IANA Action state changed to No IC from In Progress |
2015-01-06
|
09 | (System) | IANA Action state changed to In Progress |
2015-01-06
|
09 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-01-06
|
09 | Amy Vezza | IESG has approved the document |
2015-01-06
|
09 | Amy Vezza | Closed "Approve" ballot |
2015-01-06
|
09 | Amy Vezza | Ballot approval text was generated |
2015-01-06
|
09 | Amy Vezza | Ballot writeup was changed |
2015-01-06
|
09 | Jari Arkko | The formal approval action is now taken, after the IESG's approval of this document in December 18, 2014, and subsequent small edits and sending a … The formal approval action is now taken, after the IESG's approval of this document in December 18, 2014, and subsequent small edits and sending a summary of last call discussion. I would like to thank everyone who has participated in this process either working on the document directly, managing the process, or through providing input on this matter. |
2015-01-06
|
09 | Jari Arkko | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2015-01-06
|
09 | Russ Housley | New version available: draft-ietf-ianaplan-icg-response-09.txt |
2014-12-22
|
08 | Russ Housley | New version available: draft-ietf-ianaplan-icg-response-08.txt |
2014-12-18
|
07 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Sean Turner. |
2014-12-18
|
07 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2014-12-18
|
07 | Cindy Morgan | Changed consensus to Yes from Unknown |
2014-12-18
|
07 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-12-18
|
07 | Jari Arkko | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2014-12-17
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Melinda Shore. |
2014-12-17
|
07 | Eliot Lear | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2014-12-17
|
07 | Eliot Lear | New version available: draft-ietf-ianaplan-icg-response-07.txt |
2014-12-17
|
06 | Martin Stiemerling | [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling |
2014-12-17
|
06 | Alia Atlas | [Ballot comment] Typo: bottom of p. 11: s/ organizaitons / organizations |
2014-12-17
|
06 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2014-12-17
|
06 | Richard Barnes | [Ballot comment] I agree very strongly with the overall approach of the document, and having watch the process, I agree that it represents the strong … [Ballot comment] I agree very strongly with the overall approach of the document, and having watch the process, I agree that it represents the strong consensus of the IETF. A few editorial comments below. Abstract: "The IETF community is invited to comment and propose changes to this document." Presumably this should be removed before publication? Section 1: "Note that there are small changes to the content of the questions asked in order to match the RFC format." To be defensive, you might note that these changes only entail shifting white space around (assuming that's true). E.g., "Note that the formatting of the questions has been changed to match the RFC format." Section 1: "As if to demonstrate the last point, ..." Have you lost an antecedent here? I'm lost as to what point is supposedly demonstrated here. Section 1: "In this RFP, ..." It would be good to make this a blockquote to be extra clear that it is not from this document. Section 2, Question II.B: "accountab le" Section 2: "IETF Response: To be completed as the process progresses." Presumably this should be updated before publication? It seems pretty silly to have IANA Considerations and Security Considerations in this document. Surely we can make an exception to the requirements and strip these out? |
2014-12-17
|
06 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2014-12-16
|
06 | Adrian Farrel | [Ballot comment] My comments (archived below for completeness) have all been addressed by the editors who plan a new revision. === Thank you for working … [Ballot comment] My comments (archived below for completeness) have all been addressed by the editors who plan a new revision. === Thank you for working on this document and capturing the consensus of the comments you received. I have a few editorial points and some minor questions I hope you will have time to consider. --- The Shepherd write-up says... The I-D should not be published as an RFC immediately after approval. Instead, the IESG should hold it and transmit its approved status through its appointees to the ICG. If discussion with the ICG results in proposals to change the proposal, such changes will need to be discussed in the WG. The advantage of this approach is that a bis to an RFC is not required. This would save RFC Editor time, and possibly avoid confusion later. But this seems a minimal benefit. On the hand, I don't see how discussions with the ICG would result in changes to IETF consensus material. Maybe the point is that the ICG might have questions about the clarity or about missing material. The process here may be slightly out of alignment. Getting external review is normally handled prior to, or during IETF last call. Very occasionally it is also handled immediately after IESG last call. Having external review after approval for publication seems to be running things a bit late. Perhaps what you wanted to achieve was IESG review rather than IESG approval? --- idnits throws some issues and warnings. These are not mentioned in the Shepherd Writeup, but I don't think any work is actually needed. -- This document includes language that was natural in the I-D as it was under development, but would be inappropriate in a published RFC. Title Strike "Draft" Abstract Strike the final sentence. I do not believe that Section 5 is appropriate in an IETF Stream document. --- Section 1 para 1 talks says They solicited proposals regarding post- transition arrangements from the three functional areas In a paragraph mentioning many groups of people, it would be helpful to be explicit instead of saying "They...". I think you mean "The ICG...". It is unclear at this stage of the document what a "functional area" is and it is hard to understand whether the word "from" is intended (the three functional areas should provide proposals about the whole set of transition arrangements) or is intended to read "for" (proposals should be made relating to the transaction arrangements for each of the functional areas). Although this does not change the response itself, clarity would be helpful. --- Section 1 The paragraph... As if to demonstrate the last point, the following text was included in a footnote in the original RFP: ...is either bdly placed or badly worded. It appear that the original RFP was attempting to demonstrate that there are small changes to the content of the questions asked in order to match the RFC format. I doubt that this is what you are trying to say! --- Section 1 Please indent the final paragraph to make it more clear that it is quoted from another document. --- I wondered whether RFC 7120 needed to be referenced. I also wondered whether the Errata Report system should be indicated. Both of these have mechanisms that cause changes in registries without necessitating RFCs. --- Page 11 s/organizaitons/organizations/ --- Page 11 IETF community is quite satisfied The conflict between common usage and correct (British - cf. Jane Austen) meaning of "quite" makes this ambiguous. I suggest you use an alternative such as "reaosnably", "very", or "completely". NB. You use the correct definitive usage in bullet 3 on page 13. --- Page 12 Discussions during the IETF 89 meeting in London led to the following guiding principles for IAB efforts that impact IANA protocol parameter registries. These principles must be taken together; their order is not significant. This text appears to be saying that the consensus embodied in this document is that these principles are a result of the London discussions. It does not imply that there is consensus on these principles themselves. If the latter was intended, then some rewording may be beneficial, such as: The IAB carries out a number of activities that impact IANA protocol parameter registries. The following principles guide how the IAB carries out these activities. These principles must be taken together; their order is not significant. However, the later use of the first person plural is then very ambiguous. When you write... We think the structures that sustain the protocol parameters registries function need to be... ...who is "we". Is it the IAB or is it the community? So perhaps you are just using this document to record the IAB's views on things without any IETF consensus. That would be fine, but perhaps it would be better to put that material in an IAB RFC or an IAB Statement, and reference it from this document. Lastly, the text doesn't really read like guiding principles. It is more some general observations and afirmations. So you might want to change the term. Indeed, you conclude the response with These principles will guide the IAB, IAOC, and the rest of the IETF community as they work with ICANN to establish future IANA performance metrics and operational procedures. ...which is counter to the initial statement that these are guiding principles for IAB efforts. --- Page 15 The policies and procedures are outlined in the documents we named above. Any reason not to repeat the citation for clarity? --- Question V "Support and enhance the multistakeholder model" I don't feel that the response addresses multistakeholerism in the the transition. it talks about how great the IETF is (which is true) but not about the transition proposal. To some extent you could argue that the proposal is that the IETF should retain substantial control, and so talking about the IETF's model is relevant, but this does not jump out of the text. Furthermore, there are elements of the contract and oversight that surely need to be stated. --- As mentioned by others, the response to question VI needs further work. You should probably have drafted this and included it with a caveat so that the community could see what you proposed to deliver. In any case you need: >>> o The steps that were taken to develop the proposal and to >>> determine consensus. - WG last call - IETF last call - IESG evaluation >>> Links to announcements, agendas, mailing lists, consultations and >>> meeting proceedings. - Publication request - IETF last call announcement - IESG ballots - IESG approval announcement >>> An assessment of the level of consensus behind your community's >>> proposal, including a description of areas of contention or >>> disagreement. - Text! (Before the provision of this text, it is hard for the IESG to ballot) --- Section 4 might benefit from observing that part of one of the questions was: >>> "Maintain the security, stability, and resiliency of the >>> Internet DNS;" So security is a specific as well as a general concern. --- As previously mentioned, section 5 is odd. --- Some of your reference are normative. That is, in some cases you do not answer questions with direct text, but say "This is explained in [Foo]." That makes [Foo] a normative reference. In this category I see (at least) [http://www.ntia.doc.gov/page/iana-functions-purchase-order] [RFC6761] [RFC6220] [RFC5226] [RFC2026] [RFC2418] [NTIA-Contract] |
2014-12-16
|
06 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from No Record |
2014-12-16
|
06 | Alissa Cooper | [Ballot comment] I support this document enthusiastically. I've provided editorial suggestions below. = Section 1 = "In March of 2014 the U.S. National Telecommunications & … [Ballot comment] I support this document enthusiastically. I've provided editorial suggestions below. = Section 1 = "In March of 2014 the U.S. National Telecommunications & Information Administration (NTIA) announced its intent to transition oversight of Internet Assigned Numbers Authority (IANA) functions." You might include a citation: http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name-functions = Section 2 = "There are, however, points of interaction between other organizations, and a few cases where we may further define the scope of a registry for technical purposes." s/we/the IETF/ -- s/ICANN or the Regional Internet Registries (RIRs)/ICANN and the Regional Internet Registries (RIRs)/ -- "Please also see the references at the bottom of this document." This seems too vague. There are many references at the bottom of the document, not all of which are relevant to answering the RFP question about policy development and dispute resolution. It seems like this sentence could be deleted. -- s/with the same affiliation/with the same employment affiliation/ -- "Especially when relationships among protocols call for it, many registries are operated by, or in conjunction with, other bodies." I think this would be clearer if it said "Especially when relationships among protocols call for it, many registries are operated by with input and coordination from other bodies." The "operated" verb is otherwise confusing when read together with the sentence that follows. -- s/all input is welcome./all input was welcome./ (or Pete's suggestion works for me too) -- In addition to Adrian's suggestion, I think the response to Section VI of the RFP needs these direct links: IANAPLAN WG: https://datatracker.ietf.org/wg/ianaplan/charter/ Agenda from IETF 91: https://tools.ietf.org/wg/ianaplan/agenda Minutes from IETF 91: https://tools.ietf.org/wg/ianaplan/minutes Agenda from the interim meeting: Minutes from the interim meeting: |
2014-12-16
|
06 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2014-12-16
|
06 | Spencer Dawkins | [Ballot comment] Thanks for taking this task on. I have a bunch of minor suggestions. The editors are welcome to tell me the text has … [Ballot comment] Thanks for taking this task on. I have a bunch of minor suggestions. The editors are welcome to tell me the text has already been heavily tweaked, so I should shut up, and I'm already a Yes ("do the right thing"). After looking at this draft, I'm even less impressed with the way we cite BCPs than I was yesterday, but that's an IESG problem, and probably doesn't affect balloting for this draft (no editor action required). In this text: Abstract This document contains the IETF response to a request for proposals from the IANA Stewardship Transition Coordination Group regarding the protocol parameters registries. It is meant to be included in an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ aggregate proposal that also includes contributions covering domain ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ names and numbering resources that will be submitted from their ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ respective operational communities. The IETF community is invited to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ comment and propose changes to this document. This sentence didn't parse easily for me, and I think the problem was just being too passive and indirect. Perhaps something like this: Abstract This document contains the IETF response to a request for proposals from the IANA Stewardship Transition Coordination Group regarding the protocol parameters registries. The IETF response will be included in an aggregate response, along with contributions covering domain names and numbering resources from the operational communities responsible for those resources. The IETF community is invited to comment and propose changes to this document. In this text: 1. IETF Introduction Note that there are small changes to the content of the questions asked in order to match the RFC format. As if to demonstrate the last point, the following text was included in a footnote in the original RFP: I don't understand how the following text demonstrates "the last point" about small changes to the content of the questions. Were I to guess, my guess would be "this was a footnote, but RFCs don't have footnotes, so we dragged the text into the body of the document". Did I get it? In this text: 2. The Formal RFP Response >>> >>> 0. Proposal Type >>> >>> Identify which category of the IANA functions this >>> submission proposes to address: >>> IETF Response: [XXX] Protocol Parameters This response states the existing practice of the IETF, and also represents the views of the Internet Architecture Board and the IETF. Is ^this paragraph part of the IETF Response, or an observation? I'm probably confused by how the "IETF Response:" line is indented. The next "IETF Response:" line isn't indented as much, and if this line was indented the same way, I'd definitely read the paragraph as part of the IETF Response. FOR THE IESG, no author response required: You have to love this description of BCP9 ... The Internet Standards Process is documented in [RFC2026]. That document explains not only how standards are developed, but also how disputes about decisions are resolved. RFC 2026 has been amended a number of times, and those amendments are indicated in [RFC-INDEX]. ^^^^^^^^^ Is this the best we can ask authors to do in a document that is going to people who don't read RFCs for a living? I'm afraid the answer from the IESG may be "yes" ... In this text: It is important to note that the IETF includes anyone who wishes to participate. Staff and participants from ICANN or the Regional Internet Registries (RIRs) regularly participate in IETF activities. I was somewhat confused about whether this is about who the IETF allows to participate, or about the definition of the "the IETF". Given that you're trying to describe who's included in non-member organization, perhaps this could be something like: It is important to note that the IETF does not have formal membership. The term "the IETF" includes anyone who wishes to participate in the IETF, and IETF participants may also be members of other communities. Staff and participants from ICANN or the Regional Internet Registries (RIRs) regularly participate in IETF activities. IN this text: o The routing architecture has evolved over time, and is expected to continue to do so. Such evolution may have an impact on appropriate IP address allocation strategies. As and when that ^^^^^^^^^^^ happens, we will consult with the RIR community, as we have done in the past. "As and when" reads roughly to me. Perhaps "As", or perhaps "If and when"? FOR THE IESG: In this text: The IAB members are selected and may be recalled through a Nominating Committee (NOMCOM) process, which is described in [RFC3777]. The use of one RFC as shorthand for a multi-RFC BCP in this case is problematic, and this text doesn't even give the hand-waving "by the way, that RFC has been updated, and you can probably find the updates in the RFC-INDEX" that previous instances included. In this text: The IAB provides oversight of the protocol parameters registries of the IETF, and is responsible for selecting appropriate operator(s) and related per-registry arrangements. Especially when relationships among protocols call for it, many registries are operated by, or in conjunction with, other bodies. Unless the IAB or IETF has concluded that special treatment is needed, the operator for registries is currently ICANN. I don't think the last sentence is right. Is it correct to say "ICANN is currently the operator for all registries, except for specific registries where the IAB or IETF has concluded that special treatment is needed"? The current text reads like ICANN as the operator is all or nothing. In this text: We think the structures that sustain the protocol parameters registries function need to be strong enough that they can be offered independently by the Internet technical community, without the need for backing from external parties. And we believe we largely are ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ there already, although the system can be strengthened further, and ^^^^^^^^^^^^^ continuous improvements are being made. The indicated phrase seems very breezy. Perhaps "And we believe those structures are strong enough now"? In this text: >>> V. NTIA Requirements >>> >>> Additionally, NTIA has established that the transition proposal >>> must meet the following five requirements: >>> >>> "Support and enhance the multistakeholder model;" >>> IETF Response: Everyone is welcome to participate in IETF activities. The policies and procedures are outlined in the documents we named above. In- person attendance is not required for participation, and many people participate in email discussions that have never attended an IETF meeting. An email account is the only requirement to participate. The IETF makes use of both formal and informal lines of communication to collaborate with other organizations within the multistakeholder ecosystem. Is it worth explicitly pointing out that there is no cost of membership? In this text: This proposal maintains the existing open framework that allows anyone to participate in the development of IETF standards, including the IANA protocol parameters registries policies. Further, an implementer anywhere in the world has full access to the protocol specification published in the RFC series and the protocol parameters registries published at iana.org. Those who require assignments in the IANA protocol registries will continue to be able to do so, as ^^^^^ specified by the existing policies for those registries. I don't think that parses. Is this "will continue to be able to request these assignments"? In this text: IETF Response: The IESG established the IANAPLAN working group to develop this response. Anyone was welcome to join the discussion and participate ^^^^^^ in the development of this response. An open mailing list (ianaplan@ietf.org) was associated with the working group. In addition, IETF's IANA practices have been discussed in the broader community, and all input is welcome. I wonder if this text reflects how open the IETF is. It would be correct to say "Anyone on earth with access to e-mail was able to join ...". That might not be the right thing to say, but is the current text strong enough? In this text: Announcement of a public session on the transition: http:// www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html I'm not sure "public" is the right adjective. Perhaps something like "Announcement of a face-to-face session with provision for interactive remote participation? I'm asking because the URL just says there's a session at IETF 90, and that would make a random reader of this document think travel, accommodations and meeting fees would be required. I think discussion about the IAB Note is headed the right direction, but that matters. |
2014-12-16
|
06 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2014-12-16
|
06 | Brian Haberman | [Ballot comment] What Stephen said... |
2014-12-16
|
06 | Brian Haberman | [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman |
2014-12-16
|
06 | Ted Lemon | [Ballot comment] I am absolutely delighted by this document. I think it's a good and useful read even outside of its intended context, and serves … [Ballot comment] I am absolutely delighted by this document. I think it's a good and useful read even outside of its intended context, and serves its intended purpose well. I would like to personally commend the working group for producing such a good document so quickly. I do have one comment: This mechanism is global in nature. The current agreement does not specify a jurisdiction. I am puzzled by the use of the term "global" here. I would have said "international." That said, I actually found Pete's suggested text to be a huge improvement. I think the current text is, while not exactly vague, at least easy to misunderstand, so I would encourage the WG to consider adopting Pete's version. I think Pete's longer text contextualizes the term "global" in a way that requires no further adjustment. I am not in love with "we largely are there already" because it's a difficult idiom. I'd suggest the following instead: OLD: And we believe we largely are there already, although the system can be strengthened further, and continuous improvements are being made. NEW: And we believe that this is for the most part the current situation, although the system can be strengthened further, and continuous improvements are being made. I am not in love with this turn of phrase: We fully understand the need to work together. This seems to imply that we had to be convinced. I would rather that we said something like this: We believe that we must continue to work together. OLD: many people participate in email discussions that have never attended an IETF NEW: many people participate in email discussions who have never attended an IETF I am happy with this document whether the changes I've suggested above are adopted or not. Thanks for the good work! |
2014-12-16
|
06 | Ted Lemon | Ballot comment text updated for Ted Lemon |
2014-12-16
|
06 | Ted Lemon | [Ballot comment] I am absolutely delighted by this document. I think it's a good and useful read even outside of its intended context, and serves … [Ballot comment] I am absolutely delighted by this document. I think it's a good and useful read even outside of its intended context, and serves its intended purpose well. I would like to personally comment the working group for producing such a good document so quickly. I do have one comment: This mechanism is global in nature. The current agreement does not specify a jurisdiction. I am puzzled by the use of the term "global" here. I would have said "international." That said, I actually found Pete's suggested text to be a huge improvement. I think the current text is, while not exactly vague, at least easy to misunderstand, so I would encourage the WG to consider adopting Pete's version. I think Pete's longer text contextualizes the term "global" in a way that requires no further adjustment. I am not in love with "we largely are there already" because it's a difficult idiom. I'd suggest the following instead: OLD: And we believe we largely are there already, although the system can be strengthened further, and continuous improvements are being made. NEW: And we believe that this is for the most part the current situation, although the system can be strengthened further, and continuous improvements are being made. I am not in love with this turn of phrase: We fully understand the need to work together. This seems to imply that we had to be convinced. I would rather that we said something like this: We believe that we must continue to work together. OLD: many people participate in email discussions that have never attended an IETF NEW: many people participate in email discussions who have never attended an IETF I am happy with this document whether the changes I've suggested above are adopted or not. Thanks for the good work! |
2014-12-16
|
06 | Ted Lemon | [Ballot Position Update] New position, Yes, has been recorded for Ted Lemon |
2014-12-16
|
06 | Kathleen Moriarty | [Ballot comment] Thank you for your work on this draft and discussing the important points Adrian raised. |
2014-12-16
|
06 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2014-12-15
|
06 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-12-15
|
06 | Stephen Farrell | [Ballot comment] I think Adrian's points are valid and well worth bottoming out on but I'll end up a yes on this unless something very … [Ballot comment] I think Adrian's points are valid and well worth bottoming out on but I'll end up a yes on this unless something very crazy happens. And balloting ahead of that having happened is maybe a good demonstration that not every single word in this draft is gigantically important to the extent that getting one word wrong will cause the Internet to come crumbling down. The basic thrust, and the detail, of this are good. I look forward to seeing Adrian's issues with the end stage processing of this being sorted out smoothly. |
2014-12-15
|
06 | Stephen Farrell | [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell |
2014-12-15
|
06 | Pete Resnick | [Ballot comment] I'm absolutely fine with this going forward as-is caveat one question below. Otherwise, my other four comments are completely stylistic/editorial that I found … [Ballot comment] I'm absolutely fine with this going forward as-is caveat one question below. Otherwise, my other four comments are completely stylistic/editorial that I found during my final review: If the WG finds them useful, great, but if you don't change them, I will still be fine with the document going forward as-is. First my question: In section 2, you say: >>> An assessment of the level of consensus behind your community's >>> proposal, including a description of areas of contention or >>> disagreement. >>> IETF Response: To be completed as the process progresses. Is the IESG being asked to fill that in at the end of the process? I think that's a reasonable choice, but I wanted to make sure that someone had the token. You should probably add a note here to indicate who is expected to draft that text. Now, as to the editorial comments: In section 1, "the three functional areas" are not identified in the first paragraph of the intro. Perhaps they should be? In section 2, I thought that: The IETF is a global organization that produces voluntary standards, whose goal is to make the Internet work better [RFC3595]. sounded a bit cheesy. I think it would sound more professional to use the full mission statement from 3935 instead of the goal statement: The IETF is a global organization that produces voluntary standards, whose mission is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better [RFC3595]. Maybe too much of a mouthful, but I think it sounds better. Entirely up to the WG. Also in section 2: >>> VI. Community Process >>> >>> This section should describe the process your community used for >>> developing this proposal, including: >>> >>> o The steps that were taken to develop the proposal and to >>> determine consensus. >>> IETF Response: The IESG established the IANAPLAN working group to develop this response. Anyone was welcome to join the discussion and participate in the development of this response. An open mailing list (ianaplan@ietf.org) was associated with the working group. In addition, IETF's IANA practices have been discussed in the broader community, and all input is welcome. The simple editorial point is that everything else is in the past tense except for the the last sentence, which switches from present perfect to present. Present perfect seems right for everything except the first sentence. The other point about this is that it doesn't quite answer the question about the steps taken to determine consensus. Here's a suggested replacement; the stuff in curly braces is if the group thinks it's worth being more explicit: IETF Response: The IESG established the IANAPLAN working group to develop this response. Anyone has been welcome to join the discussion and participate in the development of this response. An open mailing list (ianaplan@ietf.org) has been associated with the working group. In addition, IETF's IANA practices have been discussed in the broader community, and all input has been welcome. Normal IETF procedures [RFC2026] [RFC2418] were used to determine rough consensus{: The chairs of the working group reviewed open issues and, after an internal working group last call, determined that all had been satisfactorily addressed, and subsequently the IESG did a formal IETF-wide Last Call followed by a formal review and determined that the document had rough consensus}. Finally, one last editorial bit: When providing the links to announcements, I suggest using the mailarchive.ietf.org ones instead of the mailman ones (which appear in the "Archived-at:" of each message). The mailarchive.ietf.org links I believe are intended to be the place to find mail over the long term. |
2014-12-15
|
06 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
2014-12-15
|
06 | Adrian Farrel | [Ballot comment] Thank you for working on this document and capturing the consensus of the comments you received. I have a few editorial points and … [Ballot comment] Thank you for working on this document and capturing the consensus of the comments you received. I have a few editorial points and some minor questions I hope you will have time to consider. --- The Shepherd write-up says... The I-D should not be published as an RFC immediately after approval. Instead, the IESG should hold it and transmit its approved status through its appointees to the ICG. If discussion with the ICG results in proposals to change the proposal, such changes will need to be discussed in the WG. The advantage of this approach is that a bis to an RFC is not required. This would save RFC Editor time, and possibly avoid confusion later. But this seems a minimal benefit. On the hand, I don't see how discussions with the ICG would result in changes to IETF consensus material. Maybe the point is that the ICG might have questions about the clarity or about missing material. The process here may be slightly out of alignment. Getting external review is normally handled prior to, or during IETF last call. Very occasionally it is also handled immediately after IESG last call. Having external review after approval for publication seems to be running things a bit late. Perhaps what you wanted to achieve was IESG review rather than IESG approval? --- idnits throws some issues and warnings. These are not mentioned in the Shepherd Writeup, but I don't think any work is actually needed. -- This document includes language that was natural in the I-D as it was under development, but would be inappropriate in a published RFC. Title Strike "Draft" Abstract Strike the final sentence. I do not believe that Section 5 is appropriate in an IETF Stream document. --- Section 1 para 1 talks says They solicited proposals regarding post- transition arrangements from the three functional areas In a paragraph mentioning many groups of people, it would be helpful to be explicit instead of saying "They...". I think you mean "The ICG...". It is unclear at this stage of the document what a "functional area" is and it is hard to understand whether the word "from" is intended (the three functional areas should provide proposals about the whole set of transition arrangements) or is intended to read "for" (proposals should be made relating to the transaction arrangements for each of the functional areas). Although this does not change the response itself, clarity would be helpful. --- Section 1 The paragraph... As if to demonstrate the last point, the following text was included in a footnote in the original RFP: ...is either bdly placed or badly worded. It appear that the original RFP was attempting to demonstrate that there are small changes to the content of the questions asked in order to match the RFC format. I doubt that this is what you are trying to say! --- Section 1 Please indent the final paragraph to make it more clear that it is quoted from another document. --- I wondered whether RFC 7120 needed to be referenced. I also wondered whether the Errata Report system should be indicated. Both of these have mechanisms that cause changes in registries without necessitating RFCs. --- Page 11 s/organizaitons/organizations/ --- Page 11 IETF community is quite satisfied The conflict between common usage and correct (British - cf. Jane Austen) meaning of "quite" makes this ambiguous. I suggest you use an alternative such as "reaosnably", "very", or "completely". NB. You use the correct definitive usage in bullet 3 on page 13. --- Page 12 Discussions during the IETF 89 meeting in London led to the following guiding principles for IAB efforts that impact IANA protocol parameter registries. These principles must be taken together; their order is not significant. This text appears to be saying that the consensus embodied in this document is that these principles are a result of the London discussions. It does not imply that there is consensus on these principles themselves. If the latter was intended, then some rewording may be beneficial, such as: The IAB carries out a number of activities that impact IANA protocol parameter registries. The following principles guide how the IAB carries out these activities. These principles must be taken together; their order is not significant. However, the later use of the first person plural is then very ambiguous. When you write... We think the structures that sustain the protocol parameters registries function need to be... ...who is "we". Is it the IAB or is it the community? So perhaps you are just using this document to record the IAB's views on things without any IETF consensus. That would be fine, but perhaps it would be better to put that material in an IAB RFC or an IAB Statement, and reference it from this document. Lastly, the text doesn't really read like guiding principles. It is more some general observations and afirmations. So you might want to change the term. Indeed, you conclude the response with These principles will guide the IAB, IAOC, and the rest of the IETF community as they work with ICANN to establish future IANA performance metrics and operational procedures. ...which is counter to the initial statement that these are guiding principles for IAB efforts. --- Page 15 The policies and procedures are outlined in the documents we named above. Any reason not to repeat the citation for clarity? --- Question V "Support and enhance the multistakeholder model" I don't feel that the response addresses multistakeholerism in the the transition. it talks about how great the IETF is (which is true) but not about the transition proposal. To some extent you could argue that the proposal is that the IETF should retain substantial control, and so talking about the IETF's model is relevant, but this does not jump out of the text. Furthermore, there are elements of the contract and oversight that surely need to be stated. --- As mentioned by others, the response to question VI needs further work. You should probably have drafted this and included it with a caveat so that the community could see what you proposed to deliver. In any case you need: >>> o The steps that were taken to develop the proposal and to >>> determine consensus. - WG last call - IETF last call - IESG evaluation >>> Links to announcements, agendas, mailing lists, consultations and >>> meeting proceedings. - Publication request - IETF last call announcement - IESG ballots - IESG approval announcement >>> An assessment of the level of consensus behind your community's >>> proposal, including a description of areas of contention or >>> disagreement. - Text! (Before the provision of this text, it is hard for the IESG to ballot) --- Section 4 might benefit from observing that part of one of the questions was: >>> "Maintain the security, stability, and resiliency of the >>> Internet DNS;" So security is a specific as well as a general concern. --- As previously mentioned, section 5 is odd. --- Some of your reference are normative. That is, in some cases you do not answer questions with direct text, but say "This is explained in [Foo]." That makes [Foo] a normative reference. In this category I see (at least) [http://www.ntia.doc.gov/page/iana-functions-purchase-order] [RFC6761] [RFC6220] [RFC5226] [RFC2026] [RFC2418] [NTIA-Contract] |
2014-12-15
|
06 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2014-12-15
|
06 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-12-13
|
06 | Barry Leiba | [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba |
2014-12-11
|
06 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-ianaplan-icg-response-06, which is currently in Last Call, and has the following comments: We understand that, upon approval of this … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-ianaplan-icg-response-06, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2014-12-10
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2014-12-09
|
06 | Jari Arkko | Ballot has been issued |
2014-12-09
|
06 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2014-12-09
|
06 | Jari Arkko | Created "Approve" ballot |
2014-12-09
|
06 | Jari Arkko | Ballot writeup was changed |
2014-12-09
|
06 | Christer Holmberg | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Christer Holmberg. |
2014-12-01
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Melinda Shore |
2014-12-01
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Melinda Shore |
2014-11-28
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2014-11-28
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2014-11-27
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sean Turner |
2014-11-27
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sean Turner |
2014-11-26
|
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-11-26
|
06 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Draft Response to the Internet … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Draft Response to the Internet Coordination Group Request for Proposals on the IANA protocol parameters registries) to Informational RFC The IESG has received a request from the Planning for the IANA/NTIA Transition WG (ianaplan) to consider the following document: - 'Draft Response to the Internet Coordination Group Request for Proposals on the IANA protocol parameters registries' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-12-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document contains the IETF response to a request for proposals from the IANA Stewardship Transition Coordination Group regarding the protocol parameters registries. It is meant to be included in an aggregate proposal that also includes contributions covering domain names and numbering resources that will be submitted from their respective operational communities. The IETF community is invited to comment and propose changes to this document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-11-26
|
06 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-11-26
|
06 | Jari Arkko | Last call was requested |
2014-11-26
|
06 | Jari Arkko | Ballot approval text was generated |
2014-11-26
|
06 | Jari Arkko | Ballot writeup was generated |
2014-11-26
|
06 | Jari Arkko | IESG state changed to Last Call Requested from AD Evaluation |
2014-11-26
|
06 | Jari Arkko | Writeup for draft-ietf-ianaplan-icg-response-06 v20141126c IANAPLAN WG Chairs: Marc Blanchet and Leslie Daigle 1. Summary The document shepherd is Andrew Sullivan. The responsible Area Director is … Writeup for draft-ietf-ianaplan-icg-response-06 v20141126c IANAPLAN WG Chairs: Marc Blanchet and Leslie Daigle 1. Summary The document shepherd is Andrew Sullivan. The responsible Area Director is Jari Arkko. The document is the product of the IANAPLAN working group. This document embodies the IETF's response to the IANA Stewardship Transition Coordination Group (ICG) request for proposal. It outlines the IETF's views on the necessary arrangements to support the continued operation of registries operated by IANA for the IETF under the terms of an agreement between the National Telecommunications and Information Administration and the Internet Corporation for Assigned Names and Numbers). 2. Reviews and Consensus There is rough consensus in the WG to publish the document as an RFC. To a large extent, the document expresses things on which the IETF had previously already achieved consensus. There is no reason to suppose, for instance, that there is much desire to open the terms of RFC 2860. There was ample discussion of the Internet draft in the working group, both on the list and in the meeting session at IETF 91. These discussions mostly focussed on certain contentious issues. Several of them were worked out as a result of WG discussion. There was a suggestion that the document should request the transfer of the domain "iana.org" and also any marks associated with IANA to the control of the IETF Trust. The WG did not agree to this suggestion, and instead reached rough consensus not to request such transfers. There was a broad suggestion that the document should contain either much stronger statements of terms acceptable to the IETF, or else strong statements instructing the IAOC what terms to negotiate. The WG did not agree to this suggestion, and reached rough consensus not to include such statements in output from the WG. In addition, a member of the IAOC pointed out that it would be hard for the IAOC to implement instructions that did not have a fallback position (what to do in case negotiation failed). The WG's charter explicitly required the WG not to constrain the IAB's or IAOC's execution of their respective duties too much, so it is difficult to know how the WG could have produced something incorporating this suggestion, even if it had wanted to. Two participants were sufficiently unhappy with the resulting draft, apparently in part because of the previous two decisions, that they requested their names be removed from the Acknowledgements section, despite their contributions to the discussion of the draft. 3. Intellectual Property Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document. 4. Other Points The I-D should not be published as an RFC immediately after approval. Instead, the IESG should hold it and transmit its approved status through its appointees to the ICG. If discussion with the ICG results in proposals to change the proposal, such changes will need to be discussed in the WG. |
2014-11-26
|
06 | Jari Arkko | Last call announcement was changed |
2014-11-26
|
06 | Jari Arkko | Last call announcement was generated |
2014-11-26
|
06 | Jari Arkko | Placed on agenda for telechat - 2014-12-18 |
2014-11-26
|
06 | Jari Arkko | AD review has been performed earlier without major issues. Some suggested changes were discussed on the mailing list, and the resulting changes were non-controversial. Draft-06 … AD review has been performed earlier without major issues. Some suggested changes were discussed on the mailing list, and the resulting changes were non-controversial. Draft-06 adopts those changes along with some editorial improvements. The draft is ready for IETF Last Call. |
2014-11-26
|
06 | Jari Arkko | IESG state changed to AD Evaluation from Publication Requested |
2014-11-26
|
06 | Jari Arkko | IESG process started in state Publication Requested |
2014-11-26
|
06 | (System) | Earlier history may be found in the Comment Log for /doc/draft-lear-iana-icg-response/ |
2014-11-26
|
06 | Jari Arkko | Working group state set to Submitted to IESG for Publication |
2014-11-26
|
06 | Eliot Lear | New version available: draft-ietf-ianaplan-icg-response-06.txt |
2014-11-25
|
05 | Eliot Lear | New version available: draft-ietf-ianaplan-icg-response-05.txt |
2014-11-22
|
04 | Eliot Lear | New version available: draft-ietf-ianaplan-icg-response-04.txt |
2014-11-14
|
03 | Eliot Lear | New version available: draft-ietf-ianaplan-icg-response-03.txt |
2014-11-10
|
02 | Marc Blanchet | Intended Status changed to Informational from None |
2014-11-10
|
02 | Marc Blanchet | Notification list changed to "Andrew Sullivan" <ajs@anvilwalrusden.com> |
2014-11-10
|
02 | Marc Blanchet | Document shepherd changed to Andrew Sullivan |
2014-10-27
|
02 | Eliot Lear | New version available: draft-ietf-ianaplan-icg-response-02.txt |
2014-10-16
|
01 | Eliot Lear | New version available: draft-ietf-ianaplan-icg-response-01.txt |
2014-10-08
|
00 | Marc Blanchet | This document now replaces draft-lear-iana-icg-response instead of None |
2014-10-08
|
00 | Eliot Lear | New version available: draft-ietf-ianaplan-icg-response-00.txt |