Subject: [Ianaplan] what *is* IANA?

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Sep 2014 18:08:45 +0200

I draw your attention to the footnote included in the final RFP:

>       In this RFP, "IANA" refers to the functions currently
>       specified in the agreement between NTIA and ICANN
>       [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as
>       well as any other functions traditionally performed by the IANA
>       functions operator. SAC-067
>       [https://www.icann.org/en/system/files/files/sac-067-en.pdf]
>       provides one description of the many different meanings of the
>       term “IANA” and may be useful reading in addition to the
>       documents constituting the agreement itself.

Here is the question: do we need additional text to make clear that we
are referring to the function and not the agreement, as we respond? 
Perhaps the use of the term IANA throughout the text needs some review?

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Sep 2014 13:18:00 +1200

> Perhaps the use of the term IANA throughout the text needs some review?

I don't really see much room for doubt, since the very first sentence
of the draft responses identifies the scope as the "IANA protocol parameters
function".

This did cause me to notice that although RFC2850 is listed as a reference,
it isn't cited in the text. Maybe the sentence I suggested previously:
"Among other duties, the IAB must approve the appointment
of an organization to act as IANA on behalf of the IETF."
needs a supplement such as

  In March 2000, the IAB and IETF signed an agreement with ICANN
  for ICANN to host the IANA protocol parameters function [RC2850].

     Brian

---

From: Eric Burger <[email-masked]>
Date: Thu, 11 Sep 2014 06:34:54 -0400

I’m torn. Once pointed out, I agree with with Brian, I think it is clear. However, if it was not clear to Eliot who has been looking at this intently for a while, I would offer it would not hurt to make it absurdly clear that the IETF could not give a rat’s *ss about ICANN or some funky USG contract, but we care deeply about the authoritative registry that contains the IETF protocol parameters, also known as the Internet Assigned Numbers Authority.

On Sep 10, 2014, at 9:18 PM, Brian E Carpenter <[email-masked]> wrote:

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Sep 2014 13:48:09 +0300

On 11 Sep 2014, at 13:34, Eric Burger <[email-masked]> wrote:

> I’m torn. Once pointed out, I agree with with Brian, I think it is clear. However, if it was not clear to Eliot who has been looking at this intently for a while, I would offer it would not hurt to make it absurdly clear

Right.

> that the IETF could not give a rat’s *ss about ICANN or some funky USG contract, but we care deeply about the authoritative registry that contains the IETF protocol parameters, also known as the Internet Assigned Numbers Authority.

Your text proposal may need some work :-)

I think adding a sentence or two about how we view the situation would be useful.

Jari

---

From: "Lynn St.Amour" <[email-masked]>
Date: Thu, 11 Sep 2014 08:01:58 -0400

Hi Brian,

I think this needs to be made very clear and your proposed addition is helpful.  Perhaps even add something like:  This agreement is reviewed regularly by the IAB and IETF as is performance against the SLA.  In other words, there is a very active monitoring and full ownership by the IETF for these functions.

Lynn

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 11 Sep 2014 08:14:19 -0400

It might also be helpful to have a clause to the effect that the 
authority to designate the the protocol parameter function (or registry) 
rests with IETF.  I.e., ICANN (or whomever) has no authority to perform 
those functions on its own (even though ICANN's charter can be read as 
claiming that they do).

Items like there are two points to be made very explicitly:
- Definition of, and policy for protocol parameters resides with IETF.  
(Somewhat of a bold assumption, but it takes the place of the equivalent 
statement of authority in the NTIA contract)
- IETF has the sole authority/power to designate, by contract, an 
organization to perform the associated IANA functions.

Miles Fidelman

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

---

From: Ray Pelletier <[email-masked]>
Date: Thu, 11 Sep 2014 08:19:02 -0400

>  for ICANN to host the IANA protocol parameters function [RC2850].

I agree.

We should emphasize IANA’s role as a service provider and not focus on the IETF as a customer.

This is clear in the beginning of the MOU with ICANN:

MEMORANDUM OF UNDERSTANDING CONCERNING THE TECHNICAL WORK OF THE INTERNET 
ASSIGNED NUMBERS AUTHORITY

1. This  Memorandum of Understanding (“MOU”) defines an agreement between the Internet Engineering 
Task Force and the Internet Corporation for Assigned Names and Numbers.  Its intent is exclusively to 
define the technical work to be carried out by the Internet Assigned Numbers Authority on behalf of the 
Internet Engineering Task Force and Internet Research Task Force.  It is recognized that ICANN may, 
through the IANA, provide similar services to other organizations with respect to protocols not within the 
IETF’s scope (i.e. registries not created by IETF or IRTF action); nothing in this MOU limits ICANN’s ability to do so.  

<https://iaoc.ietf.org/documents/IETF-ICANN-MOU_2000.pdf>

Ray

---

From: Eric Burger <[email-masked]>
Date: Thu, 11 Sep 2014 09:14:03 -0400

+1. I think this captures the reality that the IANA is a creation of the IETF that happens to reside at ICANN. We should steer away from language that makes it sound like the IANA is a creation of ICANN and the IETF happens to use it.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Sep 2014 06:15:48 -0700

> +1. I think this captures the reality that the IANA is a creation of the IETF that happens to reside at ICANN. We should steer away from language that makes it sound like the IANA is a creation of…

The language that Ray cites in the MOU with ICANN is at odds with this view.

In particular, the language:

     "It is recognized that ICANN may, through the IANA, provide similar
services to other organizations with respect to protocols not within the
IETF’s scope"

makes explicit that IANA is an ICANN activity, provides a set of
services to the IETF.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Sep 2014 08:53:47 +1200

> makes explicit that IANA is an ICANN activity, provides a set of

I don't see an inconsistency. I don't recall (and can't be bothered
to trawl the archive) whether this point was added by the IETF
or by ICANN, but it was simply to avoid pointless restrictions.

   Brian

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Sep 2014 13:53:46 -0700

> or by ICANN, but it was simply to avoid pointless restrictions.

The language translates into

     "ICANN provides a set of services through IANA.  (Only) some of
those serves are for the IETF."

This means that IANA is not an IETF function; it is an ICANN function.

And FWIW, this latter interpretation matches the way folk around ICANN
talk about IANA.

d/

---

From: Seun Ojedeji <[email-masked]>
Date: Thu, 11 Sep 2014 22:12:03 +0100

Well if it says other services "through" IANA, wouldn't it mean ICANN does
not indeed own the main IANA functions and someone else does (in this case
the IETF).

Cheers!
sent from Google nexus 4
kindly excuse brevity and typos.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Sep 2014 11:41:26 +1200

> This means that IANA is not an IETF function; it is an ICANN function.

It's a function that they host. However, if the IETF invoked the
6 month cancellation clause and moved the job elsewhere, all that
would be left at ICANN would be the registries they have taken
on for other parties, if there are any.

There would be a little spat about the domain name iana.org, of course.
We've known that since 1998.

> And FWIW, this latter interpretation matches the way folk around ICANN

Existentially, they are bound to talk that way.

   Brian

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Sep 2014 16:57:24 -0700

On 9/11/2014 4:41 PM, Brian E Carpenter wrote:
> It's a function that they host.

Unfortunately you are coercing the language to mean what you want it to,
rather than what it actually means.

The language pretty clearly means that they can (choose to) do other
services "through the IANA" if it wishes to.

That makes the entity of IANA theirs to add services to, not the IETF's.

d/

---

From: Seth Johnson <[email-masked]>
Date: Thu, 11 Sep 2014 18:27:37 -0600

> those serves are for the IETF."

Or:

    "ICANN may provide services similar to those IANA provides.  ICANN
may do so through IANA for protocols not within IETF's scope."

Seth

---

From: Dave Crocker <[email-masked]>
Date: Thu, 11 Sep 2014 17:27:43 -0700

> may do so through IANA for protocols not within IETF's scope."

This continues to miss the point.

The touchstone to reality is that an IETF decision to re-home the IETF's
IANA functions would be unlikely to be able to take the IANA domain
name.  It's a touchstone because it is an indication that IANA is now
publicly perceived as an ICANN function and ICANN's IANA functions
/already/ include more than the IETF functions.

So we might take our assignment marbles and go somewhere else, but it
won't be called IANA.  Or, at least, there will still be an IANA at ICANN.

d/

---

From: Seth Johnson <[email-masked]>
Date: Thu, 11 Sep 2014 18:40:20 -0600

> won't be called IANA.  Or, at least, there will still be an IANA at ICANN.

Aww.  Well, you are so stating.  But . . . do you have to?  :-)

Seth

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 11 Sep 2014 21:14:06 -0700

> won't be called IANA.  Or, at least, there will still be an IANA at ICANN.

[BA] I for one would not consider such an outcome acceptable. Note that the NTIA-ICANN contract covers disposition of property and required filing of a plan to deal with the succession to another contractor.  So it might be wise for the IETF Trust (who after all, owns these issues) to look into this.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 12 Sep 2014 06:36:58 +0200

Dave,

Everyone.  Today, we'll put out the next version of the draft.  It
contains this footnote I mentioned.  Personally I see subtle language
differences between the NTIA contract, our MoU, and RFC 6220.  That is-
2860 uses IANA as a proper noun, the NTIA contract talks about IANA
functions, and 6220 talks about the protocol parameters registry
function.  The response intends does NOT use the 2860 approach (I may
have missed a spot- there's a lot of text).

Anyway, if people have proposed edits to further address this issue,
that will be helpful.

Eliot

---

From: Seun Ojedeji <[email-masked]>
Date: Fri, 12 Sep 2014 06:38:41 +0100

If I give you a car that you are to always drive to X location at the
sametime I also said you may drive the car to Y location (if you wish).
Does it mean that you own the car?

Cheers!

sent from Google nexus 4

---

From: S Moonesamy <[email-masked]>
Date: Fri, 12 Sep 2014 00:04:09 -0700

Hi Bernard,
At 21:14 11-09-2014, Bernard Aboba wrote:
>[BA] I for one would not consider such an outcome acceptable. Note 
>that the NTIA-ICANN contract covers disposition of property and 
>required filing of a plan to deal with the succession to another 
>contractor.  So it might be wise for the IETF Trust (who after all, 
>owns these issues) to look into this.

A succession plan is about thinking about the future.  According to 
publicly available information "The Internet Assigned Numbers 
Authority (IANA) is a department of ICANN".  It is highly improbably 
that it can be changed.

Can the IETF takes its marbles and go home?  One might wish to 
consider whether the people in the relevant IETF constituency already 
have a plan for that.  Alternately, one might wish to consider 
whether the IETF has the money to do that.  Otherwise, it is not a 
credible ultimatum.

Regards,
S. Moonesamy

---

From: Seth Johnson <[email-masked]>
Date: Fri, 12 Sep 2014 02:34:05 -0600

It's my intention to simply encourage David to consider carefully his
disposition toward the move.  His position seemed to reflect a reading
of the passage that might be said to be tendentious.

On Thu, Sep 11, 2014 at 11:38 PM, Seun Ojedeji <[email-masked]> wrote:
> sametime I also said you may drive the car to Y location (if you wish). Does
> it mean that you own the car?
>
> Cheers!
>
> sent from Google nexus 4

---

From: Seun Ojedeji <[email-masked]>
Date: Fri, 12 Sep 2014 11:29:49 +0100

Hi SM,

On Fri, Sep 12, 2014 at 8:04 AM, S Moonesamy <[email-masked]> wrote:

>> [BA] I for one would not consider such an outcome acceptable. Note that
>> the NTIA-ICANN contract covers disposition of property and required filing
>> of a plan to deal with the succession to another contractor.  So it might
>> be wise for the IETF Trust (who after all, owns these issues) to look into
>> this.
>>
>
> publicly available information "The Internet Assigned Numbers Authority
> (IANA) is a department of ICANN".  It is highly improbably that it can be
> changed.
>

This was a view i shared a non-IETF list, however some has said that the
"departmental" separation was only made possible becuase of the contract
and will most likely disappear in absence of the contract. A view i was
quite puzzled about.

> Can the IETF takes its marbles and go home?  One might wish to consider
> whether the people in the relevant IETF constituency already have a plan
> for that.  Alternately, one might wish to consider whether the IETF has the
> money to do that.  Otherwise, it is not a credible ultimatum.
>

A question i would ask is where is home ;), nevertheless i get your
gist....and i think ensuring the existence of such option is important
(even if it doesn't get exercised).

Cheers!

-- 
------------------------------------------------------------------------

*Seun Ojedeji,Federal University Oye-Ekitiweb:      http://www.fuoye.edu.ng
<http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email:
<http://goog_1872880453>[email-masked]
<[email-masked]>*

The key to understanding is humility - my view !

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 12 Sep 2014 07:33:02 -0400

S Moonesamy wrote:
> have a plan for that.  Alternately, one might wish to consider whether 
> the IETF has the money to do that.  Otherwise, it is not a credible 
> ultimatum.
>

At one point, in researching these issues, I came across a relevant 
factoid:
IINs - the numbers assigned to credit card issuers (the 1st 4 numbers on 
a credit card), fall under an ISO standard (ISO 7812). At one point, the 
registration authority was the American Bankers Association.  Now it's ANSI.

That's at least one precedent.  There are probably more.  And, of 
course, there are plenty of precedents for one standards body with 
multiple registries.  ISBNs come to mind, as do, .... wait for it ....  
domain names.  DNS being particularly interesting given the split 
between ultimate authority (NTIA for now), ICANN, IANA, registrars, and 
root nameserver operators.

The notion that we should allow ICANN to be enshrined as the permanent 
and unchangeable IANA function provider - through lack of well crafted 
contractual agreements - strikes me as absolutely wrongheaded.  And... 
if folks at NTIA review this stuff carefully - through the eyes of 
government regulators and contracting types - they would consider it 
unacceptable.

Just one man's opinion, of course.

Miles Fidelman

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2014 04:45:58 -0700

> of the passage that might be said to be tendentious.

I don't have a 'disposition' about the move.  The current exercise for
the IETF is not whether the IETF wants or plans to move from having
ICANN administer the IANA functions.

The nature of an agreement like this is the same as for any contract.
It requires considering termination details, whether desired or planned
or not, and whether pleasant or not.

d/

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 12 Sep 2014 13:58:49 +0200

I agree with Miles, so I guess now it is just two people's opinion.

Best,
Richard

> -----Original Message-----
> From: Ianaplan [mailto:[email-masked]]On Behalf Of Miles
> Fidelman
> Sent: vendredi, 12. septembre 2014 13:33
> Cc: [email-masked]
> Subject: Re: [Ianaplan] what *is* a succession plan?
> 
> 
> S Moonesamy wrote:
> > Hi Bernard,

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 12 Sep 2014 08:21:43 -0400

As the saying goes, 'possession is nine tenths of the law.'  If I give 
you a car, and don't renew my registration, and never got the title back 
from the bank after paying off the loan - given enough time, you might 
well be able to claim that you own my car.  There are plenty of 
precedents regarding "squater's rights" and disputes over property lines 
being decided by the passage of enough time.

We are dealing with a legal and regulatory matter here. Undocumented 
code can still run.  When dealing with laws, regulations and contracts, 
we have to get the paperwork right.

Seun Ojedeji wrote:
> sametime I also said you may drive the car to Y location (if you 
> wish). Does it mean that you own the car?
>
> Cheers!
>
> sent from Google nexus 4
> On 12 Sep 2014 01:31, "Dave Crocker" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     bbiw.net <http://bbiw.net>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Seun Ojedeji <[email-masked]>
Date: Fri, 12 Sep 2014 13:37:55 +0100

I agree....legal interpretation may not necessarily equate with
common-sense. :)

Thanks

Regards

