Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries
RFC 7979

Note: This ballot was opened for revision 06 and is now closed.

(Jari Arkko) Yes

(Alia Atlas) Yes

Comment (2014-12-17 for -06)
No email
send info
Typo:

bottom of p. 11:  s/ organizaitons / organizations

(Richard Barnes) Yes

Comment (2014-12-17 for -06)
No email
send info
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?

Alissa Cooper Yes

Comment (2014-12-16 for -06)
No email
send info
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: <fill in>
Minutes from the interim meeting: <fill in>

(Spencer Dawkins) Yes

Comment (2014-12-16 for -06)
No email
send info
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.

(Stephen Farrell) Yes

Comment (2014-12-15 for -06)
No email
send info
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.

(Brian Haberman) Yes

Comment (2014-12-16 for -06)
No email
send info
What Stephen said...

Barry Leiba Yes

(Ted Lemon) Yes

Comment (2014-12-16 for -06)
No email
send info
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!

(Kathleen Moriarty) Yes

Comment (2014-12-16 for -06)
No email
send info
Thank you for your work on this draft and discussing the important points Adrian raised.

(Pete Resnick) Yes

Comment (2014-12-15 for -06)
No email
send info
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.

(Martin Stiemerling) Yes

(Benoît Claise) No Objection

(Adrian Farrel) No Objection

Comment (2014-12-16 for -06)
No email
send info
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]

(Joel Jaeggli) No Objection