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

[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