On Fri, Sep 12, 2014 at 1:21 PM, Miles Fidelman <[email-masked]>
wrote:

> As the saying goes, 'possession is nine tenths of the law.'  If I give you
> a car, and don't renew my registration, and never got the title back from
> the bank after paying off the loan - given enough time, you might well be
> able to claim that you own my car.  There are plenty of precedents
> regarding "squater's rights" and disputes over property lines being decided
> by the passage of enough time.
>
> We are dealing with a legal and regulatory matter here. Undocumented code
> can still run.  When dealing with laws, regulations and contracts, we have
> to get the paperwork right.
>
> Seun Ojedeji wrote:
>
>>
>> On 12 Sep 2014 01:31, "Dave Crocker" <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2014 05:40:15 -0700

> I agree....legal interpretation may not necessarily equate with

Luckily, this isn't one of those situations.

Common sense strongly advises against simplistic assumptions of
best-case outcomes in arrangements between independent organizations.

d/

---

From: Eliot Lear <[email-masked]>
Date: Fri, 12 Sep 2014 14:50:37 +0200

Miles,

> Just one man's opinion, of course.

As has been repeatedly mentioned, there is a termination clause in our
MoU.  Let me ask you this question: what more might be required, and
what would it accomplish above and beyond what we have?  Please be specific.

Eliot

---

From: Milton L Mueller <[email-masked]>
Date: Fri, 12 Sep 2014 13:37:31 +0000

> The touchstone to reality is that an IETF decision to re-home the IETF's IANA
> functions would be unlikely to be able to take the IANA domain name.  It's a
> touchstone because it is an indication that IANA is now publicly perceived as
> an ICANN function and ICANN's IANA functions /already/ include more than
> the IETF functions.
> 

This is a non-issue. Registration of the IANA domain could easily be included as part of any transition plan. It is a detail, though it is one that should not be overlooked. If IETF and the protocol community decide that they want their contract to provide IANA functions to include rights to the IANA domain, put that into the RFP. Then it becomes part of the transition agreement with NTIA and ICANN will have to abide by it

Milton L Mueller
Laura J and L. Douglas Meredith Professor 
Syracuse University School of Information Studies
http://faculty.ischool.syr.edu/mueller/

---

From: Milton L Mueller <[email-masked]>
Date: Fri, 12 Sep 2014 13:41:26 +0000

From: Ianaplan [mailto:[email-masked]] On Behalf Of Seun Ojedeji

A succession plan is about thinking about the future.  According to publicly available information "The Internet Assigned Numbers Authority (IANA) is a department of ICANN".  It is highly improbably that it can be changed.

Why do people say things like this? Nothing in the NTIA announcement says that IANA is a department of ICANN and must ever so remain. It is perfectly possible to change it. Nothing stops any one of the 3 operational communities from proposing whatever IANA arrangements have broad levels of support in those communities. Argue the merits – do not invent constraints that don’t exist.
--MM

---

From: Milton L Mueller <[email-masked]>
Date: Fri, 12 Sep 2014 13:50:21 +0000

> contractual agreements - strikes me as absolutely wrongheaded.  

I agree. Most people who think about it also agree. Does anyone not agree?

---

From: Seun Ojedeji <[email-masked]>
Date: Fri, 12 Sep 2014 14:55:58 +0100

sent from Google nexus 4
>
>
>
>
>
> Why do people say things like this? Nothing in the NTIA announcement says
that IANA is a department of ICANN and must ever so remain.
But something in the NTIA contract said so? I think the separation was
initiated/maintained by the communities.

It is perfectly possible to change it. Nothing stops any one of the 3
operational communities from proposing whatever IANA arrangements have
broad levels of support in those communities.
I think the point is that it's not ICANN as an organisation that will be
doing that but rather the relevant communities which IMHO would be an
acceptable approach.

Cheers!
.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2014 06:59:12 -0700

On 9/12/2014 6:37 AM, Milton L Mueller wrote:
>> So we might take our assignment marbles and go somewhere else, but
>> it won't be called IANA.  Or, at least, there will still be an IANA
>> at ICANN.
> 
> This is a non-issue. Registration of the IANA domain could easily be
> included as part of any transition plan. It is a detail, though it is
> one that should not be overlooked. If IETF and the protocol community
> decide that they want their contract to provide IANA functions to
> include rights to the IANA domain, put that into the RFP. Then it
> becomes part of the transition agreement with NTIA and ICANN will
> have to abide by it

The difference between theory and practice is always minimal, in theory.
 In practice, however...

In other words, it very much /is/ an issue, having to do with far more
than minor details.  A contract that assumes best-case scenarios is sure
to disappoint at least one of the parties.

The messy reality of operational pragmatics is always distasteful, but
always necessary.  If that reality isn't covered in the agreement, the
result will be a highly problematic transition -- possibly including
failure -- should a transition be deemed necessary.

The point is that the current contract language is inadequate for
covering a possible move to a different provider.  So it needs to be
made adequate.

d/

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Fri, 12 Sep 2014 10:24:50 -0400

I think the issue can be separated into 2 different problems:

1/  ICANN (or any one corporation) being enshrined as the permanent and 
unchangeable provider of registries for Internet protocols.  (Borrowing 
from Miles' text).

2/  Whether "IANA" is the permanent and unchangeable name of those 
registries.

I appreciate that several have expressed the belief that "2/" is a given 
("IANA *is* Internet registries") and "1/" is unacceptable.

But if "IANA" comes down to thumb-wrestling over domain name 
registrations and arguing over history, how much effort should the IETF 
make there?  For the IETF's purposes, is "1/" not the most important issue?

BTW, as the IAB occasionally points out, the IETF has in fact on 
occasion chosen other operators for registries (ENUM registry at RIPE 
NCC, for instance).

Leslie.

On 9/12/14 9:59 AM, Dave Crocker wrote:
>>> So we might take our assignment marbles and go somewhere else,
>>> but it won't be called IANA.  Or, at least, there will still be
>>> an IANA at ICANN.
>>
>> This is a non-issue. Registration of the IANA domain could easily
>> be included as part of any transition plan. It is a detail, though
>> it is one that should not be overlooked. If IETF and the protocol
>> community decide that they want their contract to provide IANA
>> functions to include rights to the IANA domain, put that into the
>> RFP. Then it becomes part of the transition agreement with NTIA and
>> ICANN will have to abide by it
>
>
> The difference between theory and practice is always minimal, in
> theory. In practice, however...
>
> In other words, it very much /is/ an issue, having to do with far
> more than minor details.  A contract that assumes best-case scenarios
> is sure to disappoint at least one of the parties.
>
> The messy reality of operational pragmatics is always distasteful,
> but always necessary.  If that reality isn't covered in the
> agreement, the result will be a highly problematic transition --
> possibly including failure -- should a transition be deemed
> necessary.
>

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
[email-masked]
-------------------------------------------------------------------

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2014 07:32:55 -0700

> 2/  Whether "IANA" is the permanent and unchangeable name of those

Worthy distinction.

The issue with 1/ is the ability to move enough information and
operations someplace else; that is, ensuring that the IETF retains
sufficient control over information and procedures to be able to re-home
it.  (I'm told the IETF has a shadow copy of the information; excellent
start.  The question then is the surrounding operational infrastructure
that is needed.)

The issue with 2/ at the least needs to be considered in terms of 1/.
It is possible there also are issues with branding, and the like, that
are relevant for the IETF.  I've no idea what the right answer for
matters in that realm, but I know it is worthy of thoughtful
consideration.  By thoughtful I mean both 'serious' and 'not excessive'...

d/

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 12 Sep 2014 16:38:21 +0200

I also agree, but I'm not sure whether everybody else agrees in full or not.
You may wish to take a look at the exchange of E-Mails starting on 10
September at:

  http://mailman.apnic.net/mailing-lists/ianaxfer/archive/2014/09/

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Milton L
> Mueller
> Sent: vendredi, 12. septembre 2014 15:50
> To: 'Miles Fidelman'
> Cc: [email-masked]

---

From: Seth Johnson <[email-masked]>
Date: Fri, 12 Sep 2014 09:11:24 -0600

>> 2/  Whether "IANA" is the permanent and unchangeable name of those

FWIW -- I haven't staked out this position.  The issue is more about
"We're talking about an 'IANA Transition' and what it means, so where
we put names can be important in defining the process."  I hardly have
a position, just piped up on a point of being accurate in language
given that it matters.

> consideration.  By thoughtful I mean both 'serious' and 'not excessive'...

This is a very nice way to put the matter, just needs to be noted that
it's predicated on point 2/ as phrased by Leslie.  Just consider
things in terms of what we're defining, not who has the name.  Though
in the end that will matter, and might become a matter of grace from
one perspective or the other.

Seth

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 12 Sep 2014 11:33:30 -0400

One of the complexities here is that the use of the term "IANA" has changed so much over the years.

I suggest that two of the many definitions matter for this conversation: first, the IETF's definition of its area of concern as usually described under the name "IANA" and the descriptor "protocol parameter registries," and second, the definition contained in the "IANA functions contract" between the USG and ICANN. The second definition includes some things under the term "IANA" that we don't, and doesn't say much at all about the work we do care about.

As someone who has many times over some years ground my teeth over the ways in which the terminology has drifted-- for example, to me much of the most important work of "IANA" has nothing at all to do with "the security and stability of the DNS," a phrase which is usually prominent in discussions of "IANA" among those more familiar with ICANN's role than that of the IETF-- I think we need to make sure we're clear about those two definitions and which we're using in anything we write for the ICG. Part of the work here is to map between the definitions so there are no gaps and no inconsistencies between what we mean in the IETF context and what we expect other people to understand, including ICANN and NTIA.

I think Leslie's formulation is a reasonable way of splitting the concerns we're expressing here and clarity about which "IANA" we mean would help discussion of both.

Suzanne

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 12 Sep 2014 08:37:41 -0700

> what would it accomplish above and beyond what we have?  Please be specific.

[BA] Eliot - under RFC 6220,  the answer to that question is not for this WG or the IAB to decide. RFC 6220 makes it clear that contractual issues are owned by the IAOC and IETF Trust. The correct procedure is for those groups along with counsel to analyze the situation and make a recommendation.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 12 Sep 2014 07:00:40 -0700

Hi Seun,
At 03:29 12-09-2014, Seun Ojedeji wrote:
>This was a view i shared a non-IETF list, however some has said that 
>the "departmental" separation was only made possible becuase of the 
>contract and will most likely disappear in absence of the contract. 
>A view i was quite puzzled about.

Is that the Cross Community Working Group [1] mailing list?  I do not 
have access to that mailing list.

The relevant clause for the separation is:

   "The Contractor shall ensure that designated IANA functions staff 
members will
    not initiate, advance, or advocate any policy development related to the
    IANA functions."

If the contract lapses there isn't anything to prevent a merger.

>gist....and i think ensuring the existence of such option is 
>important (even if it doesn't get exercised).

Home is within the jurisdiction of the Commonwealth of Virginia 
(United States).

Regards,
S. Moonesamy

1. 
https://community.icann.org/display/gnsocwgdtstwrdshp/CWG+to+Develop+an+IANA+Stewardship+Transition+Proposal+on+Naming+Related+Functions

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 12 Sep 2014 08:44:16 -0700

>  Why do people say things like this? Nothing in the NTIA announcement says that IANA is a department of ICANN and must ever so remain. It is perfectly possible to change it. Nothing stops any one o…

[BA] Indeed. The NTIA-ICANN contract has many pages devoted to succession planning.  In fact, the current contractor was required to provide a succession plan in April 2014. Reading the contract, it is clear that USG lawyers spent quite a bit of effort to tie down rights issues and ensure that another contractor could be selected in future.

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Sep 2014 10:57:05 -0400

> [BA] I for one would not consider such an outcome acceptable. Note that the NTIA-ICANN contract covers disposition of property and required filing of a plan to deal with the succession to another c…

When the IETF Trust was formed, CNRI transferred ietf.org and iab.org to the Trust.  CNRI transferred iana.org to ICANN at that time.

Russ

---

From: Seun Ojedeji <[email-masked]>
Date: Fri, 12 Sep 2014 18:23:33 +0100

sent from Google nexus 4
kindly excuse brevity and typos.
On 12 Sep 2014 18:12, "Russ Housley" <[email-masked]> wrote:
>
>
> When the IETF Trust was formed, CNRI transferred ietf.org and iab.org to
the Trust.  CNRI transferred iana.org to ICANN at that time.
Uh....? Please can you provide reference to this....need to read up the
content

Thanks

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 12 Sep 2014 13:34:20 -0400

> what would it accomplish above and beyond what we have?  Please be specific.
The termination clause has to state, unequivocally, that "upon 
termination, by either part, the authority to designate the a new IANA 
functions provider, for protocol numbering, reverts to IETF; and that 
ICANN has no authority to continue performing that function."

Miles Fidelman

---

From: S Moonesamy <[email-masked]>
Date: Fri, 12 Sep 2014 10:37:05 -0700

Hello,
At 06:41 12-09-2014, Milton L Mueller wrote:
>Why do people say things like this? Nothing in 
>the NTIA announcement says that IANA is a 
>department of ICANN and must ever so remain. It 
>is perfectly possible to change it. Nothing 
>stops any one of the 3 operational communities 
>from proposing whatever IANA arrangements have 
>Argue the merits – do not invent constraints that don't exist.

As a note to the Working Group Chairs, I do not 
think that any obligation under BCP 79 applies to 
me in this case.  Any (IETF) process guidance is welcome as I could be wrong.

My comment was not about the NTIA 
announcement.  From what I read the rights to the 
"Internet Assigned Numbers Authority" service 
mark was transferred to ICANN.  Neither that mark 
nor the domain name were transferred to the IETF Trust as assets.

If I go to a government official and say that 
"IANA is not a department of ICANN", he or she 
would point me to http://www.iana.org/about  The 
following is from the Whois record:

   Registrant Name:Domain Administrator
   Registrant Organization:ICANN
   Registrant Street: 12025 Waterfront Drive
   Registrant City:Los Angeles
   Registrant State/Province:California

The IANA personnel I personally met nearly a 
month ago ( 
http://data.iana.org/ksk-ceremony/18/KC18_annotated_scripts.pdf 
) are employed by ICANN.  For what it is worth, I 
suggested adding the note at the bottom of Page 2 of that document.

Page 8 of the document at 
http://iaoc.ietf.org/documents/2014-ICANN-IETF-MoU-Supplemental-Agreement-Executed.pdf 
was signed by Elise Gerich, Vice President, IANA, ICANN.

The sentence [1] "It is highly improbably that it 
can be changed." is an opinion.  My opinion is 
based on my experiences [2] of ICANN.  I am okay 
if anyone says that I am wrong.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/ianaplan/current/msg00230.html
2. I do not think that it bears much weight.

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 12 Sep 2014 13:52:02 -0400

> ICANN has no authority to continue performing that function."
Make that "upon termination, by either party, the authority to designate 
the a new IANA functions provider, for protocol numbering, reverts to 
IETF; and that ICANN has no authority to continue performing that 
function."  (typo - said "part" not "party" last time)

Might also not hurt to have a very specific statement in the preamble 
that "IETF is the duly constituted standards body and authority for 
protocol numbers.  Through this agreement, IETF designates ICANN to 
perform the protocol number related IANA functions, as defined and 
delineated below.  This designation and delegation of authority is 
revocable at any time, as detailed in clause <xxx>."

Then have a good lawyer look at the exact language - perhaps someone 
who's been involved in putting together a comparable delegation of 
authority document (maybe the folks who hand out ISBNs, or the folks at 
IEEE or ANSI.)

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 12 Sep 2014 14:00:47 -0400

> covering a possible move to a different provider.  So it needs to be
Exactly!

Contracts are for those situations where things go wrong, or there is a 
difference of interpretation of who's responsible for what, and who has 
what authority to do what.

These kinds of things need to be spelled out very clearly, and ideally 
signed off by all parties - otherwise, if/when things go South, 
everybody will claim "they did it" and "we have the authority to do x" 
and so forth.

As somebody pointed out, the NTIA contract has lots of language re. 
succession - somebody familiar with that language might want to lift it 
wholesale, adapt it to the post-NTIA world, and drop it into ietf's 
proposal.

Miles Fidelman

---

From: Milton L Mueller <[email-masked]>
Date: Fri, 12 Sep 2014 18:07:51 +0000

> From: S Moonesamy [mailto:[email-masked]]
> announcement.  From what I read the rights to the "Internet Assigned
> Numbers Authority" service mark was transferred to ICANN.  Neither that
> mark nor the domain name were transferred to the IETF Trust as assets.
> 
> If I go to a government official and say that "IANA is not a department of
> ICANN", he or she would point me to http://www.iana.org/about  The

S.: 
You are merely reasserting the obvious fact that ICANN controls IANA now (due to a USG contract). That has no bearing on what it will or will not control at the end of this process. No one has said that IANA is not a department of ICANN now - it is. The question is whether that can be changed. It can. Indeed, taken in combination with the broader ICANN accountability process, virtually _anything_ about ICANN, including its jurisdiction of incorporation, its membership structure, its bylaws, its independent review process, its board composition, could in principle be changed as part of the process we are embarking on. 

Bernard has already pointed out that the current IANA contract contains language allowing for the transferability of the functions. Russ has pointed out that the iana.org domain name has already been transferred as part of the first round of ICANN-related changes around 1998. I really don't see any further merit in discussing in the erroneous idea that because ICANN is currently the IANA contractor that this cannot change or is unlikely to change. 

Milton L Mueller

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Sep 2014 14:28:10 -0400

On Fri, Sep 12, 2014 at 01:34:20PM -0400, Miles Fidelman wrote:
> authority to continue performing that function."

I continue to be mystified by the number of people who think that the
legitimacy of IANA registries (in this case, the protocol parameters
one) is somehow founded on "authority" -- as though there is an
Internet Cartman running around yelling at people
(https://www.youtube.com/watch?v=gx4jn77VKlQ).

That's not where the authority comes from.  The authority comes from
people wanting things to work well.  The reason people pick the IETF
protocols is because they increase the odds of interoperation;
correspondingly, when there is no interoperation advantage, people
don't pick IETF protocols.  (Ask about the deployment of IRIS, for
instance.)

So, if the IETF picks another way to publish is protocol parameters,
ICANN's ability to continue publishing protocol parameters might well
continue.  The question would be whether anyone would use them.  If
the IETF is doing a good job, then the answer will be, "No," and we
shouldn't care whether ICANN continues to publish a list of numbers
somewhere.  If the IETF is doing a poor job, the answer might _not_
be, "No," and we shouldn't try to prevent that outcome, either.

IANA's authority follows from it being _useful_, not from it being
Boss of Internets.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 12 Sep 2014 14:41:19 -0400

> Bernard has already pointed out that the current IANA contract contains language allowing for the transferability of the functions. Russ has pointed out that the iana.org domain name has already be…
The point, is to make sure that the IETF (and other) contract(s) that 
succeed the NTIA contract assert the authority to transfer the function, 
and assert that ICANN can't unilaterally lay claim to the function - as 
their charter sort of does.

In the absence of such language - ideally signed by everybody, including 
ICANN - cancellation of the MOU opens up a free for all. Let's try to 
avoid that possibility by including appropriate language in the 
transition plan.

Miles Fidelman

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 12 Sep 2014 14:59:38 -0400

+1

The only “succession” that should be of concern to us is if people shift
away from using IETF protocols (and their parameters). And that has
nothing to do with the NTIA transition.

Alissa

---

From: Seth Johnson <[email-masked]>
Date: Fri, 12 Sep 2014 13:15:07 -0600

(Just for reference) There is more though: the stress on authority is
important in relation to the concerns of those pursuing broader
"Internet-related public policy" in "less mathematically pure" areas
in connection with the broader context of the WSIS project and its
goals.  Walking blindly into the implications there is my (mostly
quiet) concern.  :-)

Seth

> IANA's authority follows from it being _useful_, not from it being

On Fri, Sep 12, 2014 at 12:41 PM, Miles Fidelman
<[email-masked]> wrote:
>> You are merely reasserting the obvious fact that ICANN controls IANA now
>> (due to a USG contract). That has no bearing on what it will or will not
>> control at the end of this process. No one has said that IANA is not a
>> department of ICANN now - it is. The question is whether that can be
>> changed. It can. Indeed, taken in combination with the broader ICANN
>> accountability process, virtually _anything_ about ICANN, including its
>> jurisdiction of incorporation, its membership structure, its bylaws, its
>> independent review process, its board composition, could in principle be
>> changed as part of the process we are embarking on.
>>
>> Bernard has already pointed out that the current IANA contract contains
>> language allowing for the transferability of the functions. Russ has pointed
>> out that the iana.org domain name has already been transferred as part of
>> the first round of ICANN-related changes around 1998. I really don't see any
>> further merit in discussing in the erroneous idea that because ICANN is
>> currently the IANA contractor that this cannot change or is unlikely to
>> change.
>>
>>
> succeed the NTIA contract assert the authority to transfer the function, and
> assert that ICANN can't unilaterally lay claim to the function - as their
> charter sort of does.
>
> ICANN - cancellation of the MOU opens up a free for all. Let's try to avoid
> that possibility by including appropriate language in the transition plan.
>
> Miles Fidelman
>
> --

---

From: David Conrad <[email-masked]>
Date: Fri, 12 Sep 2014 12:19:55 -0700

Hi,

I’ve been hesitant to engage in these particular discussions as I suspect I may be viewed as a bit conflicted (:)), however I just wanted to strongly emphasize what Andrew has said here (so much so that I’ll repeat it in full):

