Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries
draft-ietf-ianaplan-icg-response-10

Typo:

bottom of p. 11:  s/ organizaitons / organizations

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>

What Stephen said...

Thank you for your work on this draft and discussing the important points Adrian raised.

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.

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?

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.

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.

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!