Planning for the IANA/NTIA Transition
charter-ietf-ianaplan-01

[Ballot comment]
This isn't a strong objection, but I find this text a little unclear:
  Registries of parameter values for use in IETF protocols are stored
  and maintainted for the IETF by the Internet Assigned Numbers
  Authority (IANA), and are the subject of the "IANA Considerations"
  section in many RFCs.

  For a number of years, maintenance of the IETF protocol parameters
  registries has been provided by the Internet Corporation for Assigned
  Names and Numbers (ICANN).

I think it would be clearer if the second paragraph started thusly:

Registries of parameter values for use in IETF protocols are stored
and maintainted for the IETF by the Internet Assigned Numbers
Authority (IANA), and are the subject of the "IANA Considerations"
section in many RFCs.

  For a number of years, the IANA function has been provided by the
  Internet Corporation for Assigned Names and Numbers (ICANN).

Otherwise you're repeating information from the first paragraph, and not directly describing the connection between IETF and ICANN.  Of course any sensible person will make the connection, hence the weakness of this objection, but I don't think it's necessary to make the reader do this work.

Rather than verbing a noun here with "to transition out of", why not say "to relinquish" or "to give up"?

  2014, NTIA announced its intention to transition out of its current

I think this is a worthwhile effort, although I agree with Pete that it could fail to work on a process level; I just don't see that as a reason not to try.

[Ballot comment]
Notwithstanding that "IETF consensus document" normally means "an RFC on which there has been IETF last call and where there is consensus for publication" I feel that
  The IANAPLAN working group is chartered to produce an IETF consensus
  document
needs to be clarified since it leave ambiguity as to whether an RFC is the intended output. there are three options (pick one!)
- "...that will be published as an RFC"
- "...that may be published as an RFC"
- "...that will be produced as an Internet-Draft and submitted to the ICANN thingy committee when consensus has been reached."

---

In view of Joel's comment about timeliness, I wonder whether micro-management through the milestones might be helpful.

[Ballot comment]

Overarching? When I look up, I do not see NTIA from here:-)

I'd suggest deleting the word - it's not needed and gives the
wrong impression IMO.

[Ballot comment]
Sorry for the late review. I've got two concerns. Normally, if I was on the call, I would BLOCK for the moment so that we could discuss these. But I'm highly unlikely to be on the call tomorrow. So I'm putting in an ABSTAIN, since barring other info I really think these should be dealt with. I hope I'll be able to get to email in the morning, see people's responses (or agreements to make changes) and I'll switch to YES. I may be able to sneak onto the call for a short bit. But if not, I don't want to block going forward if you feel like these issues have been properly addressed. I hope you will address these issues before approving the charter.

1:

  However, the mechanisms required to address the removal of the
  overarching NTIA contract may require additional documentation or
  agreements.

This leaves the impression that the WG is chartered to create "additional documentation or agreements." I don't think that's true. I think you should probably add to this:

  The WG will identify, but not create, such required agreements.

2:

OLD
  Some parts of the transition proposal may need to document detailed
  terms of agreements or other details of procedures that are normally
  delegated to and handled by the IAB or IAOC. The working group will
  not attempt to produce or discuss documentation for these details,
  but will request the IAB or IAOC to provide them ready for submission
  as part of the final proposal.

This sort of undid the bit that was in -03 which said that the WG need not put these things into it's output RFC. I don't see any discussion on the list as to why this changed. Not only that, it (for the first time in the charter) refers to "the transition proposal". The work item at the top of "Tasks" is a "document that describes the expected interaction between the IETF and the operator". Now we're talking about "proposals". I suggest the following change:

NEW
  Fully documenting the interaction between the IETF and the operator
  of IETF protocol parameters registries may require detailed terms of
  agreements or other details of procedures that are normally delegated
  to and handled by the IAB or IAOC. The working group will not attempt
  to produce or discuss documentation for these details, but will
  request the IAB or IAOC to provide them, either to be included as an
  appendix to the WG's output document, or in a separate document
  provided by the IAB or IAOC.

I also think the first milestone should be updated similarly to not talk in terms of the "proposal".

[Ballot comment]
I have reviewed the e-mail thread during the external comment period, and believe that there are no required charter changes. The discussion, in my view at least, talked about ways the working group should operate rather than something that needs to be written in the charter text. Hence I believe this one is ready to go.

[Ballot comment]
Thanks for all of the hard work on this.  I support Adrian's comments and many of his detailed edits and it looks as though agreement is forming on his suggested changes.