> IANA's authority follows from it being _useful_, not from it being

To be honest, a large proportion of this discussion has baffled me.  It’s as if people didn’t really believe the “bottom up, (rough) consensus driven” chorus they’ve been singing for _decades_.

No single entity, not ICANN, not NTIA, not the IAB, _NO_ one, has the ability to define the “authority to continue performing that function”.

That authority comes from the consent of the users of the services (aka http://en.wikipedia.org/wiki/Consent_of_the_governed). 

The _only_ place (at least today) I can think of where things get complicated is in relation to the root of the DNS due to the hierarchical nature of the DNS (particularly when enforced by DNSSEC) and the difficulty in updating the infrastructure to reflect a change of root servers/KSK, but that’s not relevant to this discussion (I think).

Regards,
-drc
(ICANN CTO but speaking only for myself)

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2014 12:20:50 -0700

> nothing to do with the NTIA transition.
...
>> continue.  The question would be whether anyone would use them. 

The good news is that the above views mean that we don't need to have
any further discussions.  In fact it means we really don't even need an
agreement.  The arrangement simply operates on good faith and the
general 'will' of the Internet community.

The bad news is that that's an entirely unrealistic view, to level of
being professionally irresponsible.  (Sorry for being that frank, but
the tendency to want to hand-wave away these concerns is long-standing,
striking and dangerous.)

There are good and classic reasons for having a formal agreement.  And
formal agreements have good and classic aspects to be specified.

Exit issues are among those aspects.

If the agreement is to reflect a responsible IETF position, it needs a
responsible specification of exit issues and requirements.

d/

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 12 Sep 2014 16:09:25 -0400

"Legitimacy" is a significant consideration in whether people use 
protocols or not - particularly when it comes to vendors implementing 
protocols in mass market products.

When there's clear agreement on things among voluntary standards 
activities, it's more likely for vendors to adopt the standards, than to 
push their own proprietary stuff.  When there's murkiness, or conflict, 
among standards activities - things tend to get abused.

One example that comes to mind of late is DMARC, and all the havoc it's 
wrought in the world of email lists.  If somebody (IETF perhaps) had 
been more aggressive and assertive - perhaps Yahoo would not have 
foisted such disruptive change on so many people.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 12 Sep 2014 13:12:32 -0700

Dave Crocker said:

"Exit issues are among those aspects.

If the agreement is to reflect a responsible IETF position, it needs a
responsible
specification of exit issues and requirements."

[BA] Or at least an analysis of the issues, by someone with the
qualifications to do so (e.g. a lawyer).

For all we know, the issues might be relatively easy to resolve *prior to
the transition*.   Afterwards, and in the middle of a dispute - that could
be another story entirely.

However, without at least some analysis, I would not be willing to bet very
much on assertions by non-lawyers that there are "no issues".   Especially
after having dealt with *rights issues for years.   And especially after
seeing proposals for other communities that *do* include such a "gap"
analysis.

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 12 Sep 2014 16:29:38 -0400

Dave,

Before we go around calling anyone "unrealistic" and "irresponsible," perhaps we should consider the discussion in context. It seems to me that Andrew and Alissa are arguing that formal agreements are a) a really good idea, just as they were in 2000, and b) most likely to work in the case that they're founded on realism about the basis for the relationship among the entities involved.

What they (and David Conrad, and a couple of other people) have said in this thread about the underlying relationship here has always seemed true to me as well. People use the protocol parameters registries for which the IETF provides the policy and ICANN provides the implementation because it serves *their* purposes; an interoperable internet, with no ambiguity about what sequence of bits a program should look for after a particular RRTYPE value or IP option code, is simply easier to use, build on, and innovate with. If that stops being the case, due to any fault of ICANN, the IETF, or neither, no one can force programmers or operators or users to keep referring to those registries.

The argument for a good, strong agreement between ICANN and the IETF is that it increases the chances that people will continue to find the protocol parameters registries trustworthy and useful, even if something goes off the rails between those organizations….not that it's either necessary or sufficient for that purpose.

Or should we pretend that either ICANN or the IETF has more control over what happens to "the Internet" than they do? That seems a bit….unrealistic as the basis for a contract, or a discussion about succession, or anything else.

Suzanne
(no hats at all)

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Sep 2014 16:36:06 -0400

On Fri, Sep 12, 2014 at 12:20:50PM -0700, Dave Crocker wrote:
> any further discussions. 

Poppycock.  What it means is that we have to document the way things
actually work.  That includes …

> Exit issues are among those aspects.

…these.  Which I believe are documented already in the existing MoU.  

But anyway, I was reacting to the (IMO preposterous) idea that anybody
could try to be Boss of the Parameters and tell others that they don't
have the authoriteh to publish such a list of parameters.  We don't
have that kind of power, neither does anybody else, and in my opinion
we shouldn't want it, either.  I was certainly not suggesting that we
shouldn't document our interactions with the IANA contractor, or have
a mechanism to change that, or have other redress mechanisms (such as
our recall procedures, for instance).  That's all perfectly good
stuff, and it needs to be written down, and if the basis for any of it
is in fact in the NTIA-ICANN agreement, then we need to find a way to
underpin it differently.  But that's it.

> the tendency to want to hand-wave away these concerns is long-standing,

I was unaware that I'd had an opinion about this for long enough to
qualify as "long-standing".  If you have other names to call me,
however, I'll welcome you to do it off list so that we here can focus
on the substance instead.  Thanks.

Dangerously,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 12 Sep 2014 17:48:10 -0400

Hi Dave,

> responsible specification of exit issues and requirements.

My issue is that I think the list of what is required (and does not
already exist) to be able to successfully transition the protocol
parameters function to some other operator is basically empty. I do not
think ownership of iana.org or of the “IANA” trademark are required. I do
not think binding dear Michelle Cotton to us forevermore is required
(although I sure wish we could do that :)). I do not think a contract in
which ICANN agrees to stop publishing a version of the parameters even if
we enlist a different operator to publish them is necessary. Would these
things be nice? Sure. Are they necessary? Certainly not. And I’m in firm
agreement with Brian that re-opening the existing MOU should be avoided
unless we have a really compelling reason to do so.

If there are steps we want to explore as nice-to-haves outside of changes
to the MOU (e.g., the transfer of copyrights from ICANN to the IETF Trust,
as has been discussed on this list and elsewhere), we should certainly tee
those up for the Trust, IAOC, and/or IAB to think about, but we shouldn’t
treat them as requirements.

Alissa

---

From: David Conrad <[email-masked]>
Date: Fri, 12 Sep 2014 18:04:15 -0700

Miles,

On Sep 12, 2014, at 1:09 PM, Miles Fidelman <[email-masked]> wrote:
> "Legitimacy" is a significant consideration in whether people use protocols or not - particularly when it comes to vendors implementing protocols in mass market products.

I thought we were talking about who edits the text files that makes it a bit more convenient to figure out what bit patterns go where (the alternative being going through RFCs and mailing lists) rather than the legitimacy of the IETF as a standards making body.

I personally believe it makes perfect sense to come up with mutual agreements on descriptions of how things are edited, service level specifications describing what’s acceptable for editing, what to do if the editing is done poorly, etc. (stuff the IETF community has largely already done or is doing with respect to protocol parameters). If there are areas in which additional clarity is needed, I can’t see how seeking that clarity would be bad.

But all that seems to be unrelated to giving legitimacy to the IETF.

Regards,
-drc
(ICANN CTO, but speaking only for myself)

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 12 Sep 2014 21:18:33 -0400

> But all that seems to be unrelated to giving legitimacy to the IETF.
Legitimacy to the PROCESS which includes clear roles and 
responsibilities, along with who has the final say in things.

Miles Fidelman

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Sep 2014 14:35:01 +1200

On 13/09/2014 06:41, Miles Fidelman wrote:
>> You are merely reasserting the obvious fact that ICANN controls IANA
>> now (due to a USG contract). That has no bearing on what it will or
>> will not control at the end of this process. No one has said that IANA
>> is not a department of ICANN now - it is. The question is whether that
>> can be changed. It can. Indeed, taken in combination with the broader
>> ICANN accountability process, virtually _anything_ about ICANN,
>> including its jurisdiction of incorporation, its membership structure,
>> its bylaws, its independent review process, its board composition,
>> could in principle be changed as part of the process we are embarking on.
>>
>> Bernard has already pointed out that the current IANA contract
>> contains language allowing for the transferability of the functions.
>> Russ has pointed out that the iana.org domain name has already been
>> transferred as part of the first round of ICANN-related changes around
>> 1998. I really don't see any further merit in discussing in the
>> erroneous idea that because ICANN is currently the IANA contractor
>> that this cannot change or is unlikely to change.
>>
>>
> ICANN - cancellation of the MOU opens up a free for all. 

No it doesn't. In the absence of the NTIA contract, the
contractual document in force will be the IETF/ICANN MoU, which
already includes a perfectly clear termination clause. If the
MoU is terminated, it automatically becomes the IAB's duty to
approve a new organisation to act as the IETF's IANA.

Note that the MoU's scope is carefully stated "exclusively to
define the technical work to be carried out by the Internet
Assigned Numbers Authority on behalf of the Internet Engineering
Task Force and the Internet Research Task Force." That is the
work that will cease if the MoU is cancelled, and since it's
work done for the I*TF, we are entitled to the work product,
i.e. the current registry contents.

IANAL but this text was carefully reviewed by our counsel at the
time.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Sep 2014 14:39:11 +1200

> make there?  For the IETF's purposes, is "1/" not the most important issue?

Exactly. It would be slightly annoying to have to
s/iana.org/ietf-iana.org/ everywhere, but it really wouldn't
matter in any fundamental way. I think that was our contingency
plan back in 1998/2000, which fortunately we didn't have to
execute or even write down. But it would take about 5 minutes to
dust it off if we needed to.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 13 Sep 2014 14:45:01 +1200

