Subject: [Ianaplan] scratch proposal for a charter

From: Andrew Sullivan <[email-masked]>
Date: Thu, 17 Jul 2014 05:58:50 -0400

Dear colleagues,

I think I offered to send this two days ago.  Please indulge me by
taking remarks about the road to perdition, good intentions, and so on
as read.  I apologise.  Have at it. 

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Jul 2014 08:10:28 +1200

Andrew,

I think this is reasonable. There is one overarching comment, which
I don't think needs to be mentioned in the charter text unless
people don't find it obvious: any agreements between the IAB and
IANAng, or any agreements between the IAOC and IANAng, will be the
result of mutual negotiation. So whatever the proposed WG proposes
cannot be binding on the IAB or IAOC - the final agreement(s) will
be the result of negotiation and legal review.

Regards
   Brian

On 17/07/2014 21:58, Andrew Sullivan wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan

---

From: Larry Masinter <[email-masked]>
Date: Thu, 17 Jul 2014 21:34:02 +0000

There were some "Happy IANA" discussions a few years ago, about the difficulties of current registries (mainly application layer) to keep up with and match reality, especially URI schemes, MIME types, and charsets.

The recent W3C "Encodings" spec which claims to obsolete or otherwise modify the IANA charset registry is an example of how the IANA registry isn't meeting some needs.

I'd like any discussion of IANA transition to explore opportunities for application of additional resources to address the issues raised, by removing the assumption that IANA's functions are exactly what we need, with any additional support requiring overwhelming agreement before any changes are considered.

