Skip to main content

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