Hi David,

> I’ve been hesitant to engage in these particular discussions as I suspect I may be viewed as a bit conflicted (:)), however I just wanted to strongly emphasize what Andrew has said here (so much so…

So I'll snip it out again (although I agree too)...

...
> That authority comes from the consent of the users of the services (aka http://en.wikipedia.org/wiki/Consent_of_the_governed). 

Yes. That's why the IAB charter says  "The IAB must approve the
appointment of an organization to act as IANA on behalf of the
IETF" with emphasis on *approve* and the act of appointment
being left rather mysterious.

To be blunt, it doesn't matter which organisation hosts
IETF-IANA. It only matters that they do it right.

   Brian

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2014 20:11:29 -0700

> IETF-IANA. It only matters that they do it right.

Unfortunately that statement isn't blunt; it's entirely vague.

Good sound bite, but no substance that helps with the operational details.

It has literally nothing to do with the pragmatics of ensuring that a
transition to an alternate provider would be viable.  What does ensure
that is serious language in the agreement.  Language that has enough
substance to be useful.

d/

---

From: David Conrad <[email-masked]>
Date: Fri, 12 Sep 2014 20:41:06 -0700

Dave,

> Unfortunately that statement isn't blunt; it's entirely vague.

Not really, if you take “do it right” to mean abide by the IANA-related contracts found at https://iaoc.ietf.org/contracts.html

> transition to an alternate provider would be viable.  

I’m honestly curious: suppose ICANN screws up to the point where the IETF decides to exercise the termination clause of 2860.  6220 seems to me to lay out pretty much all the requirements necessary for the IETF to initiate an RFP to choose another protocol parameter function operator. In your view, what “pragmatics of ensuring that a transition to an alternative provider would be viable” are missing?

Thanks,
-drc

---

From: Seun Ojedeji <[email-masked]>
Date: Sat, 13 Sep 2014 06:57:06 +0100

sent from Google nexus 4
No, on the 1net list

http://1net-mail.1net.org/pipermail/discuss/2014-September/004763.html

members will
> If the contract lapses there isn't anything to prevent a merger.

But I thought the community MOU (namely the RIR and IETF) also has some
clear separation clauses and wouldn't that still prevent a merger?

Anyway if it's observed that is not adequate, then a community agreement
(some call it contract) that would allow the 3 communities option to
reassign their own part of the function would be in order.

>
>
> Home is within the jurisdiction of the Commonwealth of Virginia (United
States).
Home is now more global than that you know ;)

Cheers!

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 13 Sep 2014 10:03:14 +0200

Please see below.

Thanks and best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Suzanne
> Woolf
> Sent: vendredi, 12. septembre 2014 22:30
> To: [email-masked]
> Cc: [email-masked]; Alissa Cooper; Andrew Sullivan
> Before we go around calling anyone

I understood David Crocker's comments to refer to a view, or position, or
statement, not to a person.

> "unrealistic" and
> "irresponsible," perhaps we should consider the discussion in
> context. It seems to me that Andrew and Alissa are arguing that
> formal agreements are a) a really good idea, just as they were in
> 2000, and b) most likely to work in the case that they're founded
> on realism about the basis for the relationship among the
> entities involved.

Indeed.  But different people might have different views regarding what is
realistic.

>
> What they (and David Conrad, and a couple of other people) have
> said in this thread about the underlying relationship here has
> always seemed true to me as well. People use the protocol
> parameters registries for which the IETF provides the policy and
> ICANN provides the implementation because it serves *their*
> purposes; an interoperable internet, with no ambiguity about what
> sequence of bits a program should look for after a particular
> RRTYPE value or IP option code, is simply easier to use, build
> on, and innovate with. If that stops being the case, due to any
> fault of ICANN, the IETF, or neither, no one can force
> programmers or operators or users to keep referring to those registries.

Indeed, and I think we all agree on that.  And we agree that the issue at
hand is how to minimize the probability that that might "stop being the
case".

>
> The argument for a good, strong agreement between ICANN and the
> IETF is that it increases the chances that people will continue
> to find the protocol parameters registries trustworthy and
> useful, even if something goes off the rails between those
> organizations….not that it's either necessary or sufficient for
> that purpose.

Agreed.  As far as I can tell, the disagreement is whether or not the
current agreements between IETF and ICANN will be sufficiently strong if the
contract between ICANN and NTIA no longer exists.

And that is a matter of interpretation of legal text, on which reasonable
people can have different views.

>
> Or should we pretend that either ICANN or the IETF has more
> control over what happens to "the Internet" than they do? That
> seems a bit….unrealistic as the basis for a contract, or a
> discussion about succession, or anything else.
>
>
> Suzanne
> (no hats at all)
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 13 Sep 2014 07:34:09 -0700

Alissa Cooper said:

"And I’m in firm agreement with Brian that re-opening the existing MOU
should be avoided unless we have a really compelling reason to do so."

[BA] Brian stated (and I agree) that handling rights issues *would not*
require re-opening the MOU:
http://www.ietf.org/mail-archive/web/ianaplan/current/msg00178.html

"If there are steps we want to explore as nice-to-haves outside of changes
to the MOU (e.g., the transfer of copyrights from ICANN to the IETF Trust,
as has been discussed on this list and elsewhere), we should certainly tee
those up for the Trust, IAOC, and/or IAB to think about"

[BA] In particular, it would be useful for the IETF Trust to have advice
from counsel on this.  That might include an understanding of *who* (e.g.
ICANN or the USG) owns the rights the IETF Trust would like to have
transferred.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 13 Sep 2014 09:01:12 -0700

On 9/12/2014 8:41 PM, David Conrad wrote:
>> It has literally nothing to do with the pragmatics of ensuring that
>> a transition to an alternate provider would be viable.
> 
> I’m honestly curious: suppose ICANN screws up to the point where the
> IETF decides to exercise the termination clause of 2860.  6220 seems
> to me to lay out pretty much all the requirements necessary for the
> IETF to initiate an RFP to choose another protocol parameter function
> operator. In your view, what “pragmatics of ensuring that a
> transition to an alternative provider would be viable” are missing?

First of all, didn't ICANN have a requirement to provide a report that
should/would include answering your question?  I'm told it was due this
past Spring.  Might be nice to see a pointer to that report.

In any case, broadly, what is required is an audit of the information
and procedures needed to operate the registries, and contractual
language obligating ICANN to assist in achieving a successful transition.

In other words, RFC 2860 and RFC 6220 have no language that covers any
of this, nor does the exisint MOU, nevermind also lacking any formal
obligation for ICANN to follow it.

What is impressive in this sequence is the resistance to common due
diligence for operational issues.  Hence my reference to professional
irresponsibility.  (And it's nice that someone noticed I didn't assert
that about a person, but about an action, or rather inaction.)

d/

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 13 Sep 2014 09:10:15 -0700

Brian Carpenter said:

"That is the work that will cease if the MoU is cancelled, and since it's work
done for the I*TF, we are entitled to the work product, i.e. the current
registry contents."

[BA]  The NTIA-ICANN contract contains its own clauses relating to
ownership of work product and deliverables, which do not mention the IETF.
 So the legal analysis done in 2000 probably needs to be revisited.

---

From: S Moonesamy <[email-masked]>
Date: Sat, 13 Sep 2014 09:01:12 -0700

Hi Seun,
>No, on the 1net list

Thanks.

>But I thought the community MOU (namely the RIR and IETF) also has 
>some clear separation clauses and wouldn't that still prevent a merger?

No (commenting about IETF 
only).  http://www.rfc-editor.org/rfc/rfc6890.txt might explain the opinion.

Regards,
S. Moonesamy

---

From: Seun Ojedeji <[email-masked]>
Date: Sat, 13 Sep 2014 18:04:28 +0100

Hello SM,

If you look at the MOU[1], you will observe that IANA is referenced to in
all the action based statement. Especially in relation to item 4[2] of the
MOU and the wordings in the MOU indicates that IETF has clearly described
how IANA will handle its functions. I would expect that before IANA can
seize to exist(because that is what a merger will mean), it will be on
mutual agreement between the relevant communities (in this case, the IETF
for the protocol aspect).

My point is that the MOU will need to be re-written and agreed to by both
parties. However you seem to imply that ICANN can on its own do this?

Regards
1.
https://www.icann.org/resources/unthemed-pages/ietf-icann-mou-2000-03-01-en
2. Does this section make no difference: ".....In the event ICANN adopts a
policy that prevents it from complying with the provisions of this Section
4 with respect to the assignments described in (a) - (c) above, ICANN will
notify the IETF, which may then exercise its ability to cancel this MOU
under Section 2 above...."

On Sat, Sep 13, 2014 at 5:01 PM, S Moonesamy <[email-masked]> wrote:

> No (commenting about IETF only).  http://www.rfc-editor.org/rfc/
> rfc6890.txt might explain the opinion.
>
> Regards,
> S. Moonesamy
>

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 13 Sep 2014 13:14:02 -0400

> obligation for ICANN to follow it.

One might also want to consider consolidating language that is spread 
around between multiple RFCs and the MoU - into a single contractual 
document with real teeth.

> that about a person, but about an action, or rather inaction.)

Some of us noticed :-)

Miles

---

From: Avri Doria <[email-masked]>
Date: Sat, 13 Sep 2014 13:18:26 -0400

+1

avri

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 13 Sep 2014 13:31:04 -0400

Seun Ojedeji wrote:
> Hello SM,
>
> If you look at the MOU[1], you will observe that IANA is referenced to 
> in all the action based statement. Especially in relation to item 4[2] 
> of the MOU and the wordings in the MOU indicates that IETF has clearly 
> described how IANA will handle its functions. I would expect that 
> before IANA can seize to exist(because that is what a merger will 
> mean), it will be on mutual agreement between the relevant communities 
> (in this case, the IETF for the protocol aspect).
>
> My point is that the MOU will need to be re-written and agreed to by 
> both parties. However you seem to imply that ICANN can on its own do this?
>
> Regards
> 1. 
> 2. Does this section make no difference: ".....In the event ICANN 
> adopts a policy that prevents it from complying with the provisions of 
> this Section 4 with respect to the assignments described in (a) - (c) 
> above, ICANN will notify the IETF, which may then exercise its ability 
> to cancel this MOU under Section 2 above...."
>
As I read the MOU (at least the original 2000 version, and the latest 
2014 amendment) I could only find this:

"ICANN agrees that during the term of this MOU it shall cause IANA to 
comply, for protocols within IETF's scope, with the following 
requirements, which ICANN and IETF acknowledge reflect the existing 
arrangements under which the IANA is operated"

and nothing about what happens, or what ICANN can or can't do, in the 
event of expiration or cancellation of the contract.  Can somebody point 
me to specific language, if it exists?

In the absence of the NTIA contract, or such language, it strikes me 
that ICANN can point to this language, from its articles of incorporation:

3. .... pursue the charitable and public purposes of lessening the 
burdens of government and promoting the global public interest in the 
operational stability of the Internet by (i) coordinating the assignment 
of Internet technical parameters as needed to maintain universal 
connectivity on the Internet; (ii) performing and overseeing functions 
related to the coordination of the Internet Protocol ("IP") address 
space; (iii) performing and overseeing functions related to the 
coordination of the Internet domain name system ("DNS"), including the 
development of policies for determining the circumstances under which 
new top-level domains are added to the DNS root system; (iv) overseeing 
operation of the authoritative Internet DNS root server system; and (v) 
engaging in any other related lawful activity in furtherance of items 
(i) through (iv).

And... worst case.. a free-for-all erupts.

Miles Fidelman

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Sep 2014 08:45:50 +1200

>> both parties. However you seem to imply that ICANN can on its own do

ICANN is free to determine its own internal arrangements for how it
performs the IANA function, as long as they perform it correctly.

> me to specific language, if it exists?