-----Original Message-----
From: Ianaplan [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Thursday, July 17, 2014 1:10 PM
To: Andrew Sullivan
Cc: [email-masked]
Subject: Re: [Ianaplan] scratch proposal for a charter

Andrew,

I think this is reasonable. There is one overarching comment, which I don't think needs to be mentioned in the charter text unless people don't find it obvious: any agreements between the IAB and IANAng, or any agreements between the IAOC and IANAng, will be the result of mutual negotiation. So whatever the proposed WG proposes cannot be binding on the IAB or IAOC - the final agreement(s) will be the result of negotiation and legal review.

Regards
   Brian

---

From: Ted Hardie <[email-masked]>
Date: Thu, 17 Jul 2014 15:46:58 -0700

Hi Larry,

Some comments in-line.

On Thu, Jul 17, 2014 at 2:34 PM, Larry Masinter <[email-masked]> wrote:

> There were some "Happy IANA" discussions a few years ago, about the
> difficulties of current registries (mainly application layer) to keep up
> with and match reality, especially URI schemes, MIME types, and charsets.
>
> The recent W3C "Encodings" spec which claims to obsolete or otherwise
> modify the IANA charset registry is an example of how the IANA registry
> isn't meeting some needs.
>
> I'd like any discussion of IANA transition to explore opportunities for
> application of additional resources to address the issues raised, by
> removing the assumption that IANA's functions are exactly what we need,
> with any additional support requiring overwhelming agreement before any
> changes are considered.
>
>
​My take on the URI scheme issues at least (and broadly the other issues)
is that there are communities that feel the IETF isn't doing the right
thing here, not that IANA isn't.  IANA doesn't have any expertise in these
registries--it takes the direction on structure and what entries to include
from the IETF.

While I think there are issues there, I don't think this process​ is the
right one to take on those issues.  This is about the IANA operator, not
the failures in the instructions IETF may have sent IANA.  Let's not
conflate the two.

Ted

> I think this is reasonable. There is one overarching comment, which I
> don't think needs to be mentioned in the charter text unless people don't
> find it obvious: any agreements between the IAB and IANAng, or any
> agreements between the IAOC and IANAng, will be the result of mutual
> negotiation. So whatever the proposed WG proposes cannot be binding on the
> IAB or IAOC - the final agreement(s) will be the result of negotiation and
> legal review.
>
> Regards
>    Brian
>

---

From: Larry Masinter <[email-masked]>
Date: Thu, 17 Jul 2014 22:56:28 +0000

The IETF will not instruct IANA to do something IANA isn’t capable of under its contract.

For example, could IANA run analytics on its web pages, or survey a sample of IANA users, or ask for feedback,  or experiment with annotation and crowd-sourcing applications for commentary on implementation?

While the details of exactly what to do and how to do it may not be in scope, I think it shouldn’t be assumed that IANAs  functions will remain unchanged. What will be the process for driving change here? I think that’s relevant to iana transition plans.

Larry
--
http://larry.masinter.net

From: Ted Hardie [mailto:[email-masked]]
Sent: Thursday, July 17, 2014 3:47 PM
To: Larry Masinter
Cc: Brian E Carpenter; Andrew Sullivan; [email-masked]
Subject: Re: [Ianaplan] scratch proposal for a charter

Hi Larry,
Some comments in-line.

On Thu, Jul 17, 2014 at 2:34 PM, Larry Masinter <[email-masked]<mailto:[email-masked]>> wrote:
There were some "Happy IANA" discussions a few years ago, about the difficulties of current registries (mainly application layer) to keep up with and match reality, especially URI schemes, MIME types, and charsets.

​My take on the URI scheme issues at least (and broadly the other issues) is that there are communities that feel the IETF isn't doing the right thing here, not that IANA isn't.  IANA doesn't have any expertise in these registries--it takes the direction on structure and what entries to include from the IETF.

While I think there are issues there, I don't think this process​ is the right one to take on those issues.  This is about the IANA operator, not the failures in the instructions IETF may have sent IANA.  Let's not conflate the two.

Ted

-----Original Message-----
From: Ianaplan [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E Carpenter
Sent: Thursday, July 17, 2014 1:10 PM
To: Andrew Sullivan
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ianaplan] scratch proposal for a charter

Andrew,

Regards
   Brian

On 17/07/2014 21:58, Andrew Sullivan wrote:
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Ianaplan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ianaplan

_______________________________________________
Ianaplan mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ianaplan

---

From: Ted Hardie <[email-masked]>
Date: Thu, 17 Jul 2014 16:12:06 -0700

On Thu, Jul 17, 2014 at 3:56 PM, Larry Masinter <[email-masked]> wrote:

> For example, could IANA run analytics on its web pages, or survey a sample
> of IANA users, or ask for feedback,  or experiment with annotation and
> crowd-sourcing applications for commentary on implementation?
>
>
​If the IETF asked it to, it would be required to do so; that's what
"instructs" boils down to.    I'm not sure why you've inverted that in the
first step; the IETF can choose to instruct to IANA to develop new
capabilities or not to so instruct it (for cost reasons, as an example),
but the key thing is that it is the
IETF's choice.​

>
>
> While the details of exactly what to do and how to do it may not be in
> scope, I think it shouldn’t be assumed that IANAs  functions will remain
> unchanged. What will be the process for driving change here? I think that’s
> relevant to iana transition plans.
>

​You didn't quite say so, but m​
y guess is that you are reading this:

Because of the importance of
stability, an arrangement that makes as few alterations to the
historical way the protocol parameters registries are operated will be
preferable.

much more deeply than it is meant.

​Perhaps the phrase "historical way the protocol parameters registries are
operated" needs re-phrasing because I think we mostly mean "the ietf
specifies the registries and identifies experts where it has required them;
the IANA populates the registries as directed"​.  That boils down to the
IANA not being expected to provide the technical expertise on what goes in
the registries and the IETF not getting in IANA's kitchen over details like
what database the backend runs.

Ted

> *From:* Ted Hardie [mailto:[email-masked]]
> *Sent:* Thursday, July 17, 2014 3:47 PM
> *To:* Larry Masinter
> *Cc:* Brian E Carpenter; Andrew Sullivan; [email-masked]
>
> *Subject:* Re: [Ianaplan] scratch proposal for a charter
>
>
>
> Hi Larry,
>
> Some comments in-line.
>
>
>

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 17 Jul 2014 20:04:19 -0400

On Jul 17, 2014, at 7:12 PM, Ted Hardie <[email-masked]> wrote:

> ​You didn't quite say so, but m​y guess is that you are reading this:
> 
> ​Perhaps the phrase "historical way the protocol parameters registries are operated" needs re-phrasing because I think we mostly mean "the ietf specifies the registries and identifies experts where it has required them; the IANA populates the registries as directed"​.  That boils down to the IANA not being expected to provide the technical expertise on what goes in the registries and the IETF not getting in IANA's kitchen over details like what database the backend runs.
> 
> Ted

I think the suggested razor here is "If it doesn't have to change just because NTIA is leaving the room, we should think very hard, twice or more, about addressing it now or as part of this process."

Leaving it up to the IETF to change its instructions to IANA on protocol parameters registries should the IETF deem it necessary is of course a perfectly reasonable thing to do, and always has been. There's no reason to believe that NTIA leaving its contract with ICANN for the IANA functions would change that, since the relevant contract language today more or less instructs IANA to do as it's told by the IETF and so does RFC 2860 (exact language escapes me at the moment).

Preserving the current overall ability of the IETF to change things in the future as needed is critically important, and thus probably shouldn't go without saying. I'd be deeply shocked if the ianaplan activity proposed anything that would *reduce* the IETF's current (high) level of control over IANA's work on its registries, and I'd expect that the chances of the IAB/IAOC abiding by such a recommendation to approach zero.

However, it does also seem that there's no particular need to address specifics of "things we might want to change unrelated to the end of the NTIA contract" here and now, and there's some potential risk in opening a wider process than necessary. For the IETF at least, there's no reason for the end of the ICANN/NTIA contract to be a major change, and the biggest challenge may be in keeping it that way.

After many years of experience with ICANN and even more with the IETF, I support the principle of keeping this activity as simple as reasonably possible.

best,
Suzanne

---

From: Eric Burger <[email-masked]>
Date: Thu, 17 Jul 2014 20:09:13 -0400

First, a +1 to Brian’s comment.  The agreement was and undoubtably will be a contractual negotiation of terms.

Second, I very much agree with the charter text:
  The WG will review, comment on, evaluate, and if need be prepare text
                                                ^^^^^^^^^^^
  for a proposal about protocol parameters registries.

I highlight the “if need be.”  I do this because the milestones read as if the charter said:
  The WG will review, comment on, evaluate, and WILL prepare text
  for a proposal about protocol parameters registries.

This comes from my interpretation of the milestone
  March 2015  -- complete protocol parameters registries proposal

I would rather have something like:
  Mar 2015  -- complete protocol parameters registries needs and agreements review
  May 2015 -- review of other transition proposals, if needed
  Jun 2015  -- complete protocol parameters registries proposal, if needed
  Sep 2015 -- complete other transition proposals, if needed, or close
  Dec 2015 -- close, if still open

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Jul 2014 08:34:01 +0200

Hi,

> I think the suggested razor here is "If it doesn't have to change just because NTIA is leaving the room, we should think very hard, twice or more, about addressing it now or as part of this process…

Yes.  There are many moving parts right now, and the operations of IANA
work.  Therefore, the primary area I think we need to cover to satisfy
Larry's point is to ensure we have a path for making changes in the
future, should we deem that necessary.  That's not that hard.

In answer to Eric (in part), there is one area I do think we will need
to cover this time around, an that is metrics reporting.  That is NOT
covered by RFC 2860 but IS covered by the contract, although my
understanding is that the IAB had a lot to say about the current
requirements.  Again, including those reporting requirements in our
proposals should not be difficult, since they're being followed today. 
And again, a mechanism for changes should be also not difficult.  But
this is worth keeping track of.

Eliot

---

From: JFC Morfin <[email-masked]>
Date: Fri, 18 Jul 2014 09:26:00 +0200

I agree with Andrew's charter and specially with "a proposal about 
protocol parameters registries" plural for registries. IMHO there 
should not be particular IETF/IANA final negociations (no problem 
about informal ones as part of MS process with the various type of registies).

I agree with Andrew about a minimal change. However I would add the 
exploration of an ***additional*** IANA dissemination protocol, For 
example under the form of a json oriented solution.

I think his list of documents should be kept open, in case some 
additions may become necessary or the ICANIANA process produces some 
dratfs. It would also be interesting to compile all the currently 
active IANA sections into a working document and try to sort them in 
terms of corresponding functor types. This may sound a boring task 
but could help with interesting insights concerning the real needs 
when considering some possible evolution?

This might also help identfying the situations where Larry might be 
right and Ted is right. There is already a basic functor: when there 
is nothing of interest for the IANA. I suppose others might emerge.

jfc

At 00:46 18/07/2014, Ted Hardie wrote:
>Hi Larry,
>
>Some comments in-line.
>
>On Thu, Jul 17, 2014 at 2:34 PM, Larry Masinter 
><<mailto:[email-masked]>[email-masked]> wrote:
>difficulties of current registries (mainly application layer) to 
>keep up with and match reality, especially URI schemes, MIME types, 
>and charsets.
>The recent W3C "Encodings" spec which claims to obsolete or 
>otherwise modify the IANA charset registry is an example of how the 
>IANA registry isn't meeting some needs.
>I'd like any discussion of IANA transition to explore opportunities 
>for application of additional resources to address the issues 
>raised, by removing the assumption that IANA's functions are exactly 
>what we need, with any additional support requiring overwhelming 
>agreement before any changes are considered.
>
>
>â€‹My take on the URI scheme issues at least (and broadly the other 
>issues) is that there are communities that feel the IETF isn't doing 
>the right thing here, not that IANA isn't.Â  IANA doesn't have any 
>expertise in these registries--it takes the direction on structure 
>and what entries to include from the IETF.Â
>
>While I think there are issues there, I don't think this processâ€‹ 
>is the right one to take on those issues.Â  This is about the IANA 
>operator, not the failures in the instructions IETF may have sent 
>IANA.Â  Let's not conflate the two.
>
>Ted
>Â
>
>Cc: <mailto:[email-masked]>[email-masked]
>Â  Â Brian
> > I think I offered to send this two days ago. Â Please indulge me by
> > as read. Â I apologise. Â Have at it.
> >
> > Best regards,
> >
> > A
> >
> >
> >
> > <mailto:[email-masked]>[email-masked]
><mailto:[email-masked]>[email-masked]
><mailto:[email-masked]>[email-masked]

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Fri, 18 Jul 2014 10:17:54 -0400

Agreed.

> historical way the protocol parameters registries are operated will be

the charter could read:

This work is chartered exclusively to propose alterations that are 
needed in order to support the transition of stewardship of the IANA 
functions.  Other possible improvements will be set aside for future 
consideration.

Leslie.

---

From: Eric Burger <[email-masked]>
Date: Fri, 18 Jul 2014 17:10:40 -0400

Agreed. This whole proposal sounds like the United / Continental IT systems merger, where they decided that merging two of the largest public-facing transactional systems AND changing the business rules AND changing the technology all at the same time was a good idea. The result was no flights for two half days. Not a good plan.

On Jul 18, 2014, at 10:17 AM, Leslie Daigle (TCE) <[email-masked]> wrote:

> This work is chartered exclusively to propose alterations that are needed in order to support the transition of stewardship of the IANA functions.  Other possible improvements will be set aside for future consideration.
> 
> Leslie.
>

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 18 Jul 2014 22:16:06 -0400

Eric,

No, it doesn't, yet. The immediate task at hand is to keep it that way. :)

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 20 Jul 2014 14:36:10 -0400

Dear colleagues,

On the basis of the discussion I've seen on list, I've updated the
charter.  Note that I have generally preferred the path, suggested by
many, of minimising rather than including changes.

Major changes include adopting Leslie's suggested text; a (rather
awkwardly written -- suggestions welcome) paragraph noting that the WG
can't just come to consensus on contract terms; and a change of the
complete proposal milestone to move it back into January, on the
grounds that this is all supposed to be trivial so moving stuff
earlier would be good, and gives others more time to respond.

