Subject: Re: [Ianaplan] A draft for your review

From: Andrew Sullivan <[email-masked]>
Date: Mon, 1 Sep 2014 11:41:38 +0300

Hi,

On Sat, Aug 30, 2014 at 03:29:34PM +0200, Richard Hill wrote:
> 
> I think that it would be better to include the full mandate, and to say: "In that announcement, NTIA asked the Internet Corporation for Assigned Names and Numbers (ICANN) to establish a process to deliver a proposal to transition key Internet domain name functions to the global multistakeholder community." 
> 

What does that add?  In particular, that suggests that the only think
NTIA was interested in was domain name functions, in which case the
protocol parameters registry would be irrelevant.  But we cannot
possibly read it that narrowly, of course, since the protocol
parameters are also in some sense covered by the NTIA-ICANN agreement.

> function is the Internet Engineering Task Force (IETF), which acts
> on behalf of the numerous implementers that use specific parameter
> values."

I would be strongly opposed to such a change.  The IETF does not act
"on behalf" of anyone.  We are not a representative body.  The IETF
acts for itself.

> 4) Related to the above, should consideration be given to adding a
> proper dispute resolution clause, that is, including choice of law
> and venue, to the agreement?  For example, that the venue for any
> disputes would be the seat of ISOC, which is the legal entity
> involved from the IETF side.

This suggests that the IETF's responsibility for these protocol
parameters should be submitted to some other body for arbitration.  I
don't think that's correct.  

> 6) In section 2, part IV, under "Transition Implications", the IETF response is "No structural changes are required." This is correct, but I think that some contractual changes are required in order to make it clear that the ultimate authority for the protocol parameters is IETF, not ICANN.
> 

> "At present, article I.1 of the ICANN Bylaws implies that ICANN has
> the overall responsibility for the coordination and allocation and
> assignment of the protocol parameters.

I don't read the Bylaws that way, and I don't think it's a plausible
interpretation.  The text says, "Coordinates the allocation and
assignment of the three sets of unique identifiers for the Internet,"
which does not imply overall responsibility for the allocation at all.
Overall responsibility is for co-ordination, which is, in my view,
exactly right.

> 7) There was extensive discussion (but no agreement) on the IANA
> Transition mailing list regarding whether or not the fact that a US
> court could, in theory, order ICANN/IANA to do something contrary to
> agreed community policies is an issue

Yes, of course.  US (and other countries') courts make bad rulings all
the time.  I don't think that the correct question is, "Is this an
issue?"  The correct question is whether it is an issue worth dealing
with in advance, particularly since it is hard ot know exactly how we
ought to deal with it.  In my view, the answer is, "No."  I think
there is at least as great a threat from creating another new large
bureaucracy as there is from some court issuing a bad decision that
affects us in an important way.

-- 
Andrew Sullivan
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Sun, 31 Aug 2014 19:35:33 -0700

Hi Eric,
At 11:42 31-08-2014, Eric Burger wrote:
>I like the humor, like the MIB dig. However, for the substantive 
>comments, we should fix.

:-)

>I think the disconnect is /direction/ for the IANA protocol 
>parameters function comes from the IETF, which is an embodiment of 
>the Internet technical community. The /input/ for the function is 
>capably provided, not the /function/ itself. The language needs fixing.
>
>How about:
>The Internet technical community, through the IETF, has in the past 
>and for the foreseeable future will provide direction to the IANA 
>protocol parameter registry.

The stated position is:

   "The IETF Protocol Parameter Registry function is undertaken under the
    auspices of the Internet Architecture Board."

The above basically says that the IETF considers that function as an 
IETF matter.  If you (used in the general sense) call it "IANA 
protocol parameters function" it is no longer an IETF matter.

One of the questions I asked was about the "Internet technical 
community".  The problem with using the term is that it is 
ill-defined.  I'll step back; there was a discussion about "global 
multistakeholder community" on this mailing list around the beginning 
of this month.  It was concluded that it is better to use the term 
"Internet community".

My reading of the question is that it is about the IETF Community's 
use of the IANA functions.  The less difficult way to answer that is 
to build from RFC 6220 (and the relevant BCPs if that is 
necessary).  I am taking into account the arguments that the IETF or 
the IAB has made previously.  It make sense to be consistent or have 
an explanation for a change in direction or else there will be a loss 
of credibility.

>It is not that it is not aligned with the stated position of the 
>IETF, it is that it is the IETF community, including implementers, 
>"the IETF's primary users of the IETF
>  standards and other documents," that use the IANA protocol 
> parameter registries. How about:
>
>Many IETF protocols make use of commonly defined protocol 
>parameters. Implementers use these parameters. Implementers are the 
>IETF's primary users of the IETF standards and other documents.  A 
>globally available registry contains the parameter values and a 
>pointer to documentation of the associated semantic intent. This 
>registry, the IANA protocol parameter registry, provides this 
>service to ensure consistent interpretation of these parameter 
>values by independent implementations.

The above looks better.  It uses the term IANA protocol parameter 
registry though.  Please see my previous comment about that.

>RIR and ICANN people regularly come to IETF meetings, which means 
>they participate. As we say, in-person attendance is not required 
>for participation. Likewise, email discussions are also not required 
>for participation. Thus, there is no inconsistency. Moreover, 
>participation does not require posting. I will bet there are a lot 
>of ICANN and RIR people subscribed (i.e., participating) to IETF email lists.

The point was that:

   (i)  It is possible to argue either way, i.e. people participate
        or people do not participate.

   (ii) It does not add anything substantive to the response.

What you (used in the general sense) could do here is to explain that 
there is coordination and how it is being done when there is an overlap.

>See my other note to Richard.

Thanks, I read that.  From RFC 6220:

   "Any intellectual property rights of the IETF protocol parameter
    assignment information, including the IETF protocol parameter
    registry and its contents, are to be held by the IETF Trust."