I don't understand what is hard to understand about the cancellation
of the MoU. When it ends, ICANN ceases to perform the IANA function
for the IETF and IRTF. What happens after that is up to the IETF and
IRTF (and we'd have 6 months to plan it).

This is all much simpler than some people seem to think.

    Brian

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 13 Sep 2014 16:59:11 -0400

> IRTF (and we'd have 6 months to plan it).

Where in the MoU does it say that ICANN can't continue to maintain 
protocol number registries, on its own?  Given that iana.org is 
registered to ICANN (as others have pointed out), what's to prevent 
ICANN from continuing to publish protocol registries under the iana.org 
domain - say
http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml#address-family-numbers-2

I don't see any cease and desist language in the MoU.  If it's there, 
please point out where.

Miles Fidelman

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 13 Sep 2014 15:26:39 -0700

Dave Crocker said:

"What is impressive in this sequence is the resistance to common due
diligence for operational issues.  Hence my reference to professional
irresponsibility.  (And it's nice that someone noticed I didn't assert
that about a person, but about an action, or rather inaction.)"

[BA] RFC 6220 makes it clear who is responsible for carrying out this due
diligence, and it isn't the IANAPLAN WG or the IAB.  Rather it is the IAOC
that owns contractual issues and the IETF Trust that owns dealing with
rights issues.  If we do not believe that the IAOC and/or IETF Trust are
the right groups to carry out those responsibilities, then the correct
thing to do is to author an RFC 6220bis describing who should own them
instead.   But until that happens, they are on the hook.

I don't think we can infer from discussions on this list whether in fact
the IAOC/IETF Trust are engaged on this or not, so it seems premature to
conclude that they are not carrying out due diligence.  Since IAOC members
have been involved with NTIA-ICANN contract matters in the past, as well as
development and approval of the annual SLAs, they do have a history of
engagement and in my experience, they have been quite responsive when input
was needed.

That individuals on this list believe the IAOC may have nothing to do does
not really bear upon the IAOC and IETF Trust responsibilities.  Those
opinions are no more relevant than IETF participant opinions on any other
IAOC or IETF Trust matter - it is input to the decision makers, nothing
more.  The IANAPLAN WG Charter did not invalidate RFC 6220, nor did it
change the charters of the IAB or IAOC.

Therefore these issues are for the IAOC/IETF Trust to decide - that's the
role they accepted when they were installed by the nomcom.  Presumably when
they do form an opinion, they will fill in the IETF community on the logic
behind their recommendation.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 14 Sep 2014 00:33:10 +0200

Miles,

> ICANN has no authority to continue performing that function."

Thank you for being specific.  I am opening atracking issue
<https://github.com/elear/IANA-Transition/issues/22> on this text.  To
be clear: you are asking to reopen or amend 2860 in this process.  By
doing so, I am not saying that I support the above text.  As to my
personal opinion, I am not convinced one way or another.  Yet.  I agree
with those who state that at the very least we should seek review of
this issue by counsel.

Eliot

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 13 Sep 2014 15:53:25 -0700

Eliot said:

"Thank you for being specific.  I am opening a tracking issue
<https://github.com/elear/IANA-Transition/issues/22> on this text.  To be
clear: you are asking to reopen or amend 2860 in this process.  By doing
so, I am not saying that I support the above text.  As to my personal
opinion, I am not convinced one way or another.  Yet.  I agree with those
who state that at the very least we should seek review of this issue by
counsel."

[BA] I would support review by counsel.

As to whether an amendment to RFC 2860 is needed, it should be kept in mind
that there may be multiple ways to address potential issues without an
amendment.

One definition of a well written contract is one that does not require
frequent amendments.  Over the years, many operational issues have arisen,
some quite serious,  and yet we have somehow always managed to deal with
them in the annual SLAs rather than requiring an MOU amendment.

Similarly, the NTIA-ICANN contract has clauses that deal with issues such
as succession, but there is also "user documentation" accepted by both
ICANN and the "affected parties" that deals with operational details.  If
the NTIA-ICANN contract had attempted to handle all these details in the
main body, it would have been hundreds of pages longer than it is.

On Sat, Sep 13, 2014 at 3:33 PM, Eliot Lear <[email-masked]> wrote:

> functions provider, for protocol numbering, reverts to IETF; and that ICANN
> has no authority to continue performing that function."
>
>
> Thank you for being specific.  I am opening a tracking issue
> <https://github.com/elear/IANA-Transition/issues/22> on this text.  To be
> clear: you are asking to reopen or amend 2860 in this process.  By doing
> so, I am not saying that I support the above text.  As to my personal
> opinion, I am not convinced one way or another.  Yet.  I agree with those
> who state that at the very least we should seek review of this issue by
> counsel.
>
> Eliot
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 13 Sep 2014 23:56:53 +0100

On 13/09/14 23:33, Eliot Lear wrote:
>> termination, by either part, the authority to designate the a new
>> IANA functions provider, for protocol numbering, reverts to IETF;
>> and that ICANN has no authority to continue performing that
>> function."
> 
> <https://github.com/elear/IANA-Transition/issues/22> on this text.
> To be clear: you are asking to reopen or amend 2860 in this
> process.  By doing so, I am not saying that I support the above
> text.  As to my personal opinion, I am not convinced one way or
> another.

I don't get it. Anyone can define a protocol. Those can use
numbers. Anyone can create a registry for those numbers.

And I'm sorry if this seems unprofessional but it seems to
me that lots of this discussion is mostly about non-existent
angels on the non-existent heads of non-existent pins.

The IETF does not have a monopoly on being successful in
protocol design and success in that game necessitates an
IANA-like protocol-parameters function. And that's even
more true of ICANN which isn't really even in that game.

(Or, see Andrew Sullivan's earlier mail, with which I fully
agree.)

> Yet.  I agree with those who state that at the very least we should
> seek review of this issue by counsel.

A review of what exactly? Again, sorry for being dim but
I don't get it.

S.

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

---

From: S Moonesamy <[email-masked]>
Date: Sat, 13 Sep 2014 16:09:08 -0700

Hi Seun,
At 10:04 13-09-2014, Seun Ojedeji wrote:
>If you look at the MOU[1], you will observe that IANA is referenced 
>to in all the action based statement. Especially in relation to item 
>4[2] of the MOU and the wordings in the MOU indicates that IETF has 
>clearly described how IANA will handle its functions. I would expect 
>that before IANA can seize to exist(because that is what a merger 
>will mean), it will be on mutual agreement between the relevant 
>communities (in this case, the IETF for the protocol aspect).
>

My comment was about whether a merger could happen. :-)

I read RFC 2860 [1] several times.  It looks like you and I are 
looking at the MoU from different angles.

I'll rewrite some text:

    In the event a RIR adopts a policy that prevents it from complying
    with the provisions of this Section 4 with respect to the assignments
    described in (a) - (c) above, the RIR will notify the IETF, which may
    then exercise its ability to cancel this MOU under Section 2 above.

or:

    In the event an ICANN Constituency adopts a policy that prevents it from
    complying with the provisions of this Section 4 with respect to the
    assignments described in (a) - (c) above, the ICANN Constituency 
will notify
    the IETF, which may then exercise its ability to cancel this MOU under
    Section 2 above.

In my opinion the real discussion is not about protocol parameter registries.

Regards,
S. Moonesamy

1. http://www.rfc-editor.org/rfc/rfc2860.txt

---

From: Milton L Mueller <[email-masked]>
Date: Sat, 13 Sep 2014 23:53:16 +0000

> In any case, broadly, what is required is an audit of the information and
> procedures needed to operate the registries, and contractual language
> obligating ICANN to assist in achieving a successful transition.
> 
> In other words, RFC 2860 and RFC 6220 have no language that covers any of
> this, nor does the exisint MOU, nevermind also lacking any formal obligation for
> ICANN to follow it.
> 

I have to agree with Crocker on this. I don't see how one gets from advocating due diligence to ensure a smooth transition to the claim that someone is the "boss of the Internet." I can also agree with Susan that "The argument for a good, strong agreement between [the IANA functions operator] and the IETF is that it increases the chances that people will continue to find the protocol parameters registries trustworthy and useful, even if something goes off the rails ....." The stakes are actually much higher and various institutional interests far more entrenched now than they were in 1999/2000. So let's not lull ourselves to sleep with the illusion that nothing can ever happen and that certain relationships and potentialities need to be formalized.

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 13 Sep 2014 20:01:08 -0400

Eliot Lear wrote:
>> IANA functions provider, for protocol numbering, reverts to IETF; and 
>> that ICANN has no authority to continue performing that function."
>
> personal opinion, I am not convinced one way or another.  Yet.  I 
> agree with those who state that at the very least we should seek 
> review of this issue by counsel.
>
Thanks

And, as a side note - starting in 2007, 2860 has been amended pretty 
much annually.  I'm actually a bit surprised that the online version at 
http://tools.ietf.org/html/rfc2860 - doesn't include references to the 
supplemental agreements, or why those don't carry rfc numbers.

Miles Fidelman

---

From: Seun Ojedeji <[email-masked]>
Date: Sun, 14 Sep 2014 01:24:46 +0100

sent from Google nexus 4
>> If you look at the MOU[1], you will observe that IANA is referenced to
in all the action based statement. Especially in relation to item 4[2] of
the MOU and the wordings in the MOU indicates that IETF has clearly
described how IANA will handle its functions. I would expect that before
IANA can seize to exist(because that is what a merger will mean), it will
be on mutual agreement between the relevant communities (in this case, the
IETF for the protocol aspect).
> My comment was about whether a merger could happen. :-)
I think there may be some mixup, perhaps it's important to clarify what
merging in this context imply. It means the department IANA no longer
exists after the NTIA contract but ICANN still operate the functions. You
are then saying such merger will be possible without the NTIA contract.(and
done by ICANN alone)

> I read RFC 2860 [1] several times.  It looks like you and I are looking
at the MoU from different angles..
Yeah... I think you are viewing an agreement(MOU) termination as a merger
while I don't, because by then ICANN operating the IANA function will
become illegitimate. Think about it; where will ICANN get the relevant
information to create protocol parameters (for instance), unless it wants
to create a new IETF. Same goes to the RIR... so my point is, a merger is
only possible because both parties have agreed to it.

> In my opinion the real discussion is not about protocol parameter
registries.
I am not sure I get your point here... perhaps you care to elaborate.

Cheers!

---

From: Seun Ojedeji <[email-masked]>
Date: Sun, 14 Sep 2014 01:43:07 +0100

sent from Google nexus 4
kindly excuse brevity and typos.
On 13 Sep 2014 21:45, "Brian E Carpenter" <[email-masked]>
wrote:

> performs the IANA function, as long as they perform it correctly.

Well I will presume "performing it correctly"would be in accordance with
the content of the MOU, you seem to be implying this is not the case?

> IRTF (and we'd have 6 months to plan it).
Actually I have discussed this same concern of Miles sometime and the
response I got is somewhat similar to what Brian has mentioned here.
Nevertheless, I think this is working on the assumption that ICANN ofcourse
knows/has it documented that IETF has the function rights. For all it's
worth, perhaps it may be helpful to put a line that indicates that IETF
will withdraw its function upon termination of MOU.

> This is all much simpler than some people seem to think.
Yeah it seem... but it's good all possible complications are thought about
right now and corrected.

Cheers!

---

From: S Moonesamy <[email-masked]>
Date: Sat, 13 Sep 2014 18:57:40 -0700

Hi Seun,
At 17:24 13-09-2014, Seun Ojedeji wrote:
>I think there may be some mixup, perhaps it's important to clarify 
>what merging in this context imply. It means the department IANA no 
>longer exists after the NTIA contract but ICANN still operate the 
>functions. You are then saying such merger will be possible without 
>the NTIA contract.(and done by ICANN alone)

Yes.

>Yeah... I think you are viewing an agreement(MOU) termination as a 
>merger while I don't,

No.  I view the (RFC) MoU as an agreement between two organizations 
(IETF and ICANN).

>  because by then ICANN operating the IANA function will become 
> illegitimate. Think about it; where will ICANN get the relevant 
> information to create protocol parameters (for instance), unless it 
> wants to create a new IETF. Same goes to the RIR... so my point is, 
> a merger is only possible because both parties have agreed to it.

ICANN could copy the relevant information about the protocol 
parameters from the www.ietf.org. :-)

>I am not sure I get your point here... perhaps you care to elaborate.

 From BCP 25:

   "[Working group] participants should specifically note the
    requirements for disclosure of conflicts of interest"

One way to determine what people are interested in is to have each 
participant disclose his or her interests.  It is a good way to 
determine what a discussion is really about.

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Sep 2014 14:46:04 +1200

Hi Miles,

> much annually. 

It has never been amended. The subsequent statements of work etc
are supplementary; they do not change anything in the MoU.

> I'm actually a bit surprised that the online version at
> supplemental agreements, 

(a) RFC 2860 is an archival retyping of the document that I, Fred Baker
and Mike Roberts signed on March 1, 2000. As such the RFC cannot ever be
modified; it could be rendered historic(al) if the MoU was cancelled.

(b) The SoWs etc do not "update" the MoU in the sense that (say) RFC 7045
updates RFC 2460. They add to the MoU.

(c) If a new MoU or contract was signed that actually replaced any of
the terms of the old MoU, and if that new MoU was published for archival
purposes as an RFC, then it would carry an "Updates: 2860" or
"Obsoletes: 2860" header.

> or why those don't carry rfc numbers.

Apart from RFC 6220, you mean? The IAOC has a bunch of contracts etc
at http://iaoc.ietf.org/contracts.html. Why would they need to
be RFCs?

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Sep 2014 14:52:12 +1200

> A review of what exactly? Again, sorry for being dim but

We always have all ink-signature agreements reviewed by counsel
before we sign them.

But for now I haven't seen a single argument why we would *want*
to cancel an MoU that has worked well for 15 years and start
again. It's playing with fire for no reason, as far as I can see.

   Brian

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 14 Sep 2014 00:35:23 -0400

> at http://iaoc.ietf.org/contracts.html. Why would they need to

Ok... one thing that is abundantly clear is that the definition of IANA, 
the IANA functions, the IANA operator, the various roles and 
responsibilities of various organizations is spread across a rather 
large number of inter-locked documents -- some of which are clearly 
contractual in nature, others of which take other forms (RFCs), and some 
of which are "understandings" or "the way things are done." That's just 
way to complicated, cumbersome, and unclear.

IMHO, one result of this transition process should be to pull all of 
this stuff together into one contractual document, that clearly defines 
all the functions, roles, and responsibilities in one place.  (Or 
perhaps 4 clear documents, one per each IANA function that ICANN 
currently performs "on behalf of the United States Government, through a 
contract with NTIA").  [quote is from 
http://www.ntia.doc.gov/category/iana-functions]

Miles Fidelman

---

From: Seun Ojedeji <[email-masked]>
Date: Sun, 14 Sep 2014 06:24:11 +0100

sent from Google nexus 4
merger while I don't,
>
>
> No.  I view the (RFC) MoU as an agreement between two organizations (IETF
and ICANN).

Well who doesn't? We are talking about how the subject agreed upon gets
prevailed upon incase of a termination.

Just like the car analogy earlier used, if we agree that you should drive
my car to deliver goods location X but you then decide that you don't want
to be driving the car to location X as a driver but as the owner, wouldn't
you get my agreement on that?
If you proceed without my agreement and I sense what you have done is a
breech on our initial understanding, wouldn't I stop providing you goods
(since that is the reason you drive in the first place).
.... but you say....
>
>
>
> ICANN could copy the relevant information about the protocol parameters
from the www.ietf.org. :-)

Re: So you will expect me to continue generating the goods that will
service you when we no longer have an understanding.... It's a joke right :)
> One way to determine what people are interested in is to have each
participant disclose his or her interests.  It is a good way to determine
what a discussion is really about.
But this is unrelated, maybe we should start from you ;)

Cheers!

---

From: S Moonesamy <[email-masked]>
Date: Sun, 14 Sep 2014 00:45:23 -0700

Hi Seun,
>service you when we no longer have an understanding.... It's a joke right :)

No, it is not a joke.

The corporation known as ICANN is currently paying some of the cost 
for the operation of the protocol parameter registries.  The other 
part of that cost is paid through people volunteering time and 
expertise for free.

The relevant information is there for anyone on the internet to 
copy.  I could be envious and see how much money people from that 
corporation are making from that information or it could be my 
opinion that it is useful that anyone on the internet can copy it.

>But this is unrelated, maybe we should start from you ;)

Now now, are you asking whether I am well-travelled? :-)

I am one of the Root Zone (DNSSEC) Crypto Officers.  I have not and I 
still do not derive any direct or indirect material benefit from 
that.  It could be argued that visiting California (United States) is 
an indirect material benefit.  I do not mind having that 
conversation. :-)  Note that the travel is economy class.  At the 
time of this writing I have not taken any money from ICANN.  ICANN 
has invited me to several dinners.  As the United States Government 
is involved in the matter I'll disclose that I am neither a citizen 
nor do I reside in the United States.

I do not derive any direct or indirect material benefit from domain 
names or IP addresses.  My attendance (economy class) to IETF 
meetings used to be sponsored by the Internet Society.  The only 
title I have in the IETF is member of the (IETF) Applications Area Directorate.

I do not mind answering any further questions about my interests.

Regards,
S. Moonesamy

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 14 Sep 2014 14:36:03 +0200

Please see below.

Thanks and best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Brian E
> Carpenter
> Sent: dimanche, 14. septembre 2014 04:52
> To: Stephen Farrell
> Cc: [email-masked]; Miles Fidelman; Eliot Lear

And, as far as I can see, it is playing with fire for no reason to assume
that there is no need to revise the existing MoU if the NTIA IANA functions
contract no longer is in place.

The system that has worked well for 15 years includes the NTIA contract.  To
assume that no changes are needed to take into account its absence is
equivalent to asserting that the existing NTIA contract has no significance
or effect.

But, if the existing NTIA contract has no significance or effect then (1)
why did NTIA put so much effort over the years to establish it and (2) why
did NTIA call on ICANN to put into place a rather elaborate consultation
process to discuss what should be done to replace the NTIA contract?

Apparently the NTIA does not think that its existing IANA functions contract
has no significance or effect, otherwise they could just have announced that
they would not renew it.  Full stop.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 14 Sep 2014 14:39:41 +0200

Hi Dave,

When things go wrong, sometimes people say that they are going pear
shaped <https://en.wikipedia.org/wiki/Pear-shaped>.  The pear shaped
future we are discussing is one that will hopefull7 never come to pass,
but one that agreements are meant to address.   I personally appreciate
your and everyone's good-natured engagement on the topic.  One could
easily come away from a part of this discussion thinking that we're
really upset with the current arrangement when in fact nothing could be
further from the truth.  There is a tremendous amount of good faith
between the organizations.  We *all* want to do what's best for the
Internet, although at times perhaps we have different views as to what
that is.

Coming back to our exploration of the pear shaped future (psf), to me
the real questions are these: should that happen, do ICANN and the IETF
have the ability to separate such that if we go our separate ways no
interoperability problems ensue?  Do we all agree what would happen in
those circumstances?  Is there more needed?  And of course we need to
ask these questions from the IETF perspective, while recognizing that
ICANN must ask the same questions.  Now is a very good time for that
dialog to happen, and certainly far better than if our successors'
successors found themselves in a heated dispute (either on the same side
or on different sides).