[Ballot comment]
[updated to reflect a discussion with Pete about a paragraph he had written]

I probably have no objection to this document going out for community review, but I think it is a shame that the current revision has had no discussion on the mailing list created to discuss the topic despite being very substantially different from the version previously posted there. Given the volume of my comments below, I suspect that reaching some form of stability in the text and getting buy-in from the majority of interested parties would be a good idea before embarking on the one week formal review.

---
OLD
The IETF stores parameters for protocols it defines in registries.
These registries are maintained by the Internet Assigned Numbers
Authority (IANA), and are the subject of the "IANA Considerations"
section in many RFCs.
NEW
Regestries of parameter values for use in IETF protocols are stored
and maintainted for the IETF by the Internet Assigned Numbers
Authority (IANA), and are the subject of the "IANA Considerations"
section in many RFCs.
COMMENT
Just trying to align the words.
END

OLD
For a number of years, the IANA function has been provided by the
Internet Corporation for Assigned Names and Numbers (ICANN).  The
IETF's relationship with IANA was formalized through a Memorandum of
Understanding codified in 2000 with the publication of RFC 2860; over
time processes and role definitions have evolved, and have been
documented in supplemental agreements.
NEW
For a number of years, the IANA function has been provided by the
Internet Corporation for Assigned Names and Numbers (ICANN).  The
IETF's relationship with IANA was formalized through a Memorandum of
Understanding between the IETF and ICANN codified in 2000 with the
publication of RFC 2860.  Over time, processes and role definitions
have evolved, and have been documented in supplemental agreements.
COMMENT
Useful to know between who the MoU was formed.

Fixed some English.

However: what is "the IANA function" referred to here? I think it is
more that the maintenance of protocol regestries for the IETF described
in the previous paragraph.
END

OLD
ICANN has historically had a contract with the US Department of
Commerce (DoC), undertaken through the National Telecommunications and
Information Administration (NTIA).  In March of 2014, NTIA announced
its intention to complete the evolution begun in 1997, meaning that
NTIA would not need to renew its contract with ICANN when that
contract expires 30 September 2015.  NTIA requested a transition
proposal be prepared to outline the necessary arrangements. In the
case of the IETF, we expect these arrangements to consist largely of
the existing well-documented practices.
COMMENT
"Historically" implies in "the past". Using the Present Perfect
Continuous ("has had") both indicates history and currency.

Having a contract is one thing, saying what it was for may also be
valuable ""... to provide the IANA function."

"Complete the evolution begun in 1997" may be useful to someone, but
not me! Either explain that evolution or don't mention it. I think that
it is not necessary to mention it. On the other hand "evolution" and
"transition" have no meaning without some context.
"would not need to" is very ambiguous! Maybe it can't be avoided, but
it isn't good.

"A transition proposal" surely contains a proposal for transition, not
the existing well-documented practices. Maybe, "In the case of the
elements of the IANA function concerning the IETF protocol registries,
it is likely that the existing well-documented practices will continue
and no or little transition activity will be required."
END

OLD
Tasks
=====

The WG’s output is expected to be an IETF consensus document which
describes the expected interaction between the IETF and the protocol
parameters registries operator.
COMMENT
We have to recall that IANA maintains registries for other protocols
and that ICANN has been adamant that it is allowed to do that. So we
need to be clear we are not on that turf.

Also, at this stage, we should not be "expecting" output. We should be
saying what the WG is chartered to do.
NEW
Tasks
=====

The IANAPLAN working group is chartered to produce an IETF consensus
document that describes the expected interaction between the IETF and
the operator of the registries that contain the protocol parameters for
the IETF protocols.
END

OLD
Given that we have a system today that works well for the IETF,
minimal change in the oversight of the protocol parameters registries
is preferred in all cases and no change is preferred when possible.
With a view to addressing implications of moving the NTIA out of its
current role with respect to IANA on the IETF protocol parameter
registry function, the WG will focus on documenting and ensuring the
continuation of the current arrangements.  The
working group will assume the following documents continue to be in
effect:
COMMENT
"works well *for*the*IETF*" is likely to raise eyebrows. For whom
does it not work well? Why doesn't the IETF care? I think we can
just say that it works well.

Do we need the passive voice? And maybe we don't need the didactic
tone either.