The IETF Trust is based in the Commonwealth of Virginia.  There is 
also the following:

   "In addition, the IAOC has the responsibility to ensure long-term
    access, stability, and uniqueness across all such registries.  This
    responsibility is of particular significance in the event that a
    relation with a Protocol Parameter Registry Operator is terminated."

And this is the proposed IETF response:

   "Because of the nature of the agreement, questions of jurisdiction are
    immaterial."

Mr Hill commented about disputes arising out of the agreement in his 
message.  I don't think that is an issue as it is covered in the 
agreement.  Mr Huston commented about an issue on March 13 which I'll 
quote (out of context):

   "I have absolutely no idea whether a) the IETF itself is an ISOC activity
    per se and b) issues about the intellectual property rights associated
    with the protocol parameter registry contents vest with any of the
    preceding bodies."

There has already been some public discussion about (b).  I have not 
seen any answer to it.  I am okay if the IETF says that intellectual 
property rights are not important.

>How? Any text for what you think it is / should be?

It's an IAB matter.  The term "IETF process" may or may not cover 
that.  There is already the following as part of the response:

   "RFC 6220 specifies the role and function of the protocol parameters
    registry, which is critical to IETF standards processes and IETF
    protocols.  The IAB, on behalf of the IETF, has the responsibility to
    define and manage the relationship with the protocol registry
    operator role.  This responsibility includes the selection and
    management of the protocol parameter registry operator, as well as
    management of the parameter registration process and the guidelines
    for parameter allocation."

In my opinion it is a matter of fitting that into the response.

As a general comment, there is the following under "required proposal 
elements":  "associated references to source documents of specific 
policies/practices".  A plausible response would be one which could 
be substantiated with references.  Otherwise (in my opinion), it will 
look like the IETF is not comfortable with what it has written.

Regards,
S. Moonesamy

---

From: Eliot Lear <[email-masked]>
Date: Mon, 01 Sep 2014 16:10:18 +0200

Hi SM,

On 8/30/14, 4:38 PM, S Moonesamy wrote:
> Hi Eliot,
> At 00:32 30-08-2014, Eliot Lear wrote:
>> I have posted a -00 draft that seeks to respond to the most current
>> version of the RFP I could get my hands on.  Would you kindly provide
>> some thoughts about it?  I am most particularly concerned about
>> substance at the moment.  The sorts of things I'm looking for are these:
>> Is the text in the "IETF Response" accurate and in fact responsive to
>> the question?
>> Is there anything missing?
>> Is there anything that does not parse well?  Did you think "Huh??"
>> when you read a sentence?
>> My intent is to have a second version out prior to the cutoff for the
>> Honolulu meeting as a candidate for the IANAPLAN working group to
>> adopt, assuming the working group is chartered.
>
>   "The IETF is a global voluntary standards organization whose goal is
>    to make the Internet work better [RFC3595]."
>
> The IETF cannot be a MIB module. :-)

Thanks.  Doh!  Fixed.

>
> Quoting from the draft:
>
>   "The customer of the IANA protocol parameters function is the Internet
>    Engineering Task Force (IETF)."
>
> The above is inconsistent with a stated IETF position.
>
>   "1.  The IETF protocol parameter registry function has been and
>       continues to be capably provided by the Internet technical
>       community."
>
> What is the "Internet technical community"?
>
>   "The IETF uses the IANA protocol parameter registries for
>    this purpose."
>
> The above is not aligned with the stated position of the IETF.

The above text was taken verbatim (I think) from the principles that
were developed in the Spring, even before we knew of the NTIA
announcement.  I'm not saying one can't disagree or even debate the
point, but that's where the text came from.

>
> Quoting two parts of the responses out of context:
>
>   "It is important to note that the IETF includes anyone who wishes to
>    participate, including anyone from ICANN or the RIRs, and many people
>    from those organizations regularly do."
>
>   "In-person attendance is not required for participation, and many
>    people participate in email discussions that have never attended
>    an IETF meeting."
>
> I scanned the ietf@ mailing list archives and I did not find anyone
> from ICANN or the RIRs participating on that mailing list.

Really?  No Dave Conrad?  No John Curran?  No Patrik Fältstrom?  (just
to name a few).
> Why are questions of jurisdictions immaterial?
>
>   "Any modifications to the protocol parameter registry function
>    should be made using the IETF process"
>
> The above is incorrect.

That is a statement of principle.  How do you believe it to be incorrect?

>
> The IETF responses are not well-formulated in my opinion.  There isn't
> any reference to the IANA Functions contract.
>
> As this topic has been mentioned I'll comment.  From
> https://www.icann.org/resources/pages/bylaws-2012-02-25-en
>
>   "The mission of The Internet Corporation for Assigned Names and Numbers
>    ("ICANN") is to coordinate, at the overall level, the global
> Internet's
>    systems of unique identifiers, and in particular to ensure the stable
>    and secure operation of the Internet's unique identifier systems.  In
>    particular, ICANN:
>
>    1. Coordinates the allocation and assignment of the three sets of
> unique
>     identifiers for the Internet, which are
>
>       "c. Protocol port and parameter numbers."
>
> ICANN may have to adjust its bylaws if RFC 6220 is to be followed.

They've done fine thus far without having done so.

Eliot

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 1 Sep 2014 17:22:38 +0200

Dear Eliot,

Please see embedded comment below.

Thanks and best,
Richard
> -----Original Message-----
> From: Ianaplan [mailto:[email-masked]]On Behalf Of Eliot Lear
> Sent: lundi, 1. septembre 2014 16:10
> To: S Moonesamy; [email-masked]
> Cc: Russ Housley
> Subject: Re: [Ianaplan] A draft for your review
> 
> 
> Hi SM,
> 
> 

SNIP

> They've done fine thus far without having done so.