For this group, the answers should be of a general nature, along the
lines of "yes we have what we need"; "no we need something extra" or "we
don't yet know and are holding discussions".  I think for the moment
we're actually in the third camp for the moment as a community.  Once we
have answers, if we find we need more, then it is for us to express to
the IAOC what we think we need, and for them to enter discussions with
ICANN to form any additional agreements.  This doesn't mean, as I stated
earlier, that we need to open 2860.  I think I typed too quickly there. 
It is also quite possible that we will need nothing.

> No single entity, not ICANN, not NTIA, not the IAB, _NO_ one, has the ability to define the “authority to continue performing that function”.

That much I *strongly* agree with, but that doesn't mean that chaos
couldn't ensue in the pair shaped future, especially in a transition. 
We all have a responsibility to see that interoperability is maintained
and that implementors are well served.  Things we might want to avoid
would be conflicting assignments, or out of date tables, etc.

Eliot

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 14 Sep 2014 14:43:55 +0200

I agree with the point that Miles makes below, which point has also been
made by others.

It is reasonable to interpret the existing ICANN Bylaws to the effect that
the ICANN Board has the fiduciary duty to perform the IANA function and to
give final approval (ratification) to certain policies, in particular the
policies regarding IP addresses. And this quite indepenendly of whether or
not ICANN has any MoUs in place with IETF or anybody else.

For sure IETF (and the RIRs) can cancel their agreements with ICANN
regarding the IANA function.  But this does not place any obligation on
ICANN to cease providing the IANA function.

So, in a worst case scenario, IETF (or whoever) would set up a new IANA
function, while ICANN would continue with its own IANA function.

As noted, ISPs etc. are free to use whatever names/numbers/addresses they
wish, no matter who publishes them.  But, in practice, ISPs etc. would have
to choose between the values published by ICANN and those published by the
new, competing, "IANA".

As Miles says below, this could result in confusion and disruption, at least
for some time.

Why not avoid such a possibility by transposing to the ICANN Bylaws and to
IETF/ICANN MoU relevant parts of the existing IANA functions contract?

In my view, that's what a correct application of the precautionary principle
(do no harm) would call for.

Best,
Richard

> Sent: samedi, 13. septembre 2014 19:31
> Cc: [email-masked]

Miles Fidelman

---

From: Seth Johnson <[email-masked]>
Date: Sun, 14 Sep 2014 06:47:39 -0600

Yep.  People are just not getting the fact that we're handing things
off to the international arena, and the stewardship context we've
enjoyed will no longer work there to continue to support the type of
consensus pow-wow type of process we've relied on.

I think you definitely get the ramifications of handing off to the
international arena, though from a different set of priorities from
those that are traditional in this community.

People just think they can expect business as usual, and it's true
that it's hard to see just why the NTIA connection makes that
difference.  They just don't see the new dynamics that arise.

Seth

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 14 Sep 2014 14:54:18 +0200

Please see below.

Thanks and best,
Richard

> Sent: samedi, 13. septembre 2014 22:46
> To: [email-masked]

I think that many agree that it is simple, but there is some disagreement
regarding what it will look like, that is, the actual shape of "simple".

As I understand it, your view, and that of others, is that there is no issue
worth worrying about now.  If things go wrong, we can worry about it when
they do go wrong.

My view, and that of others, is that contracts are like insurance policies:
they are drawn up in advance in order (1) to make it hard for things to go
wrong and (2) to lay out a plan for how to cope with things going wrong.

The crux of the difference in views is whether, absent the existing NTIA
IANA functions contract, the existing contractual/MoU/etc. framework is
adequate.  Some think yes, others think no.

So it is simple in principle, but not in detail, because we differ regarding
the interpretation of the existing contracts/MOUs/etc. and regarding the
significance and effects of the existing NTIA IANA functions contract.

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 14 Sep 2014 15:00:20 +0200

Please see below.

Thanks and best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Stephen
> Farrell
> Sent: dimanche, 14. septembre 2014 00:57
> To: Eliot Lear; Miles Fidelman
> Cc: [email-masked]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>

Sure.  But, in practice, at present most everybody relies on the information
published by the existing IANA function.

> angels on the non-existent heads of non-existent pins.

The existing NTIA IANA functions contract is, obviously, not non-existent.
The proposal to let that contract lapse is also not non-existent.

Some apparently believe that that existing NTIA contract is of no
significance.  Others disagree.  Those who take the view that the existing
NTIA contract is significant logically argue that some of its provisions
should be incorporated into other instruments, such as the ICANN Bylaws or
the ICANN/IETF MoU.

So that's not arguing about angels, nor about whether or not angels exist.

> A review of what exactly? Again, sorry for being dim but

For a start, a review of whether the current legal/contractual framework
(ICANN Bylaws, ICANN/IETF MoU, etc.) fully covers all the provisions of the
existing NTIA IANA functions contract.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUFMu1AAoJEC88hzaAX42i0igH/1bvFHmGfvqnulNFjI59e9vK
> pdKTB7YKoZCI13YJw7TPsuSQHRUmKmhhItlYobVHMae6L6KRNwnGbPJ2DnH9ynqE
> MMBtRvMDZ5yMjQ9B2050Y7t9QMZXDxVzhNwlummKySeqsB0rbEpMeePnmgaEoKO4
> OCz+hRV2Lx+VxSPxpheVIMx559+lLUWkAQfN1im+lHaxwAd8OUf5br1haVlE/kOR
> QfPOUqZ1ZK/dgKdMwiD+ph0ruUU80lFMCtIKb+6kinboKylAAxzCO52Rg8J620Tk
> ef5T6MUitIBi4yIr5d5kWNw1kEYwtBh+mMbN0OKKu5KZk5RccKam+tN4pjmZu4g=
> =/dGZ
> -----END PGP SIGNATURE-----
>

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 14 Sep 2014 09:27:00 -0400

> significance and effects of the existing NTIA IANA functions contract.

Or... since we are, after all an engineering community..... well-crafted 
contracts are the equivalent of error checking code, and designing to 
handle edge cases.

Miles

---

From: David Conrad <[email-masked]>
Date: Sun, 14 Sep 2014 08:43:33 -0700

Eliot,

On Sep 14, 2014, at 5:39 AM, Eliot Lear <[email-masked]> wrote:
> do ICANN and the IETF have the ability to separate such that if we go our separate ways no interoperability problems ensue? 

What sort of interoperability problems are you imagining?

> Do we all agree what would happen in those circumstances? 

In the case of the protocol parameters, the only question I’ve seen outstanding are related to the ownership of “iana.org” and potentially the IPR associated with performing that function.  My understanding of the latter is that the Chairman of ICANN’s board has publicly stated ICANN will sign whatever the IETF proposes to disambiguate the status of the IPR.  I’ve not heard anything about “iana.org” one way or another.

> Is there more needed? 

Clarification of the ownership status of “iana.org” and taking up Dr. Crocker on his offer would probably be a good idea.

I gather Dave Crocker believes we’d be irresponsible and unprofessional if we didn’t have a transition plan should the existing MoU be terminated.

> Things we might want to avoid would be conflicting assignments, or out of date tables, etc.

This is where I get confused.

Suppose the IETF and ICANN part ways badly. The IETF decides Bill’s Bait and Sushi Shop is now the IANA Protocol Parameter Function Operator and goes on to create/modify/delete  protocol parameters as they’ve done since the early ‘70s with BBSS modifying text files that represent the registries. ICANN decides to refuse to erase the text files they have on their systems that represent the registries but also refuses to update those files. For sake of argument, assume iana.org is redelegated to BBSS. 

Who would even notice that ICANN had refused to update the text files? 

For a concrete example, how many people notice or even care (other than to point and laugh) that 16/8 remains labeled “Digital Equipment Corporation” in the IANA IPv4 registry?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Sun, 14 Sep 2014 08:48:57 -0700

Richard,

> function, while ICANN would continue with its own IANA function.

And tomorrow, _you_ could set up your own IANA function. 

The impact of that would be what?

As far as I am aware, the protocol parameters created/modified by the IETF community are public information.  Out of curiosity, how exactly would you stop _anyone_ from setting up “an IANA function” that publishes that public information?

Regards,
-drc

---

From: Seun Ojedeji <[email-masked]>
Date: Sun, 14 Sep 2014 18:10:26 +0100

sent from Google nexus 4
kindly excuse brevity and typos.
On 14 Sep 2014 08:55, "S Moonesamy" <[email-masked]> wrote:
>.
>
> The corporation known as ICANN is currently paying some of the cost for
the operation of the protocol parameter registries.  The other part of that
cost is paid through people volunteering time and expertise for free.
But this is not my point SM...

> The relevant information is there for anyone on the internet to copy.  I
could be envious and see how much money people from that corporation are
making from that information or it could be my opinion that it is useful
that anyone on the internet can copy it.
I think we may be going around about this. My point is can ICANN
independently and successfully pull off the entire role of servicing the
IANA and at the same time implementing (without support from the 3 main
communities). It's not just about copying and pasting those records, who
does the updates and in the case of the RIR, who does the regional resource
demand coordination.

> I am one of the Root Zone (DNSSEC) Crypto Officers.  I have not and I
still do not derive any direct or indirect material benefit from that.  It
could be argued that visiting California (United States) is an indirect
material benefit.  I do not mind having that conversation. :-)  Note that
the travel is economy class.  At the time of this writing I have not taken
any money from ICANN.  ICANN has invited me to several dinners.  As the
United States Government is involved in the matter I'll disclose that I am
neither a citizen nor do I reside in the United States.
>
> I do not derive any direct or indirect material benefit from domain names
or IP addresses.  My attendance (economy class) to IETF meetings used to be
sponsored by the Internet Society.  The only title I have in the IETF is
member of the (IETF) Applications Area Directorate.
> I do not mind answering any further questions about my interests.
The things you mentioned above about your interest IMO does not add to the
current subject of discussion. I am not sure i understand why you are
declaring your travel experience. You started off with this interest thing
and I ask you to mention yours, hoping that it will help understand what
aspect of this transition is of interest to you.
Unless you think some on this list are participating in the interest of
getting free ticket which perhaps should be the least of the issue in this
process.

Cheers!

---

From: Eliot Lear <[email-masked]>
Date: Sun, 14 Sep 2014 19:23:25 +0200

Hi Dave,

Prefacing this again to say that these are all rather unlikely scenarios.

> Who would even notice that ICANN had refused to update the text files? 

I suppose some of this is in the name.  When you Google "how to get a
protocol parameter assignment" the top hit is off of www.iana.org.  If
others went to the IETF and we assigned something, and then our evil
twin Skippy assigned something else for a given value, we would have a
conflict.  Would it matter?  Maybe not immediately.  Would it even be
detectable between implementations?  who knows?  Would we spot the
problem?  Probably, but perhaps not after something escaped into the
field.  We've had something like this problem before with just ONE
parameters registry, and so it clearly can happen with two.

Eliot

---

From: S Moonesamy <[email-masked]>
Date: Sun, 14 Sep 2014 10:45:26 -0700

Hi Seun,
At 10:10 14-09-2014, Seun Ojedeji wrote:
>The things you mentioned above about your interest IMO does not add 
>to the current subject of discussion. I am not sure i understand why 
>you are declaring your travel experience. You started off with this 
>interest thing and I ask you to mention yours, hoping that it will 
>help understand what aspect of this transition is of interest to you.
>Unless you think some on this list are participating in the interest 
>of getting free ticket which perhaps should be the least of the 
>issue in this process.

