Subject: [Ianaplan] Adrian Farrel's No Objection on charter-ietf-ianaplan-00-03: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 Aug 2014 11:40:10 -0700

Adrian Farrel has entered the following ballot position for
charter-ietf-ianaplan-00-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-ianaplan/

----------------------------------------------------------------------
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

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 20 Aug 2014 12:35:30 -0700

Putting in my two cents on Adrian’s comments.

>http://datatracker.ietf.org/doc/charter-ietf-ianaplan/

WFM, new text is as good as old.

>Useful to know between who the MoU was formed.

WFM

>in the previous paragraph.

Could do

s/the IANA function/maintenance of the IETF protocol parameters registries/

>Continuous ("has had") both indicates history and currency.

WFM

>valuable ""... to provide the IANA function."

WFM

>"transition" have no meaning without some context.

I would say s/complete the evolution begun in 1997/transition out of its
current role/

>"would not need to" is very ambiguous! Maybe it can't be avoided, but

The situation itself is ambiguous. If NTIA receives a satisfactory
proposal on time, it will not need to renew. But it has reserved the
ability to renew if that does not come to pass. So I think this language
should stay.

>and no or little transition activity will be required."

Actually, the ICG is heading in a direction where it will ask for
documentation of both existing arrangements and post-transition ones
(since it’s hard to evaluate a transition plan without understanding the
current arrangements). But the new text you suggest works for me.

>the operator of the registries that contain the protocol parameters for

I don’t think the change at the end of the sentence actually changes the
meaning (since there is only one IANA), and it makes the sentence harder
to read, but I’m fine with it if people think it helps.

>way that ensures continuation of the current arrangements.

I don’t really agree with most of the arguments you provide above for
changing this text, but I have no problems with the new text itself, save
one:

s/ensures/focuses on/

The old text left the WG a little more leeway by saying “focus on …
ensuring” and I don’t think that should be lost.

>Don't do "especially". Either the document is in effect or it is not.

Agree

>I wonder whether this list of documents should be marked as non-

I think that is obvious (we have 7000 other RFCs that remain in effect),
but I don’t think it hurts to add it.

>and the protocol parameters registries operator."

This is as opposed to making lots of other changes in how the IETF
interact with IANA. We could add that at the end of the sentence: “and is
not meant to cover other topics related to IANA."

>Would it be possible to say what the goal actually is?

I think the goal is stated earlier in the charter. This is where non-goals
are being discussed.

If the second sentence above is problematic, it could probably be removed
without harm.

>form of output. I'm not sure what you have in mind.

Perhaps it should say “possibly comment.” The WG will have a choice as to
whether to comment or not. And I think it will have the same choice of
format as any other WG — write an RFC, send emails, send a liaison
statement. I don’t think the format of comments that may or may not
materialize on documents that may or may not materialize needs to be
specified in the charter.

>the protocol parameters part. This text opens it up to the full

The IETF, and all parties interested in IANA, will be asked to review and
comment on the other components of the final transition proposal.
Personally, I think there should be a way for IETF participants to do
this, and an IETF WG is a good vehicle for that. I don’t think this text
opens anything up further than it should be open — we’re not asking the WG
to author a proposal for numbers or names, we’re saying the WG might want
to review or comment on other transition proposal components.

>protocol parameters registries".

Agreed

>part of the final proposal.

WFM

>Strategy Program will actively participate in the WG.

I think a shepherd delivers it to the IESG in I-D format, just like every
other I-D.

>IAOC is needed. Does that change the timeline?

I don’t think it changes the timeline. All of the interested parties
should be (and will be I’m sure) working together to make sure that any
IAB/IAOC-derived pieces are complete on the same timeline as the proposal
produced by the WG.

Alissa 

>
>
>_______________________________________________
>Iana-strategy mailing list
>[email-masked]
>http://lists.i1b.org/listinfo.cgi/iana-strategy-i1b.org

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 Aug 2014 23:01:33 +0100

Thanks for this, Alissa.