Yes, but, but thus far there has been a contract between NTIA and ICANN that clearly had precedence over the ICANN bylaws.  Since RFC 6220 was consistent with the NTIA/ICANN contract, there was no issue.

The exercise that we are engaged in is to see what, if anything, might be needed to replace the contract between NTIA and ICANN.

In my opinion, it is not sufficiently clear that the ICANN Bylaws do not imply that ICANN has the ultimate authority for the allocation and assignment of protocol parameters.

So I think that the ICANN Bylaws should be modified to make it clear that IETF has the ultimate authority for the allocation and assignment of protocol parameters.

But I recognize that others on this list do not share that view.

Best,
Richard

---

From: Eric Burger <[email-masked]>
Date: Mon, 1 Sep 2014 12:14:12 -0400

On Aug 31, 2014, at 10:35 PM, S Moonesamy <[email-masked]> wrote:

>> I think the disconnect is /direction/ for the IANA protocol parameters function comes from the IETF, which is an embodiment of the Internet technical community. The /input/ for the function is capably provided, not the /function/ itself. The language needs fixing.
>> 
>> How about:
>> The Internet technical community, through the IETF, has in the past and for the foreseeable future will provide direction to the IANA protocol parameter registry.
> 
> The stated position is:
> 
> The above basically says that the IETF considers that function as an IETF matter.  If you (used in the general sense) call it "IANA protocol parameters function" it is no longer an IETF matter.
> 
> One of the questions I asked was about the "Internet technical community".  The problem with using the term is that it is ill-defined.  I'll step back; there was a discussion about "global multistakeholder community" on this mailing list around the beginning of this month.  It was concluded that it is better to use the term "Internet community".
> 
> My reading of the question is that it is about the IETF Community's use of the IANA functions.  The less difficult way to answer that is to build from RFC 6220 (and the relevant BCPs if that is necessary).  I am taking into account the arguments that the IETF or the IAB has made previously.  It make sense to be consistent or have an explanation for a change in direction or else there will be a loss of credibility.

I think the disconnect is we talk about ICANN so much we think anything that starts with an ‘I’ means ICANN. IANA is the Internet Assigned Numbers Authority. IANA has /nothing/ to do with ICANN, except for the fact that ICANN /happens/ to perform the IANA function. They are a contractor for the IETF. IANA is /not/ ICANN.

The IANA function is separable from domain names and IP addresses, although there are economies of scale and management from keeping them together. Since the IANA function is created by fiat from the IETF contract, I see no problem using the terms “IETF Protocol Parameters Registry” and the “IANA function.” The IANA function is the /embodiment/ of the IETF Protocol Parameters Registry.

However, I agree with your next comment, and I have some proposed text.

>> It is not that it is not aligned with the stated position of the IETF, it is tht it is the IETF community, including implementers, "the IETF's primary users of the IETF
>> standards and other documents," that use the IANA protocol parameter registries. How about:
>> 
>> Many IETF protocols make use of commonly defined protocol parameters. Implementers use these parameters. Implementers are the IETF's primary users of the IETF standards and other documents.  A globally available registry contains the parameter values and a pointer to documentation of the associated semantic intent. This registry, the IANA protocol parameter registry, provides this service to ensure consistent interpretation of these parameter values by independent implementations.
> 
> The above looks better.  It uses the term IANA protocol parameter registry though.  Please see my previous comment about that.

I agree with you here: the use of the term IANA protocol parameter registry is sloppy. Let’s go with:
Many IETF protocols make use of commonly defined protocol parameters. Implementers use these parameters. Implementers are the IETF's primary users of the IETF standards and other documents.  A globally available registry contains the parameter values and a pointer to documentation of the associated semantic intent. This registry, the IETF Protocol Parameters Registry, provides this service to ensure consistent interpretation of these parameter values by independent implementations.  Historically, the Internet Assigned Numbers Authority has, under contract, operated the IETF Protocol Parameters Registry.

>> RIR and ICANN people regularly come to IETF meetings, which means they participate. As we say, in-person attendance is not required for participation. Likewise, email discussions are also not required for participation. Thus, there is no inconsistency. Moreover, participation does not require posting. I will bet there are a lot of ICANN and RIR people subscribed (i.e., participating) to IETF email lists.
> 
> The point was that:
> 
> What you (used in the general sense) could do here is to explain that there is coordination and how it is being done when there is an overlap.

Eliot addressed this issue better than I did. The substantive issue is that we have an open process that already has all of the major players (and lots of minor players like me) involved.

[snip]
> It's an IAB matter.  The term "IETF process" may or may not cover that.  There is already the following as part of the response:
> 

The IAB operates on behalf of the IETF. I don’t see the issue.

> As a general comment, there is the following under "required proposal elements":  "associated references to source documents of specific policies/practices".  A plausible response would be one which could be substantiated with references.  Otherwise (in my opinion), it will look like the IETF is not comfortable with what it has written.

On the one hand, we have a lot of references to IETF documents. On the other hand, if a casual reader thinks we do not have enough references, we can have more.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 01 Sep 2014 18:31:34 +0200

Hi Eric & SM,

On 9/1/14, 6:14 PM, Eric Burger wrote:
> I agree with you here: the use of the term IANA protocol parameter
> registry is sloppy. Let’s go with: Many IETF protocols make use of
> commonly defined protocol parameters. Implementers use these
> parameters. Implementers are the IETF's primary users of the IETF
> standards and other documents. A globally available registry contains
> the parameter values and a pointer to documentation of the associated
> semantic intent. This registry, the IETF Protocol Parameters Registry,
> provides this service to ensure consistent interpretation of these
> parameter values by independent implementations. Historically, the
> Internet Assigned Numbers Authority has, under contract, operated the
> IETF Protocol Parameters Registry.