Best regards,

A

Scratch proposal: Charter for IANAPLAN WG
version 2014-07-20a

Area: General
Responsible AD: Jari Arkko
Chairs: TBD

Background
==========

The IETF maintains 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.  

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.

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.

Tasks
=====

The WG will review, comment on, evaluate, and if need be prepare text
for a proposal about protocol parameters registries.  It will begin
with the following documents:

- RFC 2850 (especially section 2(d))
- RFC 2860
- RFC 6220
- IETF-ICANN-MOU_2000
    (http://iaoc.ietf.org/documents/IETF-ICANN-MOU_2000.pdf)
- IETF-ICANN Supplemental Agreement Dec 2007
    (http://iaoc.ietf.org/documents/IETF-ICANN_Supplemental_Agreement.pdf)
- IETF-ICANN Supplemental Agreement March 2008
    (http://iaoc.ietf.org/documents/IETF-IANA_%20MoU_Supplemental_Agreement_2008.pdf)
- ICANN-IETF Supplemental Agreement March 2009
    (http://iaoc.ietf.org/documents/ICANN-IETF-SLA-2009-Executed.pdf)
- ICANN-IETF Supplemental Agreement 2010
    (http://iaoc.ietf.org/documents/ICANN-IETF-SLA-2010-Executed.pdf)
- ICANN-IETF Supplemental Agreement 2011
    (http://iaoc.ietf.org/documents/ICANN-IETF-Agreement-2011-Executed.pdf)
- ICANN-IETF Supplemental Agreement 2012
    (http://iaoc.ietf.org/documents/ICANN-IETF-Agreement-2012-Executed.pdf)
- ICANN-IETF Supplemental Agreement 2013
    (http://iaoc.ietf.org/documents/2013-ICANN-IETF-MoU-Supplemental-Agreement-Executed.pdf)
- ICANN-IETF Supplemental Agreement 2014
    (http://iaoc.ietf.org/documents/2014-ICANN-IETF-MoU-Supplemental-Agreement-Executed.pdf)

It may consider, but is not bound to use,
draft-kolkman-iana-framework-00.  It is likely that RFC 3777 and its
updates are also implicated.

The WG will also review, comment on, and evaluate proposals from other
communities about the NTIA transition, to the extent that those
proposals impinge on the protocol parameters registries.

The results of any WG consensus on protocol parameters registries
will, of necessity, be input but not necessarily firm restrictions on
any contractual terms that are ultimately adopted by the IAB and any
future IANA functions provider, or contractual terms ultimately
adopted by the IAOC and any future IANA functions provider.
Statements of principle and desired outcomes are more important items
to be delivered by the working group than are detailed terms for
future agreements.

Milestones
==========

January 2015  -- complete protocol parameters registries proposal
May 2015 -- review of other transition proposals, if needed
Sept 2015 -- close

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Burger <[email-masked]>
Date: Sun, 20 Jul 2014 14:57:11 -0400

How about combining the first and third paragraphs (copied below), into something like the paragraph after the copied text?

As for the second paragraph, is that not the domain of the IAB?  The IAB can feel free to ask the IESG to charter a work group, or include in our charter, the review, evaluation, and commenting job.  However, that has infinite scope and is already the IAB’s day job to handle.  I do not think it belongs here.

> to be delivered by the working group than are detailed terms for

The charter of this work is exclusively to propose alterations, if any are required, of the existing agreements to the IAB, IAOC, or other negotiating body on behalf of the IETF to support the transition of stewardship of the IANA functions. As such, statements of principle and desired outcomes are important items for the work group to deliver, as opposed to detailed terms for future agreements.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Jul 2014 18:27:33 -0400

> How about combining the first and third paragraphs (copied below), into something like the paragraph after the copied text?

I'm not opposed.  Anyone else have an opinion?

> As for the second paragraph, is that not the domain of the IAB?  The IAB can feel free to ask the IESG to charter a work group, or include in our charter, the review, evaluation, and commenting job…

I think it has to stay, though normally I'd agree with you.  Because
of the (for our purposes) unusual way that the Coordination Group is
working, the IETF has appointed people to it and the CG and NTIA are
explicitly asking for "IETF opinion".  The way we ask the IETF's
opinion is consensus calls; so even though normally I'd say that this
is properly an IAB thing, I think in this particular case the IETF
needs a way to speak.

Best regards,

A (as usual, speaking for myself)

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Jul 2014 02:16:41 +1200

> with the following documents:

I think that last sentence is problematic, because (as hinted in the BOF)
it might appear to open the documents for amendment. Try:

The following existing documents and contractual documents provide
background for the discussion:

  Brian

---

From: Eric Burger <[email-masked]>
Date: Thu, 24 Jul 2014 10:48:46 -0400

Like it.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 24 Jul 2014 15:41:55 +0000

> Other possible improvements will be set aside for future consideration.

It is inappropriate to "set aside" other possible improvements, much less consideration of them, to some indefinite place and time in the future. I think the idea is to make such improvements out of scope for this working group.

I kind of like:
"Improvements to IANA function, processes and procedures are out of scope of this working group except to insure no contractual changes reduce the possibility of timely consideration and implementation."

Examples of improvements: survey, analytics, research into IANA registries usage. Publishing IANA registry data in JSON. Provisions for IANA be used by other SDOs.  Using crowd-source mechanisms to gather annotations, comments, proposed updates, errata. Especially for registries where those making entries are not IETF cognoscenti -- HTTP headers, URI schemes, Media Types, or where users need to know not only the official approved values but also what is supported or used in deployed software.

Larry

---

From: Eric Burger <[email-masked]>
Date: Thu, 24 Jul 2014 13:00:29 -0400

Larry is quite right here. We should not say, “Our relationship with IANA is perfect - no need to look here.” We should say something more like, “Our relationship with IANA is satisfactory. This work group will focus only on the transfer of the IANA contract away from the NTIA. Any other work, such as <brief enumerated list> is out of scope for this Work Group.”

I would include the brief enumerated list, like Larry’s below, so people do not bring those items to this work group.