The "oversight" that is claimed to exist today is somewhat over-
claimed :-(  I think part of the trouble is that we might have a
different view of what the word means from what the NTIA is thinking.
There is:
- setting criteria
- measuring against criteria
- requiring satsifaction of criteria (or enforcing contract)
I think that the bit that is transitioning (in the case of protocol
registries) is the third of these. We seem to be dodging that, yet
that is exactly the bit where we are vulnerable to theft of control.
NEW
The system in place today for oversight of the IETF protocol registries
component of the IANA function works well. The working group will
address the implications of moving the NTIA out of its current role with
respect to IANA on the IETF protocol parameters registry function in a
way that ensures continuation of the current arrangements.

The working group will assume the following documents continue to be in
effect:
END

OLD
- RFC 2850 (especially section 2(d))
- RFC 3777 and its updates
- RFC 2860
- RFC 6220
- IETF-ICANN-MOU_2000
  (http://iaoc.ietf.org/documents/IETF-ICANN-MOU_2000.pdf)
- ICANN-IETF Supplemental Agreements
  (updated yearly since 2007, the 2014 version is available at
  http://iaoc.ietf.org/documents/2014-ICANN-IETF-MoU-Supplemental-Agreement-Executed.pdf)
COMMENT
Don't do "especially". Either the document is in effect or it is not.

I wonder whether this list of documents should be marked as non-
exclusive.
END

OLD
This working group is chartered solely with respect to the planning
needed for the transition.
COMMENT
What does this mean? I thought the working group was chartered to
produce a document that described "the interaction between the IETF
and the protocol parameters registries operator."
END

OLD
Possible improvements outside that scope
will be set aside for future consideration.  Avoiding alterations in
substantive outcomes should be the goal, even if eventual mechanisms
required to address the removal of the overarching NTIA contract
may require additional documentation or agreements.
COMMENT
"alterations in substantive outcomes" means what?
Google tranlate renders "Changes in the content of the results" via
German and "changes will result in significant" via Swahili.
I think you are trying to say that the goal is to leave in place as
many elements of existing processes and agreements as is possible.
Would it be possible to say what the goal actually is?
END

OLD
Should proposals made to the NTIA by other communities regarding the
transition of other IANA functions affect the protocol parameter
registries or the IETF, the WG will also review and comment on them.
NEW
Saying that the WG will comment implies that the WG will produce some
form of output. I'm not sure what you have in mind.

Saying that other proposal might affect the IETF is a very wide scope!
You had previously screwed this tight to say the WG was only working on
the protocol parameters part. This text opens it up to the full
transition discussion.

And you need to tighten "protocol parameters registries" to "IETF
protocol parameters registries".
END

OLD
The output document of the WG need not be the complete transition
proposal regarding the oversight of the protocol parameters registries
to be handed to the NTIA. Specifically, if that transition proposal
requires documentation of some detailed terms of agreements or other
details of procedures that are normally delegated to and handled by
the IAB or IAOC, the IAB or IAOC can provide those details as part of
the submission; the WG does not need to come to consensus on those
parts of the submission.
COMMENT
But presumably you intend that the WG does come to consensus on
the fact that it doesn't need to come to consensus?

Possibly the following would work...
NEW
Some parts of the transition proposal may need to document detailed
terms of agreements or other details of procedures that are normally
delegated to and handled by the IAB or IAOC.  The working group will
not attempt to produce or discuss documentation for these details, but
will request the IAB or IAOC to provide them ready for submission as
part of the final proposal.
END

OLD
The WG shall seek the expertise of the IAB IANA Strategy Program to
formulate its output. It is expected that members of the IAB IANA
Strategy Program will actively participate in the WG.

Milestones
==========

January 2015  -- complete protocol parameters registries proposal
May 2015 -- review of other transition proposals, if needed
Sept 2015 -- close
COMMENT
I should like to know to whom the WG delivers the complete proposal
and in what form.

I would also like clarity with regard to how the proposal delivered
by the WG is considered complete if additional work from the IAB and
IAOC is needed. Does that change the timeline?
END

[Ballot comment]
I probably have no objection to this document going out for community review, but I think it is a shame that the current revision has had no discussion on the mailing list created to discuss the topic despite being very substantially different from the version previously posted there. Given the volume of my comments below, I suspect that reaching some form of stability in the text and getting buy-in from the majority of interested parties would be a good idea before embarking on the one week formal review.

---
OLD
The IETF stores parameters for protocols it defines in registries.
These registries are maintained by the Internet Assigned Numbers
Authority (IANA), and are the subject of the "IANA Considerations"
section in many RFCs.
NEW
Regestries of parameter values for use in IETF protocols are stored
and maintainted for the IETF by the Internet Assigned Numbers
Authority (IANA), and are the subject of the "IANA Considerations"
section in many RFCs.
COMMENT
Just trying to align the words.
END

OLD
For a number of years, the IANA function has been provided by the
Internet Corporation for Assigned Names and Numbers (ICANN).  The
IETF's relationship with IANA was formalized through a Memorandum of
Understanding codified in 2000 with the publication of RFC 2860; over
time processes and role definitions have evolved, and have been
documented in supplemental agreements.
NEW
For a number of years, the IANA function has been provided by the
Internet Corporation for Assigned Names and Numbers (ICANN).  The
IETF's relationship with IANA was formalized through a Memorandum of
Understanding between the IETF and ICANN codified in 2000 with the
publication of RFC 2860.  Over time, processes and role definitions
have evolved, and have been documented in supplemental agreements.
COMMENT
Useful to know between who the MoU was formed.

Fixed some English.

However: what is "the IANA function" referred to here? I think it is
more that the maintenance of protocol regestries for the IETF described
in the previous paragraph.
END

OLD
ICANN has historically had a contract with the US Department of
Commerce (DoC), undertaken through the National Telecommunications and
Information Administration (NTIA).  In March of 2014, NTIA announced
its intention to complete the evolution begun in 1997, meaning that
NTIA would not need to renew its contract with ICANN when that
contract expires 30 September 2015.  NTIA requested a transition
proposal be prepared to outline the necessary arrangements. In the
case of the IETF, we expect these arrangements to consist largely of
the existing well-documented practices.
COMMENT
"Historically" implies in "the past". Using the Present Perfect
Continuous ("has had") both indicates history and currency.

Having a contract is one thing, saying what it was for may also be
valuable ""... to provide the IANA function."

"Complete the evolution begun in 1997" may be useful to someone, but
not me! Either explain that evolution or don't mention it. I think that
it is not necessary to mention it. On the other hand "evolution" and
"transition" have no meaning without some context.
"would not need to" is very ambiguous! Maybe it can't be avoided, but
it isn't good.

"A transition proposal" surely contains a proposal for transition, not
the existing well-documented practices. Maybe, "In the case of the
elements of the IANA function concerning the IETF protocol registries,
it is likely that the existing well-documented practices will continue
and no or little transition activity will be required."
END

OLD
Tasks
=====

The WG’s output is expected to be an IETF consensus document which
describes the expected interaction between the IETF and the protocol
parameters registries operator.
COMMENT
We have to recall that IANA maintains registries for other protocols
and that ICANN has been adamant that it is allowed to do that. So we
need to be clear we are not on that turf.

Also, at this stage, we should not be "expecting" output. We should be
saying what the WG is chartered to do.
NEW
Tasks
=====

The IANAPLAN working group is chartered to produce an IETF consensus
document that describes the expected interaction between the IETF and
the operator of the registries that contain the protocol parameters for
the IETF protocols.
END

OLD
Given that we have a system today that works well for the IETF,
minimal change in the oversight of the protocol parameters registries
is preferred in all cases and no change is preferred when possible.
With a view to addressing implications of moving the NTIA out of its
current role with respect to IANA on the IETF protocol parameter
registry function, the WG will focus on documenting and ensuring the
continuation of the current arrangements.  The
working group will assume the following documents continue to be in
effect:
COMMENT
"works well *for*the*IETF*" is likely to raise eyebrows. For whom
does it not work well? Why doesn't the IETF care? I think we can
just say that it works well.

Do we need the passive voice? And maybe we don't need the didactic
tone either.

The "oversight" that is claimed to exist today is somewhat over-
claimed :-(  I think part of the trouble is that we might have a
different view of what the word means from what the NTIA is thinking.
There is:
- setting criteria
- measuring against criteria
- requiring satsifaction of criteria (or enforcing contract)
I think that the bit that is transitioning (in the case of protocol
registries) is the third of these. We seem to be dodging that, yet
that is exactly the bit where we are vulnerable to theft of control.
NEW
The system in place today for oversight of the IETF protocol registries
component of the IANA function works well. The working group will
address the implications of moving the NTIA out of its current role with
respect to IANA on the IETF protocol parameters registry function in a
way that ensures continuation of the current arrangements.

The working group will assume the following documents continue to be in
effect:
END

OLD
- RFC 2850 (especially section 2(d))
- RFC 3777 and its updates
- RFC 2860
- RFC 6220
- IETF-ICANN-MOU_2000
  (http://iaoc.ietf.org/documents/IETF-ICANN-MOU_2000.pdf)
- ICANN-IETF Supplemental Agreements
  (updated yearly since 2007, the 2014 version is available at
  http://iaoc.ietf.org/documents/2014-ICANN-IETF-MoU-Supplemental-Agreement-Executed.pdf)
COMMENT
Don't do "especially". Either the document is in effect or it is not.

I wonder whether this list of documents should be marked as non-
exclusive.
END

OLD
This working group is chartered solely with respect to the planning
needed for the transition.
COMMENT
What does this mean? I thought the working group was chartered to
produce a document that described "the interaction between the IETF
and the protocol parameters registries operator."
END

OLD
Possible improvements outside that scope
will be set aside for future consideration.  Avoiding alterations in
substantive outcomes should be the goal, even if eventual mechanisms
required to address the removal of the overarching NTIA contract
may require additional documentation or agreements.
COMMENT
"alterations in substantive outcomes" means what?
Google tranlate renders "Changes in the content of the results" via
German and "changes will result in significant" via Swahili.
I think you are trying to say that the goal is to leave in place as
many elements of existing processes and agreements as is possible.
Would it be possible to say what the goal actually is?
END

OLD
Should proposals made to the NTIA by other communities regarding the
transition of other IANA functions affect the protocol parameter
registries or the IETF, the WG will also review and comment on them.
NEW
Saying that the WG will comment implies that the WG will produce some
form of output. I'm not sure what you have in mind.

Saying that other proposal might affect the IETF is a very wide scope!
You had previously screwed this tight to say the WG was only working on
the protocol parameters part. This text opens it up to the full
transition discussion.

And you need to tighten "protocol parameters registries" to "IETF
protocol parameters registries".
END

OLD
The output document of the WG need not be the complete transition
proposal regarding the oversight of the protocol parameters registries
to be handed to the NTIA. Specifically, if that transition proposal
requires documentation of some detailed terms of agreements or other
details of procedures that are normally delegated to and handled by
the IAB or IAOC, the IAB or IAOC can provide those details as part of
the submission; the WG does not need to come to consensus on those
parts of the submission.
COMMENT
But presumably you intend that the WG does come to consensus on
the fact that it doesn't need to come to consensus?
END

OLD
The WG shall seek the expertise of the IAB IANA Strategy Program to
formulate its output. It is expected that members of the IAB IANA
Strategy Program will actively participate in the WG.

Milestones
==========

January 2015  -- complete protocol parameters registries proposal
May 2015 -- review of other transition proposals, if needed
Sept 2015 -- close
COMMENT
I should like to know to whom the WG delivers the complete proposal
and in what form.

I would also like clarity with regard to how the proposal delivered
by the WG is considered complete if additional work from the IAB and
IAOC is needed. Does that change the timeline?
END

[Ballot comment]
I think this version of the charter is fine to go for external review. The following comment can be held for final approval (and it won't be blocking even then), but if other changes get made during internal review, please consider:

In Tasks, the second and third paragraphs ("Given that we have a system today…" through "...may require additional documentation or agreements") seem like a really elaborate and somewhat obfuscated way of saying, "The WG shall not change the status quo". I think this could be simplified to:

  The document shall describe, either directly or by reference to
  existing documents, the different responsibilities and oversight
  roles of the IAB and IAOC, as well as the direct interactions between
  the IETF and the protocol parameters registry operator. The WG shall
  not change the current roles, responsibilities, and interactions in
  any substantive way. Rather, the WG is documenting the interactions
  that are not already explicitly called out in existing IETF
  documents, but which now need to be documented due to the elimination
  of the NTIA-ICANN contract.

  The WG may refer to the following documents, which will be presumed
  to continue to be in effect:

[List of documents]

That said, if the sponsoring AD and/or potential chairs think the more elaborate version is better (either because it gives more or less flexibility; I can't tell which it is), I certainly won't stand in the way. The current text is workable.

[Ballot comment]
As I commented in the discussion:

OLD
The WG will review, comment on, evaluate, and if need be prepare text
for a proposal about protocol parameters registries.

NEW
The WG will review, comment on, evaluate, and if need be prepare text
for a proposal about the oversight of the part of the IANA function that
administers the protocol parameters registries.

END