There is a particular facet I think we want to make clear: there may
come a time when we need another distributed registry.  It's not that
hard to imagine.  If so, we will need to look at existing structures,
and assign/delegate accordingly.  Names and unicast IP addresses are
examples of protocol registries that have been assigned to other
organizations.

[...]

> On the one hand, we have a lot of references to IETF documents. On the other hand, if a casual reader thinks we do not have enough references, we can have more.

I may have already lost the plot on this one, but as Eric writes, the
document is sprinkled with references, and there is then a specific
question about references.  I could aggregate all the references into
that question, but the reason the references are where they are is so
that people can spot relevance.

Eliot

---

From: S Moonesamy <[email-masked]>
Date: Mon, 01 Sep 2014 10:00:08 -0700

Hi Eliot,
>point, but that's where the text came from.

I read the principles from the minutes and did 
not find "technical" in the text that was agreed on.

>Really?  No Dave Conrad?  No John Curran?  No Patrik Fältström?  (just
>to name a few).

There was a message from frobbit.se (see 
http://www.ietf.org/mail-archive/web/ietf/current/msg88990.html 
) and one from shinkuro.com (see 
http://www.ietf.org/mail-archive/web/ietf/current/msg89388.html 
).  There wasn't any message from arin.net or 
icann.org.  David Conrad recently started working for ICANN.

>That is a statement of principle.  How do you believe it to be incorrect?

The IETF process is discussed in RFC 2026.  The 
text would require any changes to be done through that process.

>They've done fine thus far without having done so.