> s/the IANA function/maintenance of the IETF protocol parameters registries/

Yes, that works, but it felt like there was a wider intention.

> I would say s/complete the evolution begun in 1997/transition out of its

I like that.

> ability to renew if that does not come to pass. So I think this language

Well, it probably doesn't change what the WG will do, so keep it.

[snip]

> ensuring” and I don’t think that should be lost.

Well, I don't mind you disagreeing if we end up with the text I like :-)

[snip]

> not meant to cover other topics related to IANA."

OK, I think I see the purpose of the text, but the words are a problem: "with respect to the planning needed for the transition" just sounds lumpy.
 I'd even go with "with respect to the tasks listed above".

Adding your coda would be fine.

> I think the goal is stated earlier in the charter. This is where non-goals

But the old text is phrased as the statement of a goal.
I don't mind this being a statement of goals or non-goals or things that are out of scope, but I would like it to be meaningful!

> If the second sentence above is problematic, it could probably be removed

That works for me, but I suspect that it is there because someone had something they thought should be said.

> specified in the charter.

So you agree on "some form of output" and my concern is the consensus process involved as well as the decision as to which other proposals will be reviewed and which deserve comments.

> to review or comment on other transition proposal components.

OK, so the scope is intentionally wide, and you think it should be wider than "affect the IETF" (i.e., all).
But, you say "other components of the final transition proposal" and the text says "proposals made by other communities." There is at least a time difference there, but also one of filtering.

[snip]

> I think a shepherd delivers it to the IESG in I-D format, just like every

OK.
We normally express these millstones as "Submit foo for IESG review and publication as an RFC"

> IAB/IAOC-derived pieces are complete on the same timeline as the proposal

Okey-dokey. I guess the relevant people will be monitoring and will see that they need to start to generate text in time.

Cheers,
Adrian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Aug 2014 17:55:23 +0300

Thanks Adrian, and Kathleen - That was useful, and I think Alissa’s suggested changes work for me. I’m working on accommodating those comments and Eric’s comments into a new clean version, once I have all comments from the IESG (= now).

Jari

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 22 Aug 2014 07:30:27 -0700

Just checking whether Olaf and Pete are talking past each other:

Olaf, were you referring to the complete proposal that includes components
for names, numbers, and protocol parameters?

Pete, were you referring to the final IETF proposal that only addresses
protocol parameters?

My impression is that the answers to both of those questions are yes, but
I’m not sure.

Alissa

On 8/22/14, 5:56 AM, "Olaf Kolkman" <[email-masked]> wrote:

> 
> On Aug 22, 2014, at 2:46 PM, Pete Resnick <[email-masked]> wrote:
> 
>> On 8/22/14 6:34 AM, Olaf Kolkman wrote:
>>> How will we judge IETF consensus on that final proposal? Through the WG
>>> first and then through an IETF last call?
>>> 
>>> I would think that if the final proposal hits the IETF list it will be more
>>> or less immutable and there will be a request for a boolean: can we live
>>> with this. Not a call for bringing up new issues. I guess that all takes
>>> place at an earlier stage when draft proposals (for the other legs) hit the
>>> WG? Is that correct?
>> 
>> No, that's not correct. We should be collecting issues and assessing
>> consensus all along the process. If the proposal makes it to IETF Last Call
>> and a new issue gets brought up, the issue will be discussed and we'll
>> determine if there is rough consensus that the issue is serious enough to
>> "stop the show". This is just like any other document, except in this case we
>> had better take very seriously the responsibility of the consensus caller to
>> drive that consensus (which we are very lax about on most documents).
>> 
>> Of course, in effect asking whether any particular issue is a showstopper
>> *is* to ask whether we can live with the current proposal. But there is
>> nothing different in doing that than we (should) do for any other consensus
>> call.
> 
> 
> I think we are in sync.
> 
> To put in my own words:
> 
> If convergence on a final document within the coordination group has been
> reached (which should have as input a IETF consensus document) then an IETF
> last call on that document can bring up new issues and we have to address
> whether they are show-stoppers or not.
> 
> —Olaf
> 
> 
> 
> 
> —————————— 
> Olaf Kolkman
> Internet Society
> Chief Internet Technology Officer
> [email-masked]  www.isoc.org <http://www.isoc.org>
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Aug 2014 20:32:19 +0200