Quoting a message at 
https://lists.afrinic.net/pipermail/africann/2014-March/008730.html

   "While I know some people only attend conferences for travel
    experience (which does not only happen to Africans"

Interest is usually money related.  There may be a belief that I may 
be supporting or objecting to something in exchange for favors, e.g. 
travel experience.  I usually disclose everything I can think of to 
avoid any perception of conflict of interest.  As this has been sent 
to a public mailing list anyone can assess whether I am making 
arguments because I have received a free ticket.  I call it transparency.

Regards,
S. Moonesamy

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 14 Sep 2014 14:25:33 -0400

> I gather Dave Crocker believes we’d be irresponsible and unprofessional if we didn’t have a transition plan should the existing MoU be terminated.

Not just Dave.
> For a concrete example, how many people notice or even care (other than to point and laugh) that 16/8 remains labeled “Digital Equipment Corporation” in the IANA IPv4 registry?

Well... the example of forking in Linux distributions comes to mind.  
For a while, Ubuntu users could use Debian repos pretty cleanly, but 
eventually the packaging scheme, details of specific packages, and so 
forth, started to diverge.

In our world, let's say that Microsoft starts to ship product based on 
an IETF sanctioned registry, while Apple ships product that relies on 
ICANN - and things diverge?

Better to head that kind of thing off early.

Miles Fidelman

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 14 Sep 2014 22:01:45 +0200

Please see below.

Thanks and best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of David
> Conrad
> Sent: dimanche, 14. septembre 2014 17:49
> To: [email-masked]
> Cc: [email-masked]

Obviously nothing, because nobody would pay attention to *my* IANA function,
and rightly so.

But that is not relevant to the question of who would pay attention to
ICANN's continuation of the IANA function after the IETF decides to create
its own, because, at present, people accept that ICANN provides the IANA
function, and thus they would have a natural tendency to continue accepting
the ICANN IANA function.

It may be obvious to people on this list that a new IETF-sanctioned IANA
function should be preferred to the (at that point lapsed) ICANN IANA
function, but that is not necessarily obvious to people not on this list.

And please recall that, as the NTIA has stated, the transition that we are
discussing is to the global multi-stakeholder community, which includes many
people not on this list.

>
> As far as I am aware, the protocol parameters created/modified by
> the IETF community are public information.  Out of curiosity, how
> exactly would you stop _anyone_ from setting up “an IANA
> function” that publishes that public information?

If ICANN agreed contractually that it would not publish that information if
IETF requested it not to, then ICANN would be prevented from setting up an
IANA function that competed with IETF.

---

From: David Conrad <[email-masked]>
Date: Sun, 14 Sep 2014 13:03:05 -0700

On Sep 14, 2014, at 10:23 AM, Eliot Lear <[email-masked]> wrote:
> I suppose some of this is in the name.  

“..., assume iana.org is redelegated to BBSS."

If you do not make this assumption, then I would agree there is a non-trivial potential for confusion simply due to all the existing references to “iana.org”, hence my statement that it’d probably good to resolve (pun intended) the ownership of that particular domain name.

> If
> conflict. 

What is stopping our evil twin Skippy from assigning a different value today?

Answer: absolutely nothing and in fact it happens (see CARP or port 465).

Where I’m getting confused is NOT about the need to ensure there is coordination of registry assignments, that’s obvious. It’s about assertions of the existence of a singular top-down “authority” outside of the IETF community, e.g., NTIA or ICANN, that can dictate who can perform that coordination/publication function.

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 15 Sep 2014 08:26:48 +1200

On 14/09/2014 16:35, Miles Fidelman wrote:
...
> http://www.ntia.doc.gov/category/iana-functions]

The IETF is only concerned with the protocol parameters registries
where the documents are perfectly clear already. It isn't our business
here what happens to other areas of ICANN activities.

On 15/09/2014 00:36, Richard Hill wrote:
...
> equivalent to asserting that the existing NTIA contract has no significance

That is very precisely what I assert as far as the protocol parameters
registries, including the special purpose address and domain name
registries, are concerned. That's what's in scope here.

   Brian

---

From: David Conrad <[email-masked]>
Date: Sun, 14 Sep 2014 13:58:56 -0700

Richard,

> function, but that is not necessarily obvious to people not on this list.

You are assuming a non-infintesimal number of people not on this list (a) actually care who is providing the IANA protocol parameter coordination/publication function and (b) are even aware that ICANN is providing that service.

I’m quite doubtful either of those assumptions hold.

However, let’s say they do. In a worst case scenario, there would be a divergence in the contents of the IETF-sanctioned protocol parameter function operator’s registries and the ones maintained by ICANN (like, oh say, 16/8 in the ICANN IPv4 registry vs. 16/8 at ARIN and look at the nightmares that has caused, but I digress). Protocol and software developers who foolishly continue to look at the ICANN-based registries (and who don’t read RFCs, attend IETFs, or pay attention to IETF mailing lists) would develop software and hardware with the wrong values. This would likely make them unhappy when they go to ship said software and hardware and find that it didn’t interoperate with other vendors’ implementation of the same protocols. I would imagine those software and hardware developers would then go to the IETF and (undoubtedly) politely ask “WTF?” and the IETF would probably say “don’t blame us, blame ICANN”, at which point (given ICANN is a US-based organization), they’d rev up their lawyers and a normal (for the US) pattern would be followed in which the lawyers alone win yet again.

And ICANN would intentionally enrage folks who bother to look to them for information for a service that provides only costs, no revenue, and no recognition outside of a tiny (relatively speaking) community of software and hardware developers because...?

Regards,
-drc

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 Sep 2014 21:59:00 +0100

> registries, are concerned. That's what's in scope here.

I fully agree with Brian. In 19 years being involved in the IETF
I recall no (that is, zero) examples of where the NTIA contract
had any impact at all on protocol parameter registries. But TBH,
I've mostly not cared at all about any of that stuff;-)

Anyway, it'd be helpful if those asserting the opposite provided
some concrete examples based on their experience of doing work in
the IETF.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 14 Sep 2014 22:08:51 +0100

> existing NTIA IANA functions contract.

"For a start" !?

What you say you want sounds to me like lawyer-years of utterly
pointless effort that would produce nothing useful and would
likely constitute a DoS on this WG, if not on the ICG process
as a whole.

A general review of the ICANN bylaws also seems to me to be
out of scope of this list and of this WG.

This WG should fulfill its charter and at whatever is the right
point of completion (which is not the start) maybe think about
whether or not there is a need to ask specific questions of
counsel.

S.

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 14 Sep 2014 18:44:50 -0400

> whether or not there is a need to ask specific questions of

And herein lies the difference between those of us who view the 
transition as a contractual matter - requiring careful attention to the 
paperwork, and those who consider the transition an operational matter, 
with a "if it ain't broke, don't fix it" point of view.

IMHO, it's the contractual environment that is about to change - this 
whole thing should START with review by counsel.

Miles Fidelman

---

From: S Moonesamy <[email-masked]>
Date: Sun, 14 Sep 2014 16:09:43 -0700

Dear Mr Hill,
>discussing is to the global multi-stakeholder community, which includes many

I'll use an example.  If 
http://www.iana.org/assignments/adsp-parameters/adsp-parameters.xhtml 
disappears it won't cause significant problems.  If that web page 
diverges from another web page with similar information it won't 
cause significant problems.  It seems that people are looking at the 
information on that web page as they would for domain name and IP 
address information.  What would happen on a global scale if there 
was conflicting information?  I am asking the question to try and 
understand the seriousness of a future problem might be.

Regards,
S. Moonesamy

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Sep 2014 01:13:54 +0100

> with a "if it ain't broke, don't fix it" point of view.

Careful attention to the paperwork is exactly what IETF WGs do and
is therefore not a useful distinction.

It (IETF handling of protocol parameter registries) is not broken.
And we (the IETF) do not need to fix non-broken things.

Personally, I'm coming more and more around to the opinion that a
bunch of the arguments being offered on this list have nothing much
to do with the WG charter and seem more related to furthering views
of, or preferences for, how the Internet should really be run. (And
yes, that would be a fine exercise in futility;-)

S.

---

From: John Curran <[email-masked]>
Date: Sun, 14 Sep 2014 22:31:51 -0400

> And we (the IETF) do not need to fix non-broken things.

Agreed for the general case (don't fix what is not broken), but the 
specific assertion "IETF handling of protocol parameter registries 
is not broken" may only be true today, rather than in a world post-NTIA 
IANA Function contract. Absent NTIA contract, additional documentation 
or agreements may be required, and the identification (but not production)
of such documentation is specifically in scope of this WG.

In order to facilitate assessment of the situation, it might be useful
for the working group to consider several potential "use cases" that
might occur at a future time after NTIA's IANA stewardship transition. 
Reviewing how the existing documentation would handle each scenario 
might prove helpful in the planning needed for the transition (even
if the issues identified turn out to not be properly part of the ICG 
response but instead items to be referred to the IAB or IAOC.)

There is one particular Post NTIA scenario whose review in detail by
the working group may really help explore the adequacy of the present 
IANA documentation - 

 How would the IETF (presumably due to chronic performance issues) exit 
 from the ICANN MOU (RFC 2860) and contract with a different party for 
 administration of the IANA registries?  In such an event, would that
 new IANA operator publish all of the IANA registries, all but the DNS 
 root zone, or all but the DNS root zone & IP address space registries?
 Would the IETF accept DNS root zone and IP address space registries
 being published by a different "IANA operator" than the other protocol
 parameter registries?  Presuming that a single IANA operator is desired,
 and the communities still support ICANN as the policy authority for the 
 DNS registries and the RIR system as the policy authority for number 
 spaces, how would those policy development bodies interact with a new 
 IETF-contracted IANA operator, and would that be covered in the IETF's 
 new IANA operator contract, or require ICANN and/or the RIRs to contract
 with the new IANA operator independent of the IETF's arrangements?

I believe that walking through such a scenario might help the working group 
get closer to a common understanding on the adequacy of the present IANA 
documentation in a post-NTIA world.  This also may be a situation in which 
there are multiple approaches that are all quite functional, and the real 
challenge is getting alignment among the parties in the Internet identifier 
ecosystem towards a single framework for these important services...

FYI,
/John

Disclaimer: my views alone.

---

From: Seth Johnson <[email-masked]>
Date: Sun, 14 Sep 2014 22:22:42 -0600

While John's scenarios may be helpful, I would say Stephen's
formulation (stemming from Miles's suggestion) is not applicable.  The
WG's task is to "break something correctly" or "change things in a way
that works well."  And there are some built in issues about what would
be correct or would work well in the task of removing the NTIA,
handing over the IANA to the international arena and multistakeholder
processes, and doing so in a way that's non-government-led and
non-inter-governmental.  Including what all we want to have done to
support the change so it works well, and whether we actually can keep
from breaking things and what we want to do about that.

I think Stephen's concern about issues being really about changing how
we do things on the Internet is both sage and realistic, especially
given the fact that there's an Information Society project in full
swing surrounding the NTIA's IANA move that hopes to be all about
that.  You're going to be in that context and it will affect things
even if you make no references to it.

But I also think we should think carefully about whether things will
in fact be business as usual in/after the transition, or whether
things will break and need rectification as a consequence of the task
the NTIA has set, or whether things are being changed and need to be
changed in a way that works well, including in ways that may go beyond
business as usual, whether those elements are necessary to keep things
working as usual or simply ideas that people find desirable.

Seth

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 15 Sep 2014 09:18:16 +0200

Please see below.

Thanks and best,
Richard

> Sent: dimanche, 14. septembre 2014 22:59
> To: [email-masked]
> Cc: [email-masked]
> You are assuming a non-infintesimal number of people not on this
> list (a) actually care who is providing the IANA protocol
> parameter coordination/publication function and (b) are even
> aware that ICANN is providing that service.
>

I believe that you are correct regarding the specific details of protocol
parameters: few people know what they are and why they are important.

But many people care about the IANA function in general, even if they don't
understand the specifics of protocol parameters.

What puzzles me about these discussions is that, as far as I can tell, there
is no opposition to continuing the current operation of the protocol
parameters function.  But there seem to be three different currents of
thought regarding how best to do that:

(1) What happens with respect to the existing NTIA IANA functions contract
is irrelevant with respect to protocol parameters.

(2) The existing ICANN/IETF MoU and its Supplements provides adequate formal
documentation for the current setup, even in the absence of the NTIA IANA
functions contract.

(3) It would be better to make some changes to the ICANN/IETF MoU and to the
ICANN Bylaws in order to specify more clearly the current setup in those
documents and to plan for possible future contingencies.

What you say below seems to me like a good description, so I SNIP it here.

SNIP

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 15 Sep 2014 09:19:53 +0200

I fully agree with what John says below.

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of John
> Curran
> Sent: lundi, 15. septembre 2014 04:32
> To: Stephen Farrell
> Cc: [email-masked]
> Subject: [Ianaplan] "The mechanisms required to address the removal of
> the overarching NTIA contract may require additional documentation or
> agreements."
>
>

---

From: Seun Ojedeji <[email-masked]>
Date: Mon, 15 Sep 2014 08:42:49 +0100

+1 to the particular post-NTIA questions posted by John. Its a summary of
what many has been saying on this list.

Cheers!

sent from Google nexus 4

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 15 Sep 2014 08:26:23 -0400

+1 as well
Seun Ojedeji wrote:
>
> +1 to the particular post-NTIA questions posted by John. Its a summary 
> of what many has been saying on this list.
>
> Cheers!
>
> sent from Google nexus 4
> On 15 Sep 2014 03:32, "John Curran" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Sep 14, 2014, at 8:13 PM, Stephen Farrell
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > ...

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 15 Sep 2014 13:48:36 +0000

> However, let's say they do. In a worst case scenario, there would be a
> divergence in the contents of the IETF-sanctioned protocol parameter
> function operator's registries and the ones maintained by ICANN (like, oh
> say, 16/8 in the ICANN IPv4 registry vs. 16/8 at ARIN and look at the
> nightmares that has caused, but I digress). Protocol and software developers
> who foolishly continue to look at the ICANN-based registries (and who don't
> read RFCs, attend IETFs, or pay attention to IETF mailing lists) would develop
> software and hardware with the wrong values. This would likely make them
> unhappy when they go to ship said software and hardware and find that it
> didn't interoperate with other vendors' implementation of the same
> protocols. I would imagine those software and hardware developers would
> then go to the IETF and (undoubtedly) politely ask "WTF?" and the IETF
> would probably say "don't blame us, blame ICANN", at which point (given
> ICANN is a US-based organization), they'd rev up their lawyers and a normal
> (for the US) pattern would be followed in which the lawyers alone win yet
> again.

However marginal this case may be, Dave, you haven't given us a single reason why the ICANN-IETF relationship should NOT include a few simple, clarifying requirements that would avoid it. In other words, the problems that might be caused by avoiding this issue are real, if unlikely, and the costs of forestalling those problems are tiny. Tell me again why you are resisting this?

---

From: David Conrad <[email-masked]>
Date: Mon, 15 Sep 2014 07:39:46 -0700

Milton,

> However marginal this case may be, Dave, you haven't given us a single reason why the ICANN-IETF relationship should NOT include a few simple, clarifying requirements that would avoid it. In other…

Actually, I believe I’ve said on a couple of occasions now that it would be good to get clarity on a number of issues (disposition of “iana.org”, IPR, potentially also transition requirements are examples).

Where I get a bit of heartburn is the assertion that ICANN performs the IANA protocol parameter function _because_ of the top-down assertion of the NTIA contract and that if that contract goes away, ICANN will <insert evil deed here, exactly what I’ve been unable to determine>.  When I ran IANA (and I have no reason to believe this has changed), the NTIA contract was simply not a factor in anything having to do with the operation of the protocol parameter function. While there were periods in which ICANN’s performance of that function were sub-optimal (due in part to resource limitations and the lack of SLAs), that sub-optimality was dealt with _with no recourse to the IANA functions contract, period._ ICANN and the IETF community worked out solutions and came up with SLAs that ensured the sub-optimality would not return. NTIA had _zero_ involvement in that process (I know, I was there).

I personally don’t see the need to bind up clarifying things with the IANA stewardship transition (and see a number of reasons not to). ICANN and the IETF have, since 2007, created supplemental agreements to the MoU. If people feel there is a need to clarify things, I see no reason to not address those issues in the next iteration of the supplemental (after all, further delay could be seen as being “irresponsible and unprofessional”).

However, to be honest, what I find most fascinating about this discussion is the complete abandonment of the “bottom up, (rough) consensus” model by some folks here. I guess Dave Clark’s famous quote “We don’t believe in Kings” must’ve left out "except when we do."

Regards,
-drc

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 15 Sep 2014 08:20:35 -0700

> root zone, or all but the DNS root zone & IP address space registries?

[BA] this is a good scenario to understand. Since the NTIA-ICANN contract assumes that all functions are performed by the same contractor, I believe that the succession plan assumes that 
all functions move together to a new operator. Having multiple successors does complicate the situation.

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 15 Sep 2014 17:21:24 +0200

Please see below.

Thanks and best,
Richard

> Sent: lundi, 15. septembre 2014 16:40
> To: Milton L Mueller
> Cc: [email-masked]
>> However marginal this case may be, Dave, you haven't given us a
>>single reason why the ICANN-IETF relationship should NOT include
>>a few simple, clarifying requirements that would avoid it. In
>> other words, the problems that might be caused by avoiding this
>> issue are real, if unlikely, and the costs of forestalling those
>> problems are tiny. Tell me again why you are resisting this?
>
> Actually, I believe I’ve said on a couple of occasions now that
> it would be good to get clarity on a number of issues
> (disposition of “iana.org”, IPR, potentially also transition
> requirements are examples).
>
> Where I get a bit of heartburn is the assertion that ICANN
> performs the IANA protocol parameter function _because_ of the
> top-down assertion of the NTIA contract and that if that contract
> goes away, ICANN will <insert evil deed here, exactly what I’ve
> been unable to determine>.

I don't recall anybody saying that.  What I recall being said was that,
absent the NTIA contract, the ICANN Board might, for whatever reason
(including possible GAC advice) decide to do something not consistent with
IETF policies.  I think we all agree that that is very unlikely, in
particular regarding protocol parameters, but why not make it clear in the
contractual language that ICANN should not do that?

Conversely, such contractual language would insulate the ICANN Board from
pressures, for example from GAC, and might also help in a situation where a
court orders ICANN to do something on the basis of some national law.

SNIP

>
> I personally don’t see the need to bind up clarifying things with
> the IANA stewardship transition (and see a number of reasons not
> to).

Can you specify the reasons not to?

SNIP

>
> However, to be honest, what I find most fascinating about this
> discussion is the complete abandonment of the “bottom up, (rough)
> consensus” model by some folks here. I guess Dave Clark’s famous
> quote “We don’t believe in Kings” must’ve left out "except when we do."

I'm not sure what you are referring to here.  I haven't seen any indication
that the IETF process is not being followed in these discussions.

And I don't suppose that you are referring to posts by various people in
senior and/or leadership positions.

Perhaps you are referring to those who wish to have a clear formal
framework, but I don't see how that is inconsistent with either the bottom
up, rough consensus model, nor with an allergy to kings (and governments).

---

From: Seun Ojedeji <[email-masked]>
Date: Mon, 15 Sep 2014 16:31:15 +0100

On Mon, Sep 15, 2014 at 4:21 PM, Richard Hill <[email-masked]> wrote:

> IETF policies.

Hmm...just incase i am missing something, havn't you just repeated what you
don't re-call anyone saying.(ofcourse using different words may be the
difference)

Regards

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 15 Sep 2014 15:37:54 +0000

> From: David Conrad [mailto:[email-masked]]
> Actually, I believe I've said on a couple of occasions now that it would be
> good to get clarity on a number of issues (disposition of "iana.org", IPR,
> potentially also transition requirements are examples).

OK, then we agree. 

> Where I get a bit of heartburn is the assertion that ICANN performs the IANA
> protocol parameter function _because_ of the top-down assertion of the
> NTIA contract and that if that contract goes away, ICANN will <insert evil
> deed here, exactly what I've been unable to determine>.  When I ran IANA

That's an ideological argument (on both sides) that in my opinion should not be allowed to get in the way of the more straightforward, nitty gritty work of the transition proposal. My concern is simply that the IANA functions operator be consistently viewed not as "ICANN" but as a contracted-for, separable function performed for the IETF by whoever (including ICANN) they contract with to do it. 

What gives me heartburn is people who say we don't need to think about this because they think ICANN people are nice

--MM

---

From: John Curran <[email-masked]>
Date: Mon, 15 Sep 2014 11:56:36 -0400

On Sep 15, 2014, at 11:20 AM, Bernard Aboba <[email-masked]> wrote:

> [BA] this is a good scenario to understand. Since the NTIA-ICANN contract assumes that all functions are performed by the same contractor, I believe that the succession plan assumes that all functions move together to a new operator. Having multiple successors does complicate the situation.

I honestly do not know, but believe that the IETF community discussing its 
assumptions in this regard would be worthwhile, and might aid somewhat in 
the IANA Stewardship transition planning activities.

/John

---

From: David Conrad <[email-masked]>
Date: Mon, 15 Sep 2014 09:36:30 -0700

Richard,

On Sep 15, 2014, at 8:21 AM, Richard Hill <[email-masked]> wrote:
> What I recall being said was that,

If people believe the ability to terminate the ICANN-IETF MOU is not sufficiently clear (seems clear to me but what do I know?), why not put additional clarification in the next supplemental?

> court orders ICANN to do something on the basis of some national law.

Doubtful. I suspect (hope) no ICANN lawyer would think to say, “No, your honor, I can’t do what you demand because ICANN has contractual language with the IETF."

> Can you specify the reasons not to?

Off the top of my head:

a) timing - if there are issues, why wait? Some might even say not dealing with those issues would be “irresponsible and unprofessional”.
b) the IETF community has worked out a process over a number of years to address the relationship between itself and ICANN, why deviate from that process, particularly in a politically tinged environment?
c) given most involved in the transition have no interest in the protocol parameter side of things, the politics surrounding the transition are unlikely to have a positive effect on the administration of the MOU and its supplements