This confuses people from developing countries 
(see http://1net-mail.1net.org/pipermail/discuss/2014-January/001012.html ).

Hi Eric,
>examples of protocol registries that have been assigned to other

Names and unicast IP addresses registries are 
managed by ICANN through the IANA Functions 
contract.  The IETF part has not been 
controversial.  I would suggest solving the IETF part.

>that people can spot relevance.

Yes.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Mon, 01 Sep 2014 10:23:43 -0700

Hi Eric,
At 09:14 01-09-2014, Eric Burger wrote:
>I think the disconnect is we talk about ICANN so much we think 
>anything that starts with an 'I' means ICANN. IANA is the Internet 
>Assigned Numbers Authority. IANA has /nothing/ to do with ICANN, 
>except for the fact that ICANN /happens/ to perform the IANA 
>function. They are a contractor for the IETF. IANA is /not/ ICANN.

Yes.

I read http://www.ntia.doc.gov/page/iana-functions-purchase-order

>The IANA function is separable from domain names and IP addresses, 
>although there are economies of scale and management from keeping 
>them together. Since the IANA function is created by fiat from the 
>IETF contract, I see no problem using the terms "IETF Protocol 
>Parameters Registry" and the "IANA function." The IANA function is 
>the /embodiment/ of the IETF Protocol Parameters Registry.

I understand the above.

>However, I agree with your next comment, and I have some proposed text.

I'll comment below.

>Please see my previous comment about that.
>
>registry is sloppy.

Ok.

>  Let's go with:
>registry, the IETF Protocol Parameters Registry, provides this 
>values by independent implementations.  Historically, the Internet 
>Assigned Numbers Authority has, under contract, operated the IETF 
>Protocol Parameters Registry.

That sounds better.

>Eliot addressed this issue better than I did. The substantive issue 
>is that we have an open process that already has all of the major 
>players (and lots of minor players like me) involved.

I would not describe you as a minor player.  I commented about 
participation in my reply to Eliot.

>The IAB operates on behalf of the IETF. I don't see the issue.

Please see my comment to Eliot.

>On the one hand, we have a lot of references to IETF documents. On 
>the other hand, if a casual reader thinks we do not have enough 
>references, we can have more.

The point was to be able to substantiate what is in the text of the 
draft.  As an example, there are is a reference for the intent to 
form a working group.

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Sep 2014 10:41:53 +1200

On 02/09/2014 03:22, Richard Hill wrote:
...

> Yes, but, but thus far there has been a contract between NTIA and ICANN that clearly had precedence over the ICANN bylaws.  

IANAL, but I find it very hard to believe that a contract can have
precedence over the by-laws of a corporation. At the least it suggests
a serious failure of due diligence before signing the contract.

   Brian

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 01 Sep 2014 22:55:16 -0400

> a serious failure of due diligence before signing the contract.
Since it's the NTIA contract that grants ICANN the authority to perform 
the IANA functions, of course it has precedence.  Now, one might argue 
that the contract is in breach, because ICANN signed a contract that's 
in violation of its by-laws, in which case.... <what?>.  But, just 
because ICANN's bylaws says that it has the authority, doesn't mean it does.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Sep 2014 15:36:03 +1200

On 02/09/2014 14:55, Miles Fidelman wrote:
>>> Yes, but, but thus far there has been a contract between NTIA and
>>> ICANN that clearly had precedence over the ICANN bylaws.
> the IANA functions, of course it has precedence.  

Sorry, that's a non sequitur. A corporation surely acts according to its
Articles of Incorporation and its By-Laws, and they (probably intentionally)
make no reference to the US Government or any of its agencies, and certainly
not to the NTIA contract. ICANN will not cease to exist, nor will its
charitable purposes change, when that contract lapses.

There was absolutely no consensus in 1998 that NTIA had any authority to
grant ICANN such authority anyway. At the time, everybody involved managed
to hold their noses because ICANN had to be bootstrapped somehow and
there was nothing to be gained by fighting the White House.

> Now, one might argue

True. Which is why the IAB and IETF worked hard to get an MoU signed,
to consolidate the above bootstrap. Personally, I felt that ICANN was
on very shaky ground until 10 March 2000 when its Board ratified
the MoU. Until that moment, the IETF and IAB could have walked away
in a heartbeat. There were off-shore copies of all the existing
IANA allocations just in case.

   Brian

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 2 Sep 2014 09:59:23 +0200

Dear Brian,

The IANA Functions contract between NTIA and ICANN is not an ordinary contract.  In reality, it is delegation of authority and a mandate from NTIA to ICANN.

Recall the history: this contract was established pursuant to the 1998 NTIA Statement of Policy on the Management of Internet Names and Addresses, and the ICANN Bylaws were written to conform to that Statement of Policy.

Thus it appears clear to me that, in the ICANN Bylaws, the mission "to coordinate, at the overall level, the global Internet's systems of unique identifiers" must be understood as (gloss added in square brackets) "to coordinate [pursuant to a mandate from the US government], at the overall level, the global Internet's systems of unique identifiers".

Once you remove the IANA contract between NTIA and ICANN, that gloss is no longer relevant, so ICANN's mission becomes "to coordinate at the overall level", meaning that ICANN is the ultimate authority.

Inded, if you reread the Statement of Policy (more commonly called the White Paper) it is clear that its intent was to transfer the ultimate authority to the "new corporation", which new corporatio is of course ICANN.

NTIA's recent announcement on the transition states "Transitioning NTIA out of its role marks the final phase of the privatization of the DNS as outlined by the U.S. Government in 1997."  So the intent expressed in the White Paper must be taken into account when intepreting the ICANN Bylaws.

If they are not changed, then, in my view, ICANN will have no choice but to consider that it has ultimate authority over the global Internet's systems of unique identifiers, which of course includes the protocol parameters.

I note that Andrew Sullivan disagrees with my interpretation.

Best,
Richard

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: mardi, 2. septembre 2014 00:42
> To: [email-masked]
> Cc: [email-masked]
> > Yes, but, but thus far there has been a contract between NTIA 
> and ICANN that clearly had precedence over the ICANN bylaws.  
>

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 2 Sep 2014 10:07:54 +0200

Please see embedded comments below.

Thanks and best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Brian E
> Carpenter
> Sent: mardi, 2. septembre 2014 05:36
> To: Miles Fidelman
> Cc: [email-masked]
> not to the NTIA contract.

Correct.  That was not necessary because ICANN was the "new corporation"
referred to in the White Paper, so it was understood that the NTIA Policy
Statement was the guiding instrument.

>ICANN will not cease to exist, nor will its

I disagree with the last part of the statement above.  ICANN's purpose will
definitely change because, at present, its purpose is conditioned by the
mandate from NTIA, and in particular that rather stringent provisions of the
IANA Functions contract.

Once that contract lapses, the conditions lapse (unless they are restated
elsewhere).

More importantly, as stated by NTIA itself in its statement on the
transition, ICANN will no longer be subject to US government oversight (or
"stewardship", if you prefer), so it will become the overall authority for
all the matters covered by its mission statement, which includes protocol
parameters.

> grant ICANN such authority anyway.

Nice to hear you say that.

>At the time, everybody involved managed

And, reportedly, some thought that the government might initiate legal
proceedings to prove that they did inteed have authority.

> IANA allocations just in case.

Yes.  But, as I heard the story, another element was that it was felt that
the risk of explicit and forceful US government intervention was not work
taking.

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Sep 2014 09:11:17 +0100

On 02/09/14 08:59, Richard Hill wrote:
> If they are not changed, then, in my view, ICANN will have no choice
> but to consider that it has ultimate authority over the global
> Internet's systems of unique identifiers, which of course includes
> the protocol parameters.

I can't think of a universe in which is that a helpful statement.

The "will have no choice but to consider" phrasing seems very
like trolling.

And the supposed problematic outcome isn't worth bothering with
anyway. As has been stated numerous times, if ICANN every acted
silly with the protocol parameters, they'd end up out of that
business in 6 months and would probably suffer other collateral
damage as a result. So they just won't mess about is my conclusion
regardless of this transition. (And I don't believe there's any
indication they'd want to mess about with the protocol parameters
anyway - they do a fine job with good folks.)

Richard - wouldn't it be better to stick to a more reality
based discussion?

S.

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 2 Sep 2014 10:13:51 +0200

I believe in planning to prevent worst-case outcomes.

But maybe my reality is different from yours.

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Stephen
> Farrell
> Sent: mardi, 2. septembre 2014 10:11
> To: [email-masked]; Brian E Carpenter
> Cc: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Sep 2014 09:19:58 +0100

> I believe in planning to prevent worst-case outcomes.

But your mail utterly ignored the existing protections built
around the protocol parameters, to the extent (IMO at least)
that you moved from considering a possible worst-case outcome
to argumentatively using a nonsensical fictional outcome for
I don't know what purpose.

> But maybe my reality is different from yours.

I guess so. Ignoring the current setup for the IANA functions
as you did does seem like an alternate universe;-)

S.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 Sep 2014 12:30:20 +0300

> I note that Andrew Sullivan disagrees with my interpretation.

My disagreement, I will note, is on the basis of the text in the bylaw.

Article I, section 1. contains the mission.  Item 1 of that section is
the mission, and every item in that Article says that ICANN
"coordinates".  It doesn't say ICANN does anything else.  There
doesn't appear to be anywhere else in the bylaws that the protocol
parameters function is discussed.  For that reason, I don't believe
that the bylaws need to be changed (in respect of protocol parameter
functions).

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Sep 2014 12:01:43 +0200

Hi SM,

On 9/1/14, 7:00 PM, S Moonesamy wrote:
> I read the principles from the minutes and did not find "technical" in
> the text that was agreed on.