On 8/22/14, 6:07 PM, Olaf Kolkman wrote:
> In addition, the fair warning I started of could still be helpful. The
> coordination group reps will bring the current state of other
> proposals back into the WG, and it is better that they are discussed
> there in a timely fashion rather than at the tail end because there is
> less opportunity to actually influence the words of the end-result.
> That is what I was trying to get at with the fair warning, if you are
> interested, go to the WG, don’t wait till the end (just as our normal
> process I recon).
>

It will be very important that our proposal is WIDELY circulated as we
are developing it.  It would even be my perference if we, the RIRs, and
the various SOs could stitch together something complete for the ICG's
approval.  We would rather have objections within our process than
outside of it.  I think that gives our appointees more ammo to say,
“well, did you raise your concerns through the open processes that were
available to you?”

Eliot

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Fri, 22 Aug 2014 15:50:52 -0400

In fine IETF tradition, there's no point in replying unless I disagree 
with something; it's taken a bit of work to find something to disagree 
with ;-)  And, even so, I think it's just a different path to agreement.

Having been on the other side of the OpenStand development, let me just 
say that I think this is good and important advice for the current 
process.

In retrospect, it was quickly clear that the OpenStand text could have 
been a lot better if it had had an open and proper review (i.e., it's 
not just about process; the process is there for a reason!).  But, it 
wasn't clear how to engineer that given all the moving parts.

So, making sure discussion of this is open but _not_untended_ seems 
rational.  And making sure the WG actually sticks to its charter (which, 
in my reading anyway, leaves latitude for the IAB to make the decisions 
it needs to make) will be important, too.

Can't see what I disagree with? ;-)  I don't think it's important to 
give the community more than a "take it or leave it" choice for process 
reasons.  I think it's important because it can produce a better outcome.

Leslie.

On 8/22/14 10:46 AM, Pete Resnick wrote:
> On 8/22/14 9:30 AM, Alissa Cooper wrote:
>> Olaf, were you referring to the complete proposal that includes
>> components for names, numbers, and protocol parameters?
>>
>> Pete, were you referring to the final IETF proposal that only
>> addresses protocol parameters?
>>
>> My impression is that the answers to both of those questions are yes,
>> but I’m not sure.
>
> No, I also meant the proposals from the names and numbers folks. And I
> agree with Olaf's summary:
>
>> On 8/22/14, 5:56 AM, "Olaf Kolkman" <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> I think we are in sync.
>>>
>>> To put in my own words:
>>>
>>> If convergence on a final document within the coordination group has
>>> been reached (which should have as input a IETF consensus document)
>>> then an IETF last call on that document can bring up new issues and
>>> we have to address whether they are show-stoppers or not.
>
> Exactly. What we don't want to do is behave as if we are varying from
> our normal activities. What we *will* vary is how strongly we drive the
> consensus call, both when the WG is reviewing and when that review goes
> to IETF Last Call. We have to have participants ready to say, "Yeah,
> maybe that's not ideal, but it's not wrong enough to ask the ICG to go
> back and re-work it", and we have to have the consensus caller declare
> things in the rough decisively.
>
> My only concern is that we don't put ourselves back into the OpenStand
> debacle, where we say to the community, "You only get to say 'yes' or
> 'no'." We can say to the community, "You get to bring up issues the way
> we do with any consensus call in the IETF, but you had better make your
> case clearly and crisply that the issue is a serious one and not just a
> personal preference, because we're not going to let the discussion
> prattle on the way we often do." But I don't even think we need to say
> that; I think we can just do it.
>
> pr
>
> --
> Pete Resnick<http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>
>
>