Why should the clarifications be bound to the transition?  Don’t the folks involved in the transition have enough to do?

Regards,
-drc

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 15 Sep 2014 18:49:29 +0200

Please see below, regarding only one point.

Thanks and best,
Richard

> Sent: lundi, 15. septembre 2014 18:37
> To: [email-masked]
> Cc: [email-masked]

SNIP

> Doubtful. I suspect (hope) no ICANN lawyer would think to say,
> “No, your honor, I can’t do what you demand because ICANN has
> contractual language with the IETF."

Why not?  Bringing additional parties into litigation is legitimate.  More
importantly, IETF is not just anybody, it is a well recognized standards
body.  I expect that most judges would respect a committment to abide by
recognized standards.

Finally, if my memory is correct, ICANN's lawyers have put forward exactly
this type of argument, but referring to the contract with NTIA, in
connection with the currently open case where some people want ICANN to
transfer some things related to Iran.

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 15 Sep 2014 19:00:10 +0000

> From: Ianaplan [mailto:[email-masked]] On Behalf Of John Curran
 
A very important issue. The IANA transition problem was broken down into 3 parts, largely at the urging of the IAB/IETF. 
As a result, there is NO assumption whatsoever on the part of the ICG or the NTIA that the IANA functions for all 3 operational communities will be integrated into the same entity. If the 3 communities (names, numbers, protocols) come up with widely divergent ideas about the optimal arrangements, they could be split, though we will be on the lookout for any incompatibilities or conflicts such arrangements might cause.

Indeed, after seeing David's and others' convincing arguments about how "anyone can start a protocol registry" and that there are minimal risks of having ICANN carry on and publish a registry even if the IETF doesn't use it, I see no reason at all why management of the root zone for names and the IETF protocol registry need to be combined. The requirements for both seem to be worlds apart.

Milton L Mueller

---

From: Russ Housley <[email-masked]>
Date: Mon, 15 Sep 2014 15:23:24 -0400

On Sep 15, 2014, at 10:39 AM, David Conrad wrote:

> When I ran IANA (and I have no reason to believe this has changed), the NTIA contract was simply not a factor in anything having to do with the operation of the protocol parameter function. While there were periods in which ICANN’s performance of that function were sub-optimal (due in part to resource limitations and the lack of SLAs), that sub-optimality was dealt with _with no recourse to the IANA functions contract, period._ ICANN and the IETF community worked out solutions and came up with SLAs that ensured the sub-optimality would not return. NTIA had _zero_ involvement in that process (I know, I was there).

I was there too, and David is correct.  The discussion was handled in the context of the MoU.  No one raised the IANA Functions contract.  Further, the establishment of SLAs since that time has avoided a repeat of these issues.

Russ

---

From: John Curran <[email-masked]>
Date: Mon, 15 Sep 2014 16:15:43 -0400

> Indeed, after seeing David's and others' convincing arguments about how "anyone can start a protocol registry" and that there are minimal risks of having ICANN carry on and publish a registry even…

Hmm.

For a moment, let's hypothecate that the IETF develops a new Internet-related 
protocol ("NewIP") for some important purposes (e.g. enabling home automation 
devices, smart inter-car communication, inter-drone collision avoidance, all 
of the above, whatever...) 

This new protocol (NewIP) has its own unique IDs that must be made widely 
available for the protocol to be adopted and thus successful, and it is also 
anticipated that these will be issued via a variety of schemes, e.g. to new
equipment makers, to hobbyists who request blocks, to governments who wish 
to coordinate things in their country, etc.

After the IETF defines the technical requirements for the NewIP identifiers
(NewID registry space), it's likely to see a wide variety of proposals for 
each of these very worthy issuance schemes, as well countervailing concerns 
expressed about the excessive waste inherent in some of them, directory and 
privacy related concerns due to the potential for personally-identifiable 
usage of these NewID identifiers, plus law enforcement queries about tracking 
of these NewID's and availability of related information under appropriate 
due process, etc.

I'll observe that these are not questions that are associated with protocol 
response codes, error subtype fields, command flags, or the vast majority of 
the IETF IANA registries; in fact, they are not even really questions that
get answered by "getting the right expert" to make the call; they are more
complex questions that involve balancing multiple possible policy approaches 
to provide a fair, impartial, and technically sound identifier administration
on a global basis. Now I imagine that IETF can spin up an entire Area dedicated 
to such discussions; that would certainly change the composition of attendees
at future IETF meetings... ;-)

Alternatively, the IETF can always delegate the entire problem away by handing 
it off to an appropriate industry association, but that doesn't necessarily 
mean that the resulting administration will be receptive to input from anyone,
nor that the trade association will have open and transparent policy development
practices, or that it actually will follow those practices, etc.

Given the IETF's need for successful Internet identifier administration for
these new to-be-widely-used identifiers, making them almost "public" in nature
(particularly when compared to nearly all of the other IETF protocol identifiers),
it might be a very wise idea to have some other organization provide for overall 
coordination of the necessary registry policy development development efforts, 
including requiring adherence to reasonably open, transparent, and inclusive 
policy development processes, periodic (every 3 to 5 year) reviews of actual 
performance against such requirements, an ongoing global outreach and engagement 
process including fellowships (particularly for regions of the globe that might 
not otherwise have the means to participate), an active liaison process with all 
of the various governments that are interested in Internet identifier issues, 
and perhaps even ratification of newly developed global Internet identifier 
policies for these more general-purpose identifier spaces, so that global 
registry policies are not immediately adopted if it is clear that there were 
"significant viewpoints not adequately considered" during their development.  

Once the IETF decides what responsibilities it should have to the communities 
who are using publicly visible Internet identifier spaces, and decides on an 
approach for fulfilling these responsibilities going forward, the result may 
also prove helpful in determining what relationships (if any) the IETF needs 
with ICANN, the RIRs, and related parties doing Internet registry operations; 
that should be expected, as it is the same questions, only with respect to the 
publicly-visible identifier spaces that have already been deployed.

FYI,
/John

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 23 Sep 2014 10:08:53 +0000

On Sep 15, 2014, at 10:15 PM, John Curran <[email-masked]<mailto:[email-masked]>> wrote:

On Sep 15, 2014, at 3:00 PM, Milton L Mueller <[email-masked]<mailto:[email-masked]>> wrote:

Hmm.

6nor that the trade association will have open and transparent policy development

I cannot read this without thinking ENUM. While public Enum is not the wild commercial success one would have hoped it has all the properties you describe and an outcome that aligns with your description. RFC6220 was written with this possibility in the back of the mind.

Or I completely misunderstand what the point is you are trying to make.

—Olaf

See:
RFC 3761, IANA considerations in particular.
http://www.iab.org/documents/correspondence-reports-documents/docs2004/2004-08-12-enum-instructions/31/
and
http://www.ripe.net/data-tools/dns/enum/about

— — — — — — — — — —
Olaf Kolkman
(on personal title)

---

From: John Curran <[email-masked]>
Date: Tue, 23 Sep 2014 07:22:03 -0400

On Sep 23, 2014, at 6:08 AM, Olaf Kolkman <[email-masked]> wrote:

>> On Sep 15, 2014, at 10:15 PM, John Curran <[email-masked]> wrote:
>> ...

So the questions remain:

 - Does the IETF have a general statement of responsibilities to the global
   protocol-using community with regards to properties of an IANA registry,
   i.e.  does any policy development need to open, transparent, and inclusive?,
   does there need to be clear efforts for global outreach and engagement for
   such policy bodies?, do they need to have some clear liaison with interested
   governments who wish to monitor/participate, and does there need to be any
   periodic review of all of the above?  (It certainly would be quite a bit easier for
   the IETF to know its expectations/requirements in this area)

 - If there is an understood list of expectations/requirements, does there exist
   clear documentation of who (IETF/IAB, IANA Operator, registry policy body,
   some oversight/review body) handles each of requirements?

 - A comprehensive IANA accountability program would involves making sure that
   the IANA operator is fulfilling their responsibilities, _and_ additionally that any 
   other parties (delegated roles for IANA registries) are fulling theirs as well...

/John

---

From: JFC Morfin <[email-masked]>
Date: Tue, 23 Sep 2014 19:40:48 +0200

John,

there is no need for hypothetical cases. There are already many SDOs 
involved in Internet issues where the IETF is limited to the 
end-to-end protocol set. RFC 1958/3539.

The IETF failed at the user application/user application IDNA2003 
level, before IDNA2008 relocated it, in an end-to-end's subsidiarity 
[RFC 5895]. This situation is addressed by RFC 6852 which is cosigned 
by two of thes other SDOs (IEEE and W3C) and calls for the endosement 
of others.

It is now endorsed by: AFRINIC, LACNIC, RIPE NCC, Afilias, VPN 
Consortium, The Center for Democracy & Technology,  Accellera Systems 
Initiative, Leadmine Pond Productions, NLnet Labs, Advance Computing 
and Research Limited, DEJAN SEO, User Testing Australia,  Computer & 
Communications Industry Association (CCIA),  Adobe,  Cisco,  Internet 
Systems Consortium

Yet, the fringe-to-fringe IUse community I belong to has not endorsed it yet.

I believe it is for two reasons (apart from a lack of trust in the 
USG processes):

- as its promoter for years and facilitator (IUCG@IETF), I am not 
sure its members, as I know them, want to qualify as members of a 
"global community" or as "the people's multitude". I therefore I do 
not  know what really is to be their ploycratic governance and 
position. So, I keep documenting them through a loose specialized 
secretariat/group. I feel this formula is middly appropriate, as it 
is now 36 years old and surviving [without a penny, and some 
achievements], even if it is ill at ease with the concept of "civil 
society" as embodied by the CS organizations. There is no real 
overlap between "use" and "civil".

- the RFC 6852 is uncomplete. It gathers market communities, 
supposedly for them to adopt common technical competitive innovations 
(RFC 6852 is a paradigem for standards), yet it leaves their mutual 
compatibility to a non formal status, without any appropriate 
ultimate consensus resolution process. In the resulting technically 
fragmented internet, TCP/IP/UDP and IPaddresses seem to be the last 
common links between norms, names and number variations. I understand 
some wish the IANA is another one - as for langtags where Unicode 
wanted to engineer a digital control of languages and culures.

This is why the signatorees of this lose paradigmatic definition want 
to champion a unique IANA against their own multiregistry RFC 6220 
model. This seems to only translate historical rigidities, lack of 
imagination, and/or political interests. Some are by-passed by the 
strength and the speed of the change.

Actually, John, I always wandered about the RIRs' real interest. This 
is because I think that address definition should be algorithmic. But 
today I start believing that in not endorsing the uncomplete RFC 6852 
yet, ARIN and you might very well be the ultimate I*point of cohesion. Thx.

jfc

At 13:22 23/09/2014, John Curran wrote:
>On Sep 23, 2014, at 6:08 AM, Olaf Kolkman 
><<mailto:[email-masked]>[email-masked]> wrote:
>
>>>On Sep 15, 2014, at 10:15 PM, John Curran 
>>><<mailto:[email-masked]>[email-masked]> wrote:
>>>...
>>I cannot read this without thinking ENUM. While public Enum is not 
>>the wild commercial success one would have hoped it has all the 
>>properties you describe and an outcome that aligns with your 
>>description. RFC6220 was written with this possibility in the back of the mind.
>
>So the questions remain:
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Sep 2014 06:40:59 +0200

Hi John,

>    the IETF to know its expectations/requirements in this area)

We do not single out the IANA registry.  Rather ALL of our decisions
should follow that framework.  See RFC 6852 that the IAB released in
January of 2013, as mentioned in our current draft.

>    some oversight/review body) handles each of requirements?

RFC 6220 documents all roles.

>    other parties (delegated roles for IANA registries) are fulling

I believe the draft already documents this, but may need a two or three
word edit:

It currently reads:
>    Each year a
>    service level agreement is negotiated that supplements the MoU.

It may be better to change to "is reviewed and negotiated"...

Eliot

---

From: John Curran <[email-masked]>
Date: Wed, 24 Sep 2014 08:44:21 -0400

On Sep 24, 2014, at 12:40 AM, Eliot Lear <[email-masked]> wrote:

> We do not single out the IANA registry.  Rather ALL of our decisions should follow that framework.  See RFC 6852 that the IAB released in January of 2013, as mentioned in our current draft.
> 
>> 

Eliot - 
 
  Excellent.  For which registries has IETF delegated policy authority to other bodies, 
  and how often does it check to see if they are operating in an open, transparent, 
  and inclusive?  It's unclear from RFC 6220 (or associated documentation) and is
  information that anyone impacted as a result would want to see plainly stated.

> I believe the draft already documents this, but may need a two or three word edit:
> 
> It currently reads:
>>    Each year a

I'm sorry, you are referring to the IANA Operator...  the party which follows policy
that is received.   I was asking about the bodies which develop such policy.

Thanks!
/John

---

From: S Moonesamy <[email-masked]>
Date: Thu, 25 Sep 2014 00:11:46 -0700

Hi Eliot,

[I changed the topic as it may be easier to track.]

>January of 2013, as mentioned in our current draft.

My reading of the above is that it is different from a position taken 
by the IAB after January 2013 and before October 2013.

For what it worth the position of the IESG was that RFC 6852 was not 
subject to IETF review and approval.  draft-lear-iana-icg-response-01 
has the following:

   "The IETF operates an open and transparent manner [RFC6852]."

I do not think that the reference is appropriate as the document has 
not been subject to IETF review and approval.

Regards,
S. Moonesamy