Ok.  I'm opening an issue on the text to track this.  Incidentally, I'm
right now using GITHUB for issue tracking (see
https://github.com/elear/IANA-Transition/issues/).  If ianaplan gets
chartered the chairs may use those issues or not, depending (among other
things) whether the WG uses the draft ;-)  I will also accept pull
requests so long as it's clear that this group finds the text
acceptable, or it's editorial in nature.
> http://www.ietf.org/mail-archive/web/ietf/current/msg88990.html ) and
> one from shinkuro.com (see
> http://www.ietf.org/mail-archive/web/ietf/current/msg89388.html ). 
> There wasn't any message from arin.net or icann.org.  David Conrad
> recently started working for ICANN.

Well, but that was just the start of my list.  Steve Crocker is the
chair of the board of ICANN, and he's also the author of RFC 1 (among
many others), a former security AD, and an occasional contributor.

> The IETF process is discussed in RFC 2026.  The text would require any
> changes to be done through that process.

> The above is incorrect.

What are we materially disagreeing on in the draft?

> This confuses people from developing countries (see
> http://1net-mail.1net.org/pipermail/discuss/2014-January/001012.html ).

Ok.  I personally disagree, but I will open an issue on this as well.

> Names and unicast IP addresses registries are managed by ICANN through
> the IANA Functions contract.  The IETF part has not been

Yes.  However, it's important for all to recognize that should we create
new registries, we may ask others to manage them, and those others may
or may not be those who manage existing registries.  Does that
recognition have to happen in our response?  I've opened an issue.

Eliot

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 02 Sep 2014 06:44:57 -0400

Ditto.

The whole point of accountability mechanisms, be they in law or contract 
form, is to address worst case situations.  When things are working, 
there's little need for such mechanisms.

Miles Fidelman

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Sep 2014 11:52:59 +0100

> there's little need for such mechanisms.

Sure. But discussing this when such mechanisms do exist already
(as is the case for protocol parameters) as if those mechanisms
did not exist, is what I commented upon. That is not considering
a worst-case scenario, that constitutes ignoring reality.

S.

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 2 Sep 2014 12:56:12 +0200

What we are discussing is whether the existing mechanisms will be sufficient
after the NTIA withdraws from its "stewardship" role, which role included
placing stringent conditions on the way that ICANN performs the IANA
function.

The reality is that NTIA envisages withdrawing.  Whether that is significant
or not appears to be disputed.

Best,
Richard

> Sent: mardi, 2. septembre 2014 12:53
> To: Miles Fidelman; [email-masked]; Brian E Carpenter
> Cc: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Sep 2014 12:01:33 +0100

> placing stringent conditions on the way that ICANN performs the IANA

Let me quote some earlier text from Richard:

"If they are not changed, then, in my view, ICANN will have no choice
but to consider that it has ultimate authority over the global
Internet's systems of unique identifiers, which of course includes
the protocol parameters."

That quoted text is not worst-case scenario analysis IMO as it
utterly ignores the current accountability mechanisms for the
protocol parameters. Any kind of analysis that similarly ignores
the current reality is a bad idea.

I don't really see much value in further disagreement as to
whether or not the quoted text is a useful contribution or something
else.

S.

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 02 Sep 2014 10:02:23 -0400

> a worst-case scenario, that constitutes ignoring reality.

Yes, but the MOU can be withdrawn from.  Right now, the NTIA contract 
"backstops" the MOU.  The question becomes: what, if anything replaces 
that backstop?  If I were NTIA, I'd sure like to see that answered  
before stepping away.

Miles Fidelman

---

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Sep 2014 16:08:43 +0200

Miles,

> that backstop?  If I were NTIA, I'd sure like to see that answered 

Yes, but what does that mean in this case?  If the IETF were to
terminate the arrangement, would ICANN still review our documents, and
if so, would we not take them seriously?  The worst case would be
ICANN's copy of protocol parameters didn't match our own, and at that
point, developers would have to decide who to believe.  This would not
be a good state to be in, but realistically anyone else can do the same
thing.  And truly it would serve nobody's interest for this to happen,
not ours, not ICANN's and certainly not implementers'.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Sep 2014 15:15:01 +0100

On 02/09/14 15:08, Eliot Lear wrote:
>> Yes, but the MOU can be withdrawn from.  Right now, the NTIA
>> contract "backstops" the MOU.  The question becomes: what, if
>> anything replaces that backstop?  If I were NTIA, I'd sure like
>> to see that answered before stepping away.
> 
> terminate the arrangement, would ICANN still review our documents,
> and if so, would we not take them seriously?  The worst case would
> be ICANN's copy of protocol parameters didn't match our own, and at
> that point, developers would have to decide who to believe.  This
> would not be a good state to be in, but realistically anyone else
> can do the same thing.  And truly it would serve nobody's interest
> for this to happen, not ours, not ICANN's and certainly not
> implementers'.

Right. Speculation along those lines is just a distraction and
is not any rational form of planning, about worst or other cases.

S.

> 
> Eliot
> 
> 
> 
> _______________________________________________ Ianaplan mailing
> list [email-masked]

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 02 Sep 2014 10:17:44 -0400

> not ours, not ICANN's and certainly not implementers'.

It's awfully important (IMHO) to have a definitive registry for protocol 
parameters.  Right now ICANN provides the registry, under the aegis of 
both the NTIA contract and the MOU.  What will be the process if IETF 
decides that the job isn't being done well and wants to replace ICANN as 
the registry operator?  What if ICANN decides it wants to levy fees?  
Who makes such decisions, and how?  Etc.

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 02 Sep 2014 10:24:46 -0400

Stephen Farrell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>

The IANA transition is a question of contracts, organizational by-laws, 
law, and regulation - not engineering and project management.  Who, does 
what, to whom, under what circumstances; who pays; what are the 
mechanisms for accountability and recourse; and so forth, are precisely 
the kind of things that we need to be thinking about. (IMHO)

Miles Fidelman

---

From: David Conrad <[email-masked]>
Date: Tue, 2 Sep 2014 07:38:22 -0700

Miles,

On Sep 2, 2014, at 7:17 AM, Miles Fidelman <[email-masked]> wrote:
> It's awfully important (IMHO) to have a definitive registry for protocol parameters.  

Yes.

> Right now ICANN provides the registry, under the aegis of both the NTIA contract and the MOU.  

Yes, although as Brian and others have pointed out, the relevance of the NTIA contract is questionable.

> What will be the process if IETF decides that the job isn't being done well and wants to replace ICANN as the registry operator?  

Perhaps something similar to the replacement of the RFC Editor (not to say that it wasn’t being performed well, rather that there was a process established to change it).

> What if ICANN decides it wants to levy fees?  

If the IETF community decides that is unreasonable, it’d probably trigger the replacement.  The MoU, after all, is terminable.

> Who makes such decisions, and how?  Etc.

Who decided to replace the RFC Editor, and how?

Regards,
-drc

---

From: Eric Burger <[email-masked]>
Date: Tue, 2 Sep 2014 11:13:36 -0400

[snip]
> Perhaps something similar to the replacement of the RFC Editor (not to say that it wasn’t being performed well, rather that there was a process established to change it).

It is also enumerated in the MoU. Non issue.

> If the IETF community decides that is unreasonable, it’d probably trigger the replacement.  The MoU, after all, is terminable.

Precisely.

> Who decided to replace the RFC Editor, and how?

That is the remit of the IAB.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Sep 2014 17:49:59 +0200

On 9/2/14, 4:24 PM, Miles Fidelman wrote:
>
> The IANA transition is a question of contracts, organizational
> by-laws, law, and regulation - not engineering and project
> management.  Who, does what, to whom, under what circumstances; who
> pays; what are the mechanisms for accountability and recourse; and so
> forth, are precisely the kind of things that we need to be thinking
> about. (IMHO)

Yes.  And what are the consequences if someone doesn't do something
they're supposed to do, or does something they're not supposed to do? 
If you can imagine a specific consequence moreso than what I described
I'd like to know what it is.  And now would be a very good time, because
we are all human and I may well have missed something.

Eliot

---

From: S Moonesamy <[email-masked]>
Date: Tue, 02 Sep 2014 06:51:13 -0700

Hi Eliot,
At 03:01 02-09-2014, Eliot Lear wrote:
>Ok.  I'm opening an issue on the text to track this.  Incidentally, 
>I'm right now using GITHUB for issue tracking (see 
>chartered the chairs may use those issues or not, depending (among 
>other things) whether the WG uses the draft ;-)  I will also accept 
>pull requests so long as it's clear that this group finds the text 

I wondered whether the future working group would adopt the draft. 
:-)  I'll wait as it might not be useful to debate about the issues 
immediately.

>chair of the board of ICANN, and he's also the author of RFC 1 
>(among many others), a former security AD, and an occasional contributor.

I am aware of the above.  However, my argument was based on facts 
whereas the above is about the background of one person.  I'll wait 
to see your list. :-)

>>The IETF process is discussed in RFC 2026.  The text would require 
>>any changes to be done through that process.
>

Yes.

>What are we materially disagreeing on in the draft?

I'd say that it is more of a matter of wording for a formal answer 
which will be scrutinized by the world.  I think that you have some 
good text on Page 12 (second paragraph from the bottom).  If it is 
used as the starting point for some of the responses you have most of 
what you need.

By the way, this is a -00 draft.  It may be easier if you defer this 
for now as other persons may wish to review the draft and suggest changes.

>Ok.  I personally disagree, but I will open an issue on this as well.

Thanks.

>Yes.  However, it's important for all to recognize that should we 
>create new registries, we may ask others to manage them, and those 
>others may or may not be those who manage existing registries.  Does 
>that recognition have to happen in our response?  I've opened an issue.

I am not disagreeing with asking others to manage some registries in 
future.  My quick thought in reply to the question would be to leave 
it to RFC 6220.

Regards,
S. Moonesamy

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Wed, 03 Sep 2014 17:44:31 -0400

I have to say, I stumbled over the "customer" wording, too.  It seems to 
me that a key thing for the protocol parameters is to make sure it is 
crystal clear that the IETF drives its use of this function.  While I 
agree completely that it is the IETF that is the customer, I think we'd 
best be clear that it is only in the sense of selecting a service 
provider to implement the function.

To that end, I wonder about undoing the re-ordering of the bullets in 
the RFP, to define the service first.

[From the draft:]
>      o A description of the service or activity.
>
>
>
>    IETF Response:
>
>    Many IETF protocols make use of commonly defined protocol parameters.
>    These parameters are used by implementers, who are the IETF's primary
>    users of the IETF standards and other documents.  To ensure
>    consistent interpretation of these parameter values by independent
>    implementations, a globally available registry contains the parameter
>    values and a pointer to documentation of the associated semantic
>    intent.  The IETF uses the IANA protocol parameter registries for
>    this purpose.

Perhaps, instead:
    Many IETF protocols require the use of protocol parameters.
    These parameters are used by implementers, who are the primary
    users of the IETF standards and other documents.  To ensure
    consistent interpretation of these parameter values by independent
    implementations, these IETF protocol specifications define and 
require a globally available registry containing the parameter
    values and a pointer to documentation of the associated semantic
    intent.  The IETF uses the IANA protocol parameter registries to 
implement such registries.

And then:

> I.  Description of Community's Use of IANA Functions
>
>
>       This section should list the specific, distinct IANA services or
>       activities your community relies on. For each IANA service or
>       activity on which your community relies, please provide the
>       following:
>
>        o A description of the customer(s) of the service or activity.
>       [N.B. the IETF response has swapped this question with the next.]

As noted above -- I'm not sure swapping is helpful.

>
>
>    IETF Response:
>
>    The customer of the IANA protocol parameters function is the Internet
>    Engineering Task Force (IETF).

Perhaps instead:

"The IETF is a customer of the IANA protocol parameter function to 
implement its standards' protocol registries."

If we want to mark all four corners:

> o What registries are involved in providing the service or
>          activity.
>
>
>
>    IETF Response:
>
>    Administration of the protocol registries are themselves the service
>    that is provided to the IETF community by ICANN.

Perhaps:

"The protocol parameter registries are the product of IETF work. 
Administration of the protocol parameter registries is the service that 
is provide to the IETF [no "community" -- it's the organization] by ICANN."

Just some thoughts.

Leslie.

On 8/30/14 9:29 AM, Richard Hill wrote:
> Dear Eliot and Russ,
>
> Thank you very much for this excellent draft.
>
> I have some comments, some minor, some rather more substantive.
>
> 1) In section 1, the draft says "In that announcement, NTIA asked the
> Internet Corporation for Assigned Names and Numbers (ICANN) to
> establish a process to deliver a proposal for transition."
>
> I think that it would be better to include the full mandate, and to
> say: "In that announcement, NTIA asked the Internet Corporation for
> Assigned Names and Numbers (ICANN) to establish a process to deliver
> a proposal to transition key Internet domain name functions to the
> global multistakeholder community."
>
> 2) In section 2, Part I, the proposed IETF response is "The customer
> of the IANA protocol parameters function is the Internet Engineering
> Task Force (IETF)."
>
> I think that this is literally true, but I think it is also worth
> noting here (as the draft does later on) that the real users of the
> protocol parameters are various implementers.  So perhaps this could
> be modified to read: "The customer of the IANA protocol parameters
> function is the Internet Engineering Task Force (IETF), which acts on
> behalf of the numerous implementers that use specific parameter
> values."
>
> 3) In section 2, Part III, at the end, the proposed IETF response is
> "Because of the nature of the agreement, questions of jurisdiction
> are immaterial."  I don't think that this is appropriate, because the
> agreement in question might well be considered a contract. I don't
> see any choice of law or venue clause in the MoU or its 2014
> Supplemental Agreement, so I think that the current situation would
> better be reflected as follows:
>
> "Because of the nature of the agreement, and its dispute resolution
> and escalation clauses, it is not expected that any disputes would
> arise that would require court interventions."
>
> And you might wish to add "Should any such disputes arise, the
> jurisdiction would be the compentent jurisdiction depending on the
> nature of the dispute and the parties to the dispute."
>
> 5) In section 2, part IV, the proposed IETF response is "No changes
> are required, as over the years since the creation of ICANN, the
> IETF, ICANN, and IAB have together created a system of agreements,
> policies, and oversight mechanisms that covers what is needed."
>
> I would suggest that this be slightly modified to read "No
> operational changes are required, ..."
>
> The reason for this change is that some non-operational changes may
> be required, see below.
>
> 6) In section 2, part IV, under "Transition Implications", the IETF
> response is "No structural changes are required." This is correct,
> but I think that some contractual changes are required in order to
> make it clear that the ultimate authority for the protocol parameters
> is IETF, not ICANN.
>
> So I would propose to add, at the end of that section, the following
> three paragraphs.
>
> assignment of the protocol parameters. That article should be
> modified to make it clear that, as specified in RFC 2860, it is the
> IETF that has the overall responsibility for the coordination and
> allocation and assignment of the protocol parameters.
>
> "And item 4 of RFC 2860 should be modified to read as follows:
>
> "4. Agreed technical work items.  ICANN agrees, notwithstanding any
> provisions in its Bylaws or other corporate documents that might be
> construed differently, that during the term of this MOU it shall
> cause IANA to comply ..."
>
> For reference, item 4 of RFC 2860 currently reads "4. Agreed
> technical work items. ICANN agrees that during the term of this MOU
> it shall cause IANA to comply ..."
>
> agreed community policies is an issue and, if so, whether anything
> should be proposed to deal with that issue, such as proposing that
> the entity that performs the IANA function should have immunity of
> jurisdiction, or that the entity should have redundant sites in more
> than one jurisdiction.
>
> If there is support for dealing with that issue, then some text could
> be added.
>
> Thanks again for the great work and best, Richard
>
> -----Original Message----- From: Ianaplan
> [mailto:[email-masked]]On Behalf Of Eliot Lear Sent:
> samedi, 30. août 2014 09:32 To: [email-masked] Cc: Russ Housley
> Subject: [Ianaplan] A draft for your review
>
>
> Dear colleagues,
>
> the question? Is there anything missing? Is there anything that does
> not parse well?  Did you think "Huh??" when you read a sentence? My
> intent is to have a second version out prior to the cutoff for the
> Kind thanks to Russ Housley and the members of the IAB IANA Strategy
> Program for their very helpful contributions.  I've indicated myself
> and Russ as editors, because we have not been the only ones to insert
> text on this.
>
> Eliot ps: I am aware that the formatting could stand some
> improvement.  I will work on that for the next version.
>

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Eliot Lear <[email-masked]>
Date: Thu, 04 Sep 2014 07:54:29 +0200

Hi Leslie,

Thanks for the comments.  Please see below.

On 9/3/14, 11:44 PM, Leslie Daigle (TCE) wrote:
>
> I have to say, I stumbled over the "customer" wording, too.  It seems
> to me that a key thing for the protocol parameters is to make sure it
> is crystal clear that the IETF drives its use of this function.  While
> I agree completely that it is the IETF that is the customer, I think
> we'd best be clear that it is only in the sense of selecting a service

I did the ordering in the way that seemed to make sense to me, but
perhaps it doesn't make sense to others.  And so I'm quite happy to undo it.
> implement such registries.

I have no objection to this.

> implement its standards' protocol registries."

That seems tortured.  And perhaps it's already been made clear?

> Administration of the protocol parameter registries is the service
> that is provide to the IETF [no "community" -- it's the organization]
> by ICANN."
>
>

I like that.

Eliot