Subject: [Internetgovtech] Transition to the web

From: S Moonesamy <[email-masked]>
Date: Tue, 08 Jul 2014 15:01:48 -0700

Hello,

There is a message at 
http://mm.icann.org/pipermail/ianatransition/2014/001160.html from 
"ICANN staff".  It looks like nobody from ICANN took responsibility 
for the decision to transition the IANA Transition discussion to the 
web.  It is odd to see that in a message which mentions transparency.

Here are some of ICANN conditions to participation:

   "ICANN has the right (though not the obligation) to, in ICANN Forum's sole
    discretion (i) refuse or remove any content that, in ICANN Forum's
    reasonable opinion, violates any ICANN policy or procedure or is in any
    way harmful or objectionable, or (ii) terminate or deny access to and
    use of the Website to any individual or entity for any reason, in
    ICANN's sole discretion."

I note the "sole discretion" in the above.

   "Adhere to ICANN's conflict of interest policies"

There isn't any information about those policies.

   "Conduct themselves in accordance with ICANN policies."

There isn't any information about those policies.

   "Protect the organization's assets and ensure their efficient and 
effective use."

The participant has to protect ICANN's assets.  In simple terms 
participants should work towards ensuring ICANN's interest.

The last entity that attempted a transition of discussions to the web 
found out that it was a failure.  It looks like ICANN staff has not 
learned anything from that.

Regards,
S. Moonesamy

---

From: Michele Neylon - Blacknight <[email-masked]>
Date: Wed, 9 Jul 2014 12:55:05 +0000

There's a lot of content, including a discussion forum, over on https://www.icann.org/stewardship

As for the policies you mentioned, all of those policies are published on the ICANN website

If you're having issues locating them I'm sure someone can point you to them

Regards

Michele

--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
http://www.blacknight.co/
http://blog.blacknight.com/
http://www.technology.ie
Intl. +353 (0) 59  9183072
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845

-----Original Message-----
From: Internetgovtech [mailto:[email-masked]] On Behalf Of S Moonesamy
Sent: Tuesday, July 08, 2014 11:02 PM
To: [email-masked]
Subject: [Internetgovtech] Transition to the web

Hello,

There is a message at
http://mm.icann.org/pipermail/ianatransition/2014/001160.html from "ICANN staff".  It looks like nobody from ICANN took responsibility for the decision to transition the IANA Transition discussion to the web.  It is odd to see that in a message which mentions transparency.

   "Protect the organization's assets and ensure their efficient and effective use."

The participant has to protect ICANN's assets.  In simple terms participants should work towards ensuring ICANN's interest.

The last entity that attempted a transition of discussions to the web found out that it was a failure.  It looks like ICANN staff has not learned anything from that.

Regards,
S. Moonesamy

_______________________________________________
Internetgovtech mailing list
[email-masked]
https://www.iab.org/mailman/listinfo/internetgovtech

---

From: S Moonesamy <[email-masked]>
Date: Wed, 09 Jul 2014 08:00:14 -0700

Hi Michele,
>https://www.icann.org/stewardship

There is a statement from the Advisor to the President on Global 
Strategy on that web page.  I'll quote part of it:

   "we must first be sure that we all agree on the initial process"

I'll wait for the IETF representatives to ask IETF participants 
whether they agree.

>If you're having issues locating them I'm sure someone can point you to them

I did have issues locating these policies.

Regards,
S. Moonesamy

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Jul 2014 12:16:53 -0400

> There's a lot of content, including a discussion forum, over on https://www.icann.org/stewardship

Yes, and it's all ridiculous.  That site (or "microsite", as it's been
styled) both attempts to impose ICANN policies on the global
discussion about all IANA and pretends to be a single discussion point
for the entire transition.  But as we heard in London at the ICANN
meeting's session on the IANA transition, the way this should really
be pursued is by working on the separate parts of the IANA function
inside the concerned communities.

So, we don't actually need a single site, or list, or anything to
discuss the overall IANA transition.  The co-ordination group is there
to solve that problem.  But if we did need such a site, it could not
possibly come under ICANN's terms of service, which include a rule
that one has to protect ICANN's assets.

Were this not an IETF list (so we don't really have a reason to
discuss the names-IANA issue), I'd suggest that ICANN should repurpose
its microsite to facilitate the discussion in the names community.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Jul 2014 12:18:06 -0400

On Wed, Jul 09, 2014 at 12:16:53PM -0400, Andrew Sullivan wrote:
> Were this not an IETF list

Err, I meant "IAB" list.  Many apologies.

A

-- 
Andrew Sullivan
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Wed, 09 Jul 2014 12:56:38 -0400

--On Wednesday, July 09, 2014 12:16 -0400 Andrew Sullivan
<[email-masked]> wrote:

>...
> Were this not an IAB list (so we don't really have a reason to
> discuss the names-IANA issue), I'd suggest that ICANN should
> repurpose its microsite to facilitate the discussion in the
> names community.

(above corrected)

It would still be inappropriate for it to require adherence to
ICANN policies --notably preservation of ICANN assets and giving
priority to ICANN's best interests-- by the users or in
discussions on that site.

At a very high level, I think that is one of the key issues in
the discussion.  From my point of view, the criteria for a
successful conclusion is one that best serves the long-term
interests of the Internet and its users (I hope those are the
same).  

Various people among ICANN leadership and staff seem to keep
slipping into assertions about ICANN's own best interests
("assets" included).  If that is just a slip or an unintentional
application of an inappropriately-general rule, I think it is
worth correcting because it is by no means proven that what is
good for ICANN is good for the Internet.  If it is more than
that, then, IMO, it is really important that we resist moves in
the direction of substituting "best interests of ICANN" for
"best interests of the Internet" as a criterion, must less a
constraint on discussions.

   john

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Jul 2014 13:14:01 -0400

> discussions on that site.

Well, perhaps, but I'm not sure this list is the right place to have
an opinion about that.  I recognize the difficulty, however, of
attempting to express that to ICANN given that the terms of service of
the site presumably to be used for such communication might be
unacceptable.  But I'm not sure this list is the right place to try to
tell ICANN how it ought to run its process for figuring out the
names-relevant transition of the IANA function.

There _is_ an interesting wrinkle directly related to the IETF (and
perhaps indirectly to the IAB), however.  That is, the IETF maintains
an independent registry of special-use names.  These also need to be
registered with IANA, but maybe not in the DNS.  Clearly, that list
and the root zone mustn't be in conflict.  It's hard to see how to
make this point to ICANN if one is uncomfortable with the terms under
which ICANN is operating its community process.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Seun Ojedeji <[email-masked]>
Date: Wed, 9 Jul 2014 18:46:30 +0100

It is just so unfortunate the way ICANN is "acting" up. Even if ICANN
needed a forum (which I open-mindedly reviewed as I thought it's okay to
have options) I don't see any motive to shutdown the mailing list...unless
it is an attempt to discourage a broader discussion of the subject matter.
One would expect that ICANN will allow the coordination team do it's job
and not interfere!
More so the forum is not even independent of ICANN content/usage policies
as Andrew rightly observed. It is my hope that the coordination team will
do the needful.

Regards

sent from Google nexus 4
kindly excuse brevity and typos.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Jul 2014 19:04:47 +0100

On 09/07/14 18:14, Andrew Sullivan wrote:
> But I'm not sure this list is the right place to try to

I agree. Which makes it even more of a shame that icann
seem block-headedly intent on shuttering the mailing list
where that discussion would be appropriate.

S.

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 09 Jul 2014 14:06:51 -0400

> where that discussion would be appropriate.
Kind of sums up in a sentence all the reasons that ICANN needs continued 
oversight.

Miles Fidelman

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

---

From: "Lynn St.Amour" <[email-masked]>
Date: Wed, 9 Jul 2014 15:18:02 -0400

In thinking about how to turn this around, what if a few key people (say IETF and IAB Chairs) were to write to Fadi and some of his key advisors and suggest they reconsider their recent actions given how counter this is to so many principles.  ICANN senior staff may just not be aware of this.

And, maybe the CG should have a statement of "what good looks like" or of what one should reasonably expect from these processes.  This is where the IETF and IAB can help - you have far more experience with these types of community and consensus processes than any other group.

Lynn

---

From: Carsten Schiefner <[email-masked]>
Date: Wed, 09 Jul 2014 21:23:57 +0200

Hi Lynn,

On 09.07.2014 21:18, Lynn St.Amour wrote:
> In thinking about how to turn this around, what if a few key people
> (say IETF and IAB Chairs) were to write to Fadi and some of his key
> advisors and suggest they reconsider their recent actions given how
> counter this is to so many principles.  ICANN senior staff may just
> not be aware of this.

that indeed might be the case - that's why I'd support your take on this.

It however puts another question on the table: how "senior" @ ICANN one 
does need to be to be or become aware of it *before* actually taking 
action as we have seen?

Best,

	-C.

---

From: Seun Ojedeji <[email-masked]>
Date: Wed, 9 Jul 2014 20:43:25 +0100

sent from Google nexus 4
> that indeed might be the case - that's why I'd support your take on this.
Although I doubt this could be the reason because I won't expect such
decision to be taken by junior ICANN staff as those would just be
implementers. Also there are quite senior ICANN folks on that list which
should remove the doubt of their awareness. Nevertheless, one could reason
with your assumption for benefit of doubt.

> It however puts another question on the table: how "senior" @ ICANN one
does need to be to be or become aware of it *before* actually taking action
as we have seen?
More like don't be senior if you want to be aware ;)... lol

Cheers!

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Wed, 9 Jul 2014 16:45:11 -0300

It'd be quite worrying if ICANN is becoming an organisation where middle
management are who actually make these important decisions without proper
oversight. Several examples come to mind, none of them good.

I support Lynn's idea.

regards

-Carlos

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
h <http://cagnazzo.name>ttp://cagnazzo.me
=========================

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Jul 2014 08:39:03 +1200

> Kind of sums up in a sentence all the reasons that ICANN needs continued

Yes. I am very disillusioned by this. I agree with Lynn's suggestion
about triggering some high-level messages about this, but it suggests
that a watchdog with teeth is needed (and I'm not at all convinced that
NTIA has teeth in practice). "Teeth" generally means having the power
to fire people.

    Brian

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 09 Jul 2014 16:40:19 -0400

> NTIA has teeth in practice). "Teeth" generally means having the power

Or to chop funding.

Miles

---

From: Christian de Larrinaga <[email-masked]>
Date: Thu, 10 Jul 2014 10:43:11 +0100

Brian

The problem is not use of website or email it is that ICANN is going
well beyond the remit that the US Government set it to facilitate a
global dialogue to establish a post US governmental top down role.

ICANN has a vested interest in the outcome. It is not a neutral party.
It's conduct so far has determined the topics, the mechanisms, the
committees, the dialogue within those groups, the representation, and
now the communications tools all under its own direct management control.

This is not facilitation it is a blatant attempt to own the entire issue
from top to bottom.

The key response from IETF is some fraternal frankness that expresses
with clarity our requirements for Registry operations in future.  US.gov
has spoken now IETF needs to fill any policy void left for those
resources IETF is responsible for.

Christian

-- 
Christian de Larrinaga
FBCS, CITP, MCMA
-------------------------
@ FirstHand
-------------------------
+44 7989 386778
[email-masked]
-------------------------

---

From: S Moonesamy <[email-masked]>
Date: Thu, 10 Jul 2014 02:27:20 -0700

Hi Alissa, Jari,

I am writing to you as you are the representatives of the IETF in the 
matter of the IANA Transition.

One of the conditions required for participation in the IANA 
Transition discussions is that the person must protect ICANN 
assets.  That decision has been taken by ICANN staff [1][2].  I find 
it extremely difficult to accept that condition.  I am curious about 
whether you agreed to that condition.

Regards,
S. Moonesamy

1. http://mm.icann.org/pipermail/ianatransition/2014/001111.html
2. http://mm.icann.org/pipermail/ianatransition/2014/001160.html

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Jul 2014 10:57:24 +0100

On 10/07/14 10:43, Christian de Larrinaga wrote:
> The key response from IETF is some fraternal frankness that
> expresses with clarity our requirements for Registry operations in
> future.

Possibly that. But I also liked what Lynn said - one of the things
that I think I've seen learned by some IETF leadership is when to
put up your hands and say "ok, we were wrong, the community don't
like <X>, here's what we'll do in future," that usually in response
to the community rightly beating up some AD on [email-masked]:-)
I don't think the IESG or IAB are perfect in that respect, but when
the community has (rough) consensus on a thing then that position
does win I think.

I think a note to Fadi or whoever within icann saying that its
time that icann did the equivalent could be useful. (Though I find
it hard to believe icann don't have someone watching this list, or
their own, and they should've just figured out the above earlier.)

S.

---

From: Christian de Larrinaga <[email-masked]>
Date: Thu, 10 Jul 2014 11:24:18 +0100

ICANN has an opportunity to row back of course. I'm not discounting
Lynn's suggestion.

However the intent of my point is that IETF is in danger of delegating
its own responsibilities by allowing the debates to be framed to protect
the interests of, and be owned and implemented by another institution
that is itself a vested interested party. That is ICANN. So there is
quite a bit of back peddling needed.

Taking the initiative here is also important. IETF has responsibility
to  establish process and requirements for any future contract it
directly makes without US Gov intercession with a registry operator
(whether that is at IANA/ ICANN or anywhere)

Brian talks about "oversight with teeth". That is looking increasingly
unlikely. The alternative is undersight with teeth and that is where
IETF and other bottom up communities can develop.

C

---

From: Avri Doria <[email-masked]>
Date: Thu, 10 Jul 2014 07:24:43 -0400

> their own, and they should've just figured out the above earlier.)

I am sure they do.

It may just not matter to the ones who are reading - after all these
sorts of issues will be the purview of the Coordination Group.  Or they
may be reporting back to their bosses, who don't assign the highest
priority to this issue.  When you come right down to it, there is no
aspect of this transition that someone somewhere isn't complaining
about.  They have to be doing triage on problem issues.

At ICANN, as long as the Board is happy, there is little we can do to
change staff's direction.  Perhaps the IETF Liaison to the Board is a
path you can use to communicate your feelings.

BTW, I think I may have lost the thread on this.  The thing we are upset
about is a mailing list?  If someone closed a list you all were
interested it, could someone just reopen another list somewhere else?  I
strikes me that there is no shortage of lists on this stuff.  I seem to
be reading email on the IANA transition and ICANN accountability on
nearly a dozen of them.

But as I said, I may have lost the thread on this conversation.

avri

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Jul 2014 12:47:59 +0100

Hiya,

On 10/07/14 12:24, Avri Doria wrote:
> about is a mailing list?  

Well s/upset/unhappy about/ and yes this is about the
[email-masked] list. But its really now more
about the ham-fistedness of icann in how and why they
are closing that than the list content itself. (Though
the list did have content but I'm told the "microsite"
doesn't really, and there's the issue with inheriting
icann rules for the microsite thing as well I suppose
so I'll not bother finding out if the microsite thing
has any content.)

S.

> If someone closed a list you all were

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Jul 2014 13:51:20 +0200

Hi Lynn,

Thanks for your note.

> In thinking about how to turn this around, what if a few key people (say IETF and IAB Chairs) were to write to Fadi and some of his key advisors and suggest they reconsider their recent actions giv…

I do think it would be good for the IETF and IAB chairs to say
something.  You're exactly right that we don't know what level this
decision was made at.  And it's been executed.  What I'm concerned about
(in response to Avri really)  is two things: first, that the decision
was made by someone unknown to us, absent any discussion, that caught
many by surprise; and second that the result requires acceptance of
terms that ICANN ought not impose.  As to what communication vehicles
exist, it also seems to me that staff jumped the gun and should have
left this matter to the CG.  A change of charter seems in order, but
that gets us to your next point.

> And, maybe the CG should have a statement of "what good looks like" or of what one should reasonably expect from these processes.  This is where the IETF and IAB can help - you have far more experi…

These are just some thoughts...

The NTIA has set the yard stick for broad community consensus.  To
measure that I would hope that the CG goes back to its communities. 
Measuring the aggregate proposal through other yard sticks will be
hard.  For one, it takes a long time to develop those procedures.  As
you say, the IETF's are perhaps the most mature, and we've spent about
half my life developing them.  Therefore, one ground rule could be that
any mailing list that the CG uses will NOT be used as a measure of
consensus, that such measures will happen elsewhere.  That means that
the list would be informative, but not have normative value.  To
reinforce the point, when it becomes clear that a matter should rest
with a particular body (say the RIRs for addresses) that the discussion
should move there and not continue.

Additionally, I would suggest that participants be reminded that their
contributions to any list should be measured by the weight of their
ideas and not the volume of their email.  By the way, on *this* list I
would hope people would observe this rule.

Eliot

---

From: Avri Doria <[email-masked]>
Date: Thu, 10 Jul 2014 08:13:40 -0400

On 10-Jul-14 07:47, Stephen Farrell wrote:
> But its really now more
> are closing that than the list content itself.

Ah, I am sure the ham-fistedness complaint line is quite long.  Probably
just need to wait in the queue.

avri

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Jul 2014 13:20:47 +0100

> just need to wait in the queue.

Or not. For a case like this where we're running an open
process that kind of error needs to be openly beaten up
on IMO. I think fixing it only via a quiet word in the ear
is actually less desirable

And anyway, I've no history myself with icann, so I'm
coming to their ineptitude fresh enough to whine a bit;-)

S.

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Jul 2014 09:02:35 -0400

--On Thursday, July 10, 2014 13:20 +0100 Stephen Farrell
<[email-masked]> wrote:

>> Ah, I am sure the ham-fistedness complaint line is quite
>> long.  Probably just need to wait in the queue.
> 

Usually, I would agree.  But --deliberately stating this as a
hypothetical and without commenting on or trying to extrapolate
from prior ICANN behavior -- suppose you had an organization
with a long history of reacting to public criticism with
defensiveness, denial, stonewalling, coverups, or what, in some
cultures, would be called "fancy footwork".  Even if there were
less of a pattern but some tendencies toward reactions of that
type, someone observing the problem would be faced with a
tactical choice between a pair of goals:

	* If the main goal was the get the problem fixed,
	pointing out the problem quietly would probably have
	better odds of success.
	
	* If the main goal was to hold the organization's feet
	to the fire with the hope that similar situations would
	be avoided in the future but little expectation of
	getting the present one fixed (at least without loss of
	a lot of time and the shedding of real or virtual
	blood), then making a public stink would probably be the
	better choice.

And this sort of thing and the need to consider the possibility
of reactions other than "yes, that is a problem, let's get it
fixed" is why many people in our community prefer working with
emotionless computers and networks to dealing with humans.  :-(

    best,
      john

---

From: Dan York <[email-masked]>
Date: Thu, 10 Jul 2014 13:29:24 +0000

I find myself agreeing with Avri a bit here that I'm not entirely clear on what the issue is...

On Jul 10, 2014, at 7:24 AM, Avri Doria <[email-masked]<mailto:[email-masked]>>
 wrote:

I get that ICANN shut down the [email-masked]<mailto:[email-masked]> mailing list and asked everyone to move to a web discussion forum:

http://mm.icann.org/pipermail/ianatransition/2014/001160.html

I get that they did this without a whole lot of public notice and without much discussion.   I further understand that when you go to that web discussion forum at:

http://discuss-stewardship.icann.org/t/welcome-to-the-discussion/47

you are agreeing by participating to abide by their Standards of Behavior[1], Privacy Policy[2], and Terms of Service[3]:

[1] https://www.icann.org/resources/pages/expected-standards-2012-05-15-en
[2] https://www.icann.org/resources/pages/privacy-2012-12-21-en
[3] https://www.icann.org/resources/pages/tos-2014-06-13-en

I've scanned through all three and they all seem to be the typical kinds of documents you see associated with discussion forums and online sites.  Quite frankly, I'm glad to see they have these documents posted because it provides a framework that can be used to deal with trolls and other people who are being abusive.

>From some comments here on the list I gather there is a concern about one bullet item in the Standards of Behavior [1]:

• Protect the organization’s assets and ensure their efficient and effective use.

Which I personally took as "don't DDoS the website or otherwise do bad things to ICANN's infrastructure", but I gather others are perhaps interpreting as thinking of IANA as an ICANN "asset" and thereby biasing the discussion.

Is that the primary concern here?    If so, could we perhaps suggest to ICANN some clarifying language for this "Standards of Behavior" document to address the concerns?  Perhaps they would be fine making modifications to the document.

Additionally, would it not be reasonable to assume that if these documents apply to an ICANN-hosted web discussion forum they would *ALSO* apply to an ICANN-hosted mailing list?   Perhaps that was never explicitly stated in the sign-up page for the mailing list, but I could see a message from "ICANN staff" going out to the mailing list stating something along these lines. Many or most of us have probably been on lists where this is done from time to time by the list admins.  It seems to me to be a reasonable expectation.

If people are still unhappy with all three of these documents then perhaps, as Avri noted, discussions should take place on some of the other lists and forums that are out there on this issue.

Or am I missing something else here?

Thanks,
Dan

---

From: Lucy Lynch <[email-masked]>
Date: Thu, 10 Jul 2014 06:44:16 -0700 (PDT)

> I find myself agreeing with Avri a bit here that I'm not entirely clear 

Dan -

For me this is about inclusion by default (the push of email to each user 
with the opening for response in your own time) vs the need to constantly 
check in on a coversation (the pull of on line forums with the requirement 
to fit yourself into the correct thread). The flow of a list works better 
for me and it's easy enough to state norms for participstion when the 
conversation drifts. I'd prefer to opt for tacit inclusion - you lose 
folks with every gate you put in the path.

typing in alpine on a free bsd server...

-Lucy

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 Jul 2014 15:48:38 +0200

Dan,

On 7/10/14, 3:29 PM, Dan York wrote:
> I get that ICANN shut down the [email-masked]
> <mailto:[email-masked]> mailing list and asked everyone to
> move to a web discussion forum:
>
> I get that they did this without a whole lot of public notice and
> without much discussion.  

s/much/*any*/

> I further understand that when you go to that web discussion forum at:
>
> you are agreeing by participating to abide by their Standards of
> Behavior[1], Privacy Policy[2], and Terms of Service[3]:
>
> I've scanned through all three and they all seem to be the typical
> kinds of documents you see associated with discussion forums and
> online sites. 

It's [1].  The top of that list is a doozy.  See Andrew's note at
http://mm.icann.org/pipermail/ianatransition/2014/001134.html.  He was
quite specific as to his concerns that I share.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Jul 2014 14:53:10 +0100

>> > I get that they did this without a whole lot of public notice and

Right. And using a pseudonymous sender for those mails,
which is not ideal from an accountability perspective.
And ignoring a thread similar to this one on that list
both at the time of the initial posting and this week.
Basically, they screwed this up mightily and still are
showing no recognition of that.

S.

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 10 Jul 2014 10:30:35 -0400

It occurs to me that, a few messages back, Lynn St.Amour wrote:

> counter this is to so many principles.
>
> ICANN senior staff may just not be aware of this. And, maybe the CG 
> should have a statement of "what good looks like" or of what one 
> should reasonably expect from these processes. This is where the IETF 
> and IAB can help - you have far more experience with these types of 
> community and consensus processes than any other group.

I kind of wonder if, by now, some folks HAVE written to Fadi.  If not, 
perhaps the question becomes why not?

Miles Fidelman

---

From: Dan York <[email-masked]>
Date: Thu, 10 Jul 2014 14:30:47 +0000

Eliot,

On Jul 10, 2014, at 9:48 AM, Eliot Lear <[email-masked]<mailto:[email-masked]>>
 wrote:

I've scanned through all three and they all seem to be the typical kinds of documents you see associated with discussion forums and online sites.

It's [1].  The top of that list is a doozy.  See Andrew's note at http://mm.icann.org/pipermail/ianatransition/2014/001134.html.  He was quite specific as to his concerns that I share.

Ah, gotcha.  That message from Andrew is VERY helpful.  He went through the Standards of Behavior with a finer attention to detail than I did and I do understand and agree with his concerns.

Thank you for clarifying the issue and also for the indication that there was no real discussion about this transition on the email lists.

I guess the larger question I still have is whether it is reasonable to assume that an ICANN-hosted mailing list would operate under the same SoB and ToS as the online forum.  To me I think it probably *is*, although that may not have been explicitly stated in any list communication or pages.

The other question is: what do people want as an outcome?

1. Do we want ICANN to reinstate the ianatransition email list?

2. Do we want ICANN to change its Standards of Behavior to address the concerns raised by Andrew and others?

3. Do we want to as a group move the discussion to some other non-ICANN forum and try to encourage people to go there?

4. Do we want "someone" from ICANN to say that they didn't handle this transition terribly well?  (but then what?)

Or is there something else people want?  What is the action we want to see coming out of this discussion?

Thanks,
Dan

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 10 Jul 2014 10:40:42 -0400

Dan York wrote:
> I guess the larger question I still have is whether it is reasonable 
> to assume that an ICANN-hosted mailing list would operate under the 
> same SoB and ToS as the online forum.  To me I think it probably *is*, 
> although that may not have been explicitly stated in any list 
> communication or pages.
>

yes
> 3. Do we want to as a group move the discussion to some other 
> non-ICANN forum and try to encourage people to go there?

there do seem to be lots of other forums already in place
>
> 4. Do we want "someone" from ICANN to say that they didn't handle this 
> transition terribly well?  (but then what?)

absolutely, and it would be useful to know how the decision was made, 
and at what level of the organization -- that, by itself, would be a 
useful input into discussion of how much oversight of ICANN is needed, 
going forward

perhaps a related matter: it sure would be interesting to get some 
feedback on to what extent anybody at ICANN was actually paying 
attention to input from list discussions
> see coming out of this discussion?

Perhaps some direct recognition, by the transition group, that how ICANN 
has handled community input and discussion, is in itself an important 
consideration as transition planning goes forward.

Miles Fidelman

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Thu, 10 Jul 2014 11:41:38 -0300

Hello!

> Eliot,
... snip....

> 
> I guess the larger question I still have is whether it is reasonable to
> assume that an ICANN-hosted mailing list would operate under the same
> SoB and ToS as the online forum.  To me I think it probably *is*,

Good point. However, MLs being what they are, everyone still keeps a
copy of messages. There is further public record of all that is
discussed and even if ICANN would take the misguided step of deleting
messages from the ML archive, the messages would still be there.

> 1. Do we want ICANN to reinstate the ianatransition email list?

Yes

> concerns raised by Andrew and others?

Yes

> 
> 3. Do we want to as a group move the discussion to some other non-ICANN
> forum and try to encourage people to go there?
> 

Not necessarily. I still believe that a properly-behaving and
adequately-supervised ICANN is still the best venue for this discussion.

> transition terribly well?  (but then what?)

Not necessarily. It would be however helpful to have some 'mea culpa'.

> see coming out of this discussion?

Thank you for transforming the focus from catharsis into actions :-)

-Carlos

---

From: Seun Ojedeji <[email-masked]>
Date: Thu, 10 Jul 2014 15:42:18 +0100

I agree with the view stated by Lucy, it's not about discussing on another
list. For me it's just the fact that ICANN seem not to care on this one by
not making any attempt to address all the comments by the community. This
is a community process that exceed ICANN immediate community and so it's
somewhat militant to have acted the way they did.

Whenever I read Fadi call for participation of various stakeholders in this
process, I get encouraged because he seem passionate about it. However when
you get the participation and don't by action show them that you are
listening makes it against the "loose" term called M'ism which is supposed
to be the foundation in this process!

Regards
sent from Google nexus 4
kindly excuse brevity and typos.
On 10 Jul 2014 14:44, "Lucy Lynch" <[email-masked]> wrote:

> conversation drifts. I'd prefer to opt for tacit inclusion - you lose folks
> with every gate you put in the path.
>
>  On Jul 10, 2014, at 7:24 AM, Avri Doria <[email-masked]<mailto:[email-masked]
>> >>
>> wrote:
>>
>> I get that ICANN shut down the [email-masked]<mailto:
>> [email-masked]> mailing list and asked everyone to move to a
>> web discussion forum:
>>
>> I get that they did this without a whole lot of public notice and without
>> much discussion.   I further understand that when you go to that web
>> discussion forum at:
>>
>> I've scanned through all three and they all seem to be the typical kinds
>> of documents you see associated with discussion forums and online sites.
>>  Quite frankly, I'm glad to see they have these documents posted because it
>> provides a framework that can be used to deal with trolls and other people
>> who are being abusive.
>>
>>  From some comments here on the list I gather there is a concern about
>>> one bullet item in the Standards of Behavior [1]:
>>>
>>
>> Which I personally took as "don't DDoS the website or otherwise do bad
>> things to ICANN's infrastructure", but I gather others are perhaps
>> interpreting as thinking of IANA as an ICANN "asset" and thereby biasing
>> the discussion.
>>
>> Is that the primary concern here?    If so, could we perhaps suggest to
>> ICANN some clarifying language for this "Standards of Behavior" document to
>> address the concerns?  Perhaps they would be fine making modifications to
>> the document.
>>
>> Additionally, would it not be reasonable to assume that if these
>> documents apply to an ICANN-hosted web discussion forum they would *ALSO*
>> apply to an ICANN-hosted mailing list?   Perhaps that was never explicitly
>> stated in the sign-up page for the mailing list, but I could see a message
>> from "ICANN staff" going out to the mailing list stating something along
>> these lines. Many or most of us have probably been on lists where this is
>> done from time to time by the list admins.  It seems to me to be a
>> reasonable expectation.
>>
>> If people are still unhappy with all three of these documents then
>> perhaps, as Avri noted, discussions should take place on some of the other
>> lists and forums that are out there on this issue.
>>

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 10 Jul 2014 11:15:09 -0400

> 1. Do we want ICANN to reinstate the ianatransition email list?

As I think I've argued before, I don't especially care.  I believe
that the co-ordination group is supposed to be an ultra-lightweight
process that just allows the different communities to work
independently on their respective areas of interest.  We don't
actually need a single all-IANA-topics list or forum or any such thing
at all.

But _ICANN_ needs a list, or a forum, or something.  The names
community need to work on its stuff.  But determining their needs and
so on is just not a suitable topic for this (IAB) list.
 
Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Thu, 10 Jul 2014 09:36:54 -0700

Hi Dan,
At 06:29 10-07-2014, Dan York wrote:
>I find myself agreeing with Avri a bit here that 
>I'm not entirely clear on what the issue is...

The secondary issue was that ICANN staff ignored 
the comments from an IAB member and an IESG 
member.  I did not mention that to the 
representatives who seek to represent me.

>I get that ICANN shut down the 
>[email-masked] mailing list and asked 
>everyone to move to a web discussion forum:
>
>I get that they did this without a whole lot of 
>public notice and without much discussion.   I 
>further understand that when you go to that web discussion forum at:

There was a public notification about that.  The 
issue here is that nobody from ICANN took responsibility for that decision.

>you are agreeing by participating to abide by 
>their Standards of Behavior[1], Privacy Policy[2], and Terms of Service[3]:
>
>I've scanned through all three and they all seem 
>to be the typical kinds of documents you see 
>associated with discussion forums and online 
>sites.  Quite frankly, I'm glad to see they have 
>these documents posted because it provides a 
>framework that can be used to deal with trolls 
>and other people who are being abusive.

I could categorize a person who disagree with me 
as "troll" or as "being abusive".  However, I 
would knowingly be treating the person 
unfairly.  If a person's messages are the cause 
of a problem I would explain why I think it is a problem.

> From some comments here on the list I gather 
> there is a concern about one bullet item in the Standards of Behavior [1]:
>
>Which I personally took as "don't DDoS the 
>website or otherwise do bad things to ICANN's 
>infrastructure", but I gather others are perhaps 
>interpreting as thinking of IANA as an ICANN 
>"asset" and thereby biasing the discussion.

It takes a few minutes for an ICANN director to 
post a message saying that IANA is not an ICANN asset.

>Is that the primary concern here?    If so, 
>could we perhaps suggest to ICANN some 
>clarifying language for this "Standards of 
>Behavior" document to address the 
>concerns?  Perhaps they would be fine making modifications to the document.

I am not inclined to participate in a discussion 
about the IANA Transition which is subject to ICANN rules.

>Additionally, would it not be reasonable to 
>assume that if these documents apply to an 
>ICANN-hosted web discussion forum they would 
>*ALSO* apply to an ICANN-hosted mailing 
>list?   Perhaps that was never explicitly stated 
>in the sign-up page for the mailing list, but I 
>could see a message from "ICANN staff" going out 
>to the mailing list stating something along 
>these lines. Many or most of us have probably 
>been on lists where this is done from time to 
>time by the list admins.  It seems to me to be a reasonable expectation.

I haven't seen anyone with an icann.org email 
address stating that on the ianatransition mailing list.

>Or am I missing something else here?

The following is a statement [1] from the Advisor 
to the President on Global strategy:

   "we must first be sure that we all agree on the initial process."

Could you please show me where the decision about 
where to have the IANA Transition discussion was taken?

Please note that I am okay with taking this 
discussion to [email-masked] as it might be off-topic for this IAB mailing list.

Regards,
S. Moonesamy

1. https://www.icann.org/stewardship

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 10 Jul 2014 10:10:31 -0700

SM, all,

I think there are a few important pending developments to think about:

1. My personal opinion, as I stated at the ICANN50 session on the IANA
stewardship transition, is that it would be reasonable for one of the
roles of the coordination group to be to facilitate communications and
information sharing about the transition plan development process. I hope
this will include (1) a centralized location providing links to all of the
separate mailing lists and discussions that will occur in the IETF, RIR,
ICANN, and other communities about the transition, (2) periodic
summaries/status updates of those discussions, and (3) facilitation of an
over-arching mailing list/venue for transition discussion *if one is
necessary* (opinions might differ as to whether one is necessary if there
already exist sufficient venues for discussion in the separate
communities). However, the CG is still in formation, so it may be a little
while before any of those items get setup. My hope is that they will get
setup, and that once they do the role of the ICANN forum and microsite may
abate as focal points for information or discussion of the transition.

2. I think it would be very helpful for there to be a venue for
names-specific transition issues discussion. There is a cross-community
working group concerning the IANA stewardship transition forming among
some of the ICANN constituencies (kicked off by ccNSO and gNSO — see,
e.g., http://ccnso.icann.org/node/45666). I don’t have enough ICANN
background to fully understand how this group will work, but if it indeed
provides an open forum where any interested party can discuss transition
issues related to names (without agreeing to any sort of bylaws), I think
that will be a good thing. Again, it may take a few more weeks to see if
that can get setup.

So, in summary, I am hopeful that in short order there will be an easy way
to find out where to discuss each of the components of the transition plan
development, that such places will exist for each of the IANA functions
(and an overarching place will exist if that indeed seems useful to
people), and that the discussions that take place will not require
agreement to uphold the bylaws of any particular organization.

Alissa

---

From: John C Klensin <[email-masked]>
Date: Thu, 10 Jul 2014 13:14:17 -0400

--On Thursday, July 10, 2014 06:44 -0700 Lucy Lynch
<[email-masked]> wrote:

> For me this is about inclusion by default (the push of email
> to each user with the opening for response in your own time)
> vs the need to constantly check in on a coversation (the pull
> of on line forums with the requirement to fit yourself into
> the correct thread). The flow of a list works better for me
> and it's easy enough to state norms for participstion when the
> conversation drifts. I'd prefer to opt for tacit inclusion -
> you lose folks with every gate you put in the path.

Lucy (and Dan),

I think there are two entirely separate issues here and that the
combination has been one of the sources of confusion.

First, on which I agree with you, is the inherent difference
between mailing lists and web-based forums, even when the latter
are supplemented by notifications of when things change.  Part
of it is a matter of convenience, part is that the difference
biases the profiles of the participants.    IIR, a colleague who
is now a senior ICANN staff member once described similar
situations as the web forums selecting for greater participation
by those who had too much time on their hands than for those who
were busy and productive about other things.  

But not all of the community, even the IETT community, agrees
with us.  If you were to go back and review the IETF threads
about DMARC a while back, you would definitely see signs of an
attitude that can, I think, be summarized as "mailing lists are
an outdated way of communication and, if anti-spam measures make
mailing lists less effective or less usable, that is a cheap
price to pay".   From that perspective, sticking with mailing
lists may bias the discussion toward those of us who are
clinging to obsolete technologies.

The other, IMO completely unrelated, issues is the one that
Andrew, Eliot, and others have been discussing and analyzing.
Intentionally or not, this isn't just a move to the web.  It is
a move that requires those who want to continue to agree to a
long series of principles and requirements.  Some are pretty
typical and pretty harmless -- not much different, IPR rules
aside, from the conditions for using the IETF's web sites.
Others appear less benign.  I tend to summarize them as
requiring agreement that ICANN's best interests are ultimately
more important than those of the Internet and that ICANN staff
can control and/or censor conversations to support those
interests or other ICANN norms.  Andrew's analysis (and various
followups) are better and more precise.

Nothing would prevent ICANN from alleviating those concerns by
posting a notice that said something like "in spite of the
normal rules for our forums, while we expect courtesy, honesty,
etc., you don't need to agree to support ICANN's bylaws and
objectives to participate here".  Perhaps ICANN leadership
doesn't know, but there are (or were) fairly senior ICANN people
on this list (and, I gather, in other places where similar
discussions are occurring) so, unless they all dropped off at a
convenient moment or are deliberately hiding the discussion and
reactions from their leadership/management, each day that goes
by without such a correction reinforces the view that it is
intentional and that, for some people, calls into question the
whole subject of whether the "IANA transition" process can
succeed if ICANN is acting as steward or manager in any way.

    john

---

From: John Springer <[email-masked]>
Date: Thu, 10 Jul 2014 11:15:06 -0700 (PDT)

On Thu, 10 Jul 2014, Lucy Lynch wrote:

> check in on a coversation (the pull of on line forums with the requirement to 
> fit yourself into the correct thread). The flow of a list works better for me 
> and it's easy enough to state norms for participstion when the conversation 
> drifts. I'd prefer to opt for tacit inclusion - you lose folks with every 
> gate you put in the path.

Whole heartedly agree.

> typing in alpine on a free bsd server...

also

John Springer

>> [email-masked]<mailto:[email-masked]> mailing list and 
>> asked everyone to move to a web discussion forum:
>> 
>> I've scanned through all three and they all seem to be the typical kinds of 
>> documents you see associated with discussion forums and online sites. 
>>> From some comments here on the list I gather there is a concern about one 
>>> bullet item in the Standards of Behavior [1]:
>> 
>> ? Protect the organization?s assets and ensure their efficient and 
>> effective use.
>> 
>> Additionally, would it not be reasonable to assume that if these documents 
>> apply to an ICANN-hosted web discussion forum they would *ALSO* apply to an 
>> ICANN-hosted mailing list?   Perhaps that was never explicitly stated in 
>> the sign-up page for the mailing list, but I could see a message from 
>> "ICANN staff" going out to the mailing list stating something along these 
>> lines. Many or most of us have probably been on lists where this is done 
>> from time to time by the list admins.  It seems to me to be a reasonable 
>> expectation.
>> 
>> If people are still unhappy with all three of these documents then perhaps, 
>> as Avri noted, discussions should take place on some of the other lists and 
>> forums that are out there on this issue.
>>

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 10 Jul 2014 13:05:54 -0700

My own two beads worth, which no one is required to share, is that (a) 
the subject matter pertains to a contract let by the government of the 
United States [the IANA Functions Contract], to which it [the USG] has, 
and continues to (b) assert a government interest [it could be a 
registry related to DNSSEC or to the unique identifiers of breakfast 
cereals available in the Congressional cafeterias, either would be 
sufficient], and (c) the incumbent contractor, on behalf of the 
government of the United States, has imposed restriction on speech in a 
public forum which is not content neutral, as Andrew has taken the pains 
to point out.

Some will recall that legal council for the incumbent contractor (Joe 
Simms et alia) have asserted, and continue to assert, that the incumbent 
contractor does not act as an agent of government, and therefore that 
some constraints on its conduct do not apply. In the current instant 
that would be the restriction on imposing a content specific restriction 
on speech in a public forum.

Expecting the incumbent contractor to abandon its position of record 
(for over a decade now) absent constraint seems to me to be an 
expectation unlikely to be realized.

Eric

P.S. A further issue arises from the finite term of the IANA Functions 
Contract, awarded by competitive bid. The incumbent contractor's content 
specific restriction may have the effect of precluding competition award 
of the IANA Functions Contract.

P.P.S. The use of "incumbent contractor" rather than some acronym, has 
no purpose other than to separate the role of a government contractor 
from the its brand or identity, as these are not one and the same.

---

From: Dan York <[email-masked]>
Date: Thu, 10 Jul 2014 20:39:48 +0000

John,

Good summary of the relevant points.  Thank you.  I do have one more philosophical comment... 

On Jul 10, 2014, at 1:14 PM, John C Klensin <[email-masked]>
 wrote:

> biases the profiles of the participants.    
<snip>

> clinging to obsolete technologies.

There is the opposite side of Lucy's comment about the operation of mailing lists (that she typed in alpine).  I completely understand and sympathize with her viewpoint.  I started online in the early 1980's and for many, many years primarily read my email in pine with a whole set of procmail recipes helping keep me sane with a zillion different email lists.  I know there are MANY people within the IETF who still do that - I see it at meetings.  But, that ended for me a number of years back when I really got tired of running my own servers and switched to using webmail-based services and desktop clients. I also was doing more with files and graphics where the drag-and-drop world of the GUI mail clients worked a whole lot better for me.  Even still, I am a big supporter of mailing lists and prefer them in many cases, not the least of which is that I can pretty much read email from wherever I am whenever I want.

But...  there's a whole generation now that has grown up on the Internet *without* experiencing the power of (al)pine and procmail.  People use their ISP's webmail or Gmail or Hotmail or AOL or whatever... and for them the experience of email is typically a pretty poor one without much in the way of sorting, threading and filtering.  Instead of email they like the web-based discussion forums of Facebook or whatever other social network or forum site you want to talk about.  They'd rather have a lengthy discussion in Hacker News, Reddit or Slashdot with the easy capability to see threaded replies, to upvote/downvote, to reply to specific responses, to block people, to choose to get notifications - or NOT - for specific threads, to share links to specific parts of conversations with others.  A few of the email lists I used to be on are quiet now while vigorous discussions are happening in Facebook groups or Google+ communities.

They don't want email.   To them email is the communication medium of last resort when every other option has failed.

And I think some would dispute Lucy's characterization of email as "inclusion by default" because they would point out that in many web forums you can choose how you want to be notified of new articles and have much finer control of what you get versus having everything thrown in your inbox. And they might say that a web forum could be *more* inclusive because anyone can reach it with a web browser and don't need a mail account.

And yes... we could do what we do best as engineers and go down a really deep technical rathole about my last sentence...  and everyone could pile on in telling me how wrong I am and why email is so much better, etc., etc.

But that's not the point.  

The point is that for discussions to be truly "inclusive" of the wider Internet community we do need to find ways to involve people of both polarities - those who want to only read email in pine (and despise web forums) and those who want to only communicate in the web forums of Facebook or Reddit (and despise email).

I don't have the magic answer.

Maybe there isn't one.

If this was an IETF discussion we were talking about we could make it pretty simple because mailing lists are based on the open standards of SMTP and most web forums are their own proprietary walled gardens.  But it's ICANN trying to have the discussion and they are not a standards organization where these kind of things may matter as much.  

Somewhere in there is a balance between the polarities that needs to be made.

Dan

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Jul 2014 13:46:25 -0700

> counter this is to so many principles.  ICANN senior staff may just

(noting some additional postings about this today....)

The major challenge in such a note is for it to be clear, direct,
critical and careful.  That is, it needs to explain the points of
concern and the alternatives being recommended.  It needs to be both
comprehensive and concise, while maintaining a neutral tone about
competence or intent, lest our own communication to them appear
ham-fisted...

So you'd be a good one to write the draft.

And having it be signed by an aggregation of IETF community leadership
makes sense.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Lynn St.Amour" <[email-masked]>
Date: Thu, 10 Jul 2014 17:15:25 -0400

Hi Dave,

thanks for thinking of me :^).

Frankly, I was thinking of a fairly short peer-to-peer note.  Simply saying there are concerns, they have been quite well expressed on this list, and that we wanted to ensure Fadi/ICANN senior management was aware.  No need to hand hold here.   And, until we know ICANN senior management is aware, we do not need to treat this as intentional.

On the other hand, an equally reasonable course of action would be for one of the ICANN staffers on this list to bring it to ICANN senior management's attention and then "someone" gets back to the list.

We are using a lot of cycles talking around something that should be addressed directly, and probably as Andrew says elsewhere.

But, this is just my .02.

Lynn

---

From: Theresa Swinehart <[email-masked]>
Date: Thu, 10 Jul 2014 21:26:52 +0000

Hi Lynn and all, 

Appreciate the exchanges and the useful dialogues. Just to advise the
issue is getting attention, and I should have something back to this list
shortly. 

Kind regards, 

Theresa

On 7/10/14 5:15 PM, "Lynn St.Amour" <[email-masked]> wrote:

>Frankly, I was thinking of a fairly short peer-to-peer note.  Simply
>saying there are concerns, they have been quite well expressed on this
>list, and that we wanted to ensure Fadi/ICANN senior management was
>aware.  No need to hand hold here.   And, until we know ICANN senior
>management is aware, we do not need to treat this as intentional.
>
>On the other hand, an equally reasonable course of action would be for
>one of the ICANN staffers on this list to bring it to ICANN senior
>management's attention and then "someone" gets back to the list.
>
>We are using a lot of cycles talking around something that should be
>addressed directly, and probably as Andrew says elsewhere.
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 10 Jul 2014 15:16:37 -0700

Hi Alissa,
>abate as focal points for information or discussion of the transition.

Thanks for the substantive response.  You may 
have seen the comments on the internetgovtech 
mailing list about ICANN and the microsite.  I 
would not describe an ICANN forum or an ICANN 
microsite as a venue where the word "equitable" is understood.

>e.g., http://ccnso.icann.org/node/45666). I don't have enough ICANN

I am ambivalent about the above.  I'll choose not to comment for now.

>agreement to uphold the bylaws of any particular organization.

I'll say okay for now to keep it easy for you.

Regards,
S. Moonesamy

---

From: Avri Doria <[email-masked]>
Date: Thu, 10 Jul 2014 19:00:06 -0400

> that will be a good thing. Again, it may take a few more weeks to see if

The design team is just getting started now.  Reps from the ccNSO,
ALAC, SSAC and GNSO parts of  ICANN.

As I learn more, I will pass it on for anyone interested.

avri

---

From: Avri Doria <[email-masked]>
Date: Thu, 10 Jul 2014 23:46:27 -0400

On 10-Jul-14 19:00, Avri Doria wrote:
> The design team is just getting started now. 

I mean the charter drafting team.

> Reps from the ccNSO,

---

From: S Moonesamy <[email-masked]>
Date: Fri, 11 Jul 2014 02:19:14 -0700

Hi Christian,
>quite a bit of back peddling needed.

I don't think that the IETF (the word does not include the IAB) is in 
danger.  As mentioned above this is ICANN; parental guidance is advised.

>(whether that is at IANA/ ICANN or anywhere)

The IETF does not have any responsibility.  The IESG may receive 
questions if there is a problem with the protocol registry.

My guess is that there is a view that the IETF can be used to solve 
problems with the other IANA Functions.  The current IETF position is 
that those issues are not an IETF matter.  Anyone disagreeing with 
that can talk to Mr Housley.

>IETF and other bottom up communities can develop.

I would not describe the IETF as a bottom-up community.  As I think 
about all this the words "welfare state for the rich" comes to my mind.

Regards,
S. Moonesamy

P.S. I made a mistake in a previous message about the number of IAB 
members.  There were two IAB members who were ignored.

---

From: Christian de Larrinaga <[email-masked]>
Date: Fri, 11 Jul 2014 13:27:20 +0100

Good points. But I should be clearer.

I was thinking of IANA as the contracted registry operator for those
IANA considerations in RFCs.
There is a cost to operating this which IETF as far as I am aware is not
paying for.

Who is paying?

Does gov.us define this as part of its contract with ICANN for IANA? Is
it a cost that is being cross subsidised in the round from overall
revenue flows at ICANN?

Does IETF pay into this pool?

What happens when the overlying terms from gov.us for IANA contract
comes to an end from IETF perspective? Working through these issues and
being clear how IETF is able to exert what it wants from IANA registry
functions is what I mean by IETF needing to take initiative.

Christian

---

From: Seun Ojedeji <[email-masked]>
Date: Fri, 11 Jul 2014 13:37:45 +0100

Hello Christian,

This could also be likened to legacy IP holders whose resources is
maintained on whois by paying member's fund

Cheers!

On Fri, Jul 11, 2014 at 1:27 PM, Christian de Larrinaga <[email-masked]>
wrote:

> I was thinking of IANA as the contracted registry operator for those IANA
> considerations in RFCs.
> it a cost that is being cross subsidised in the round from overall revenue
> flows at ICANN?
>
> What happens when the overlying terms from gov.us for IANA contract comes
> to an end from IETF perspective? Working through these issues and being
> clear how IETF is able to exert what it wants from IANA registry functions
> is what I mean by IETF needing to take initiative.
>
>
>
> Christian
>
>
>
>
> S Moonesamy wrote:
>
> Hi Christian,
> The IETF does not have any responsibility.  The IESG may receive questions
> if there is a problem with the protocol registry.
>
> problems with the other IANA Functions.  The current IETF position is that
> those issues are not an IETF matter.  Anyone disagreeing with that can talk
> to Mr Housley.
>
> I would not describe the IETF as a bottom-up community.  As I think about
> all this the words "welfare state for the rich" comes to my mind.
>
> Regards,
> S. Moonesamy
>

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

*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: S Moonesamy <[email-masked]>
Date: Fri, 11 Jul 2014 09:08:13 -0700

Hi Christian,
At 05:27 11-07-2014, Christian de Larrinaga wrote:
>There is a cost to operating this which IETF as far as I am aware is 
>not paying for.
>
>Who is paying?

It is a fact that ICANN is paying for the cost of running the 
protocol registry.

>Does gov.us define this as part of its contract with ICANN for IANA? 
>Is it a cost that is being cross subsidised in the round from 
>overall revenue flows at ICANN?

This part is not clear.  The government of the United States believes 
that it is part of the IANA contract.  In the past the IETF has 
timidly expressed its view that the protocol registry is an IETF 
thing.  On the wrong side of the equator this is known as cross-subsidization.

>Does IETF pay into this pool?

No.

>comes to an end from IETF perspective? Working through these issues 
>and being clear how IETF is able to exert what it wants from IANA 
>registry functions is what I mean by IETF needing to take initiative.

The corporation can decide to ask the IETF to pay.  My advice to the 
IETF Chair might be "tell them that the IETF is not going to pay for 
this".  I think that is clear enough. :-)

Regards,
S. Moonesamy

---

From: David Conrad <[email-masked]>
Date: Fri, 11 Jul 2014 10:54:40 -0700

On Jul 11, 2014, at 9:08 AM, S Moonesamy <[email-masked]> wrote:
>> Who is paying?
> It is a fact that ICANN is paying for the cost of running the protocol registry.

Yes (and all the other registries associated with the IANA Functions of course).

>> Does gov.us define this as part of its contract with ICANN for IANA? Is it a cost that is being cross subsidised in the round from overall revenue flows at ICANN?
> This part is not clear.  

It is actually quite clear (since it is explicit in the IANA Functions contract) that the operation of the IANA Functions is at zero cost to the US government, but ICANN is permitted to charge on a cost recovery basis. Since ICANN does not charge for IANA Function services, it is subsidized through ICANN's overall revenues.

> The government of the United States believes that it is part of the IANA contract.  

Yes.

> In the past the IETF has timidly expressed its view that the protocol registry is an IETF thing.  

I'm not sure I'd call RFC 6220 timid.

> On the wrong side of the equator this is known as cross-subsidization.

I don't know what this means.

>> Does IETF pay into this pool?

Correct.  ICANN's FY15 budget including projected revenues are publicly documented at https://www.icann.org/en/system/files/files/proposed-opplan-budget-comments-fy15-16jun14-en.pdf on page 7.  Total root zone management-related revenues (including new gTLD application fees) are 98.6% of ICANN's revenues, Internet numbers-related revenues are 0.5%, and the rest is ICANN meeting-related revenues. I believe the RIRs intend their (voluntary) contribution to be for "their share" of the IANA services, but this has never been formalized.

In other words, domain name registrants are paying for the IANA Protocol Parameter Registry function.

>> What happens when the overlying terms from gov.us for IANA contract comes to an end from IETF perspective? Working through these issues and being clear how IETF is able to exert what it wants from IANA registry functions is what I mean by IETF needing to take initiative.
> The corporation can decide to ask the IETF to pay.  My advice to the IETF Chair might be "tell them that the IETF is not going to pay for this".  I think that is clear enough. :-)

It is probably worth noting that in terms of person-hours required to do the work, the IETF-related work was (back when I ran IANA) the most significant. This may have changed since I left in 2010.

Regards,
-drc
P.S. Full disclosure: I'll be (re)joining ICANN staff on Aug 4 but all information above is from public sources.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Jul 2014 11:08:44 +1200

> There is a cost to operating this which IETF as far as I am aware is not

It doesn't matter, unless one side or the other gives notice to cancel the
IETF/ICANN MOU.

>From a fairness PoV, domain name holders benefit from the existence
and viability of IETF protocols - without those protocols, there
would be no Internet traffic. So it's entirely reasonable that
the cost of the protocol registries is in practice a levy on domain
name holders. User pays.

    Brian

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 11 Jul 2014 19:38:13 -0400

> the cost of the protocol registries is in practice a levy on domain
More than that.. by designating ICANN to perform the IANA functions, 
IETF is essentially granting ICANN an exclusive license to charge for 
those functions.  I.e., IETF may not be paying, but they are providing 
something to ICANN for which ICANN can charge a fee.  (Not that 
different from a franchise agreement.  McDonald's doesn't pay its 
franchisees, the franchisees pay them.)

Miles Fidelman

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Jul 2014 13:11:20 +1200

> franchisees, the franchisees pay them.)

No we didn't and aren't. Please re-read clauses 4.4 and 4.5 of RFC 2860.

   Brian

---

From: S Moonesamy <[email-masked]>
Date: Fri, 11 Jul 2014 18:47:31 -0700

Hi David,

I'll mention this for clarity; I am one of the Crypto Officers for 
DNSSEC.  I don't have any financial interest in names, numbers, ICANN 
or the IETF.  I do not derive any revenue from the protocol registry.

At 10:54 11-07-2014, David Conrad wrote:
>It is actually quite clear (since it is explicit in the IANA 
>Functions contract) that the operation of the IANA Functions is at 
>zero cost to the US government, but ICANN is permitted to charge on 
>a cost recovery basis. Since ICANN does not charge for IANA Function 
>services, it is subsidized through ICANN's overall revenues.

I am aware that the contractor may establish fees.

>I don't know what this means.

My answer is that it is cross-subsidization.  Other people might say 
that it isn't.

>Correct.  ICANN's FY15 budget including projected revenues are 
>publicly documented at 
>https://www.icann.org/en/system/files/files/proposed-opplan-budget-comments-fy15-16jun14-en.pdf 
>on page 7.  Total root zone management-related revenues (including 
>new gTLD application fees) are 98.6% of ICANN's revenues, Internet 
>numbers-related revenues are 0.5%, and the rest is ICANN 
>meeting-related revenues. I believe the RIRs intend their 
>(voluntary) contribution to be for "their share" of the IANA 
>services, but this has never been formalized.
>

Ok.

>It is probably worth noting that in terms of person-hours required 
>to do the work, the IETF-related work was (back when I ran IANA) the 
>most significant. This may have changed since I left in 2010.

My advice might still be "tell them that the IETF is not going to pay 
for this".

Regards,
S. Moonesamy

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 11 Jul 2014 19:05:44 -0700

> the cost of the protocol registries is in practice a levy on domain

Brian,

While Jake, and then Jose, ran the NIC shop at SRI, the contract was 
cost-plus. I only mention this to point out that the "fairness PoV" 
assumes a set of conditions (privatization) that have not been 
continuous over time.

Eric

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 11 Jul 2014 22:32:25 -0400

> No we didn't and aren't. Please re-read clauses 4.4 and 4.5 of RFC 2860.

Point taken.

So where does the designation of IANA/ICANN as the domain and IP address 
authority come from, along with the "franchise" to charge for those 
functions?

Miles Fidelman

---

From: Seun Ojedeji <[email-masked]>
Date: Sat, 12 Jul 2014 07:34:55 +0100

sent from Google nexus 4
kindly excuse brevity and typos.
On 12 Jul 2014 00:08, "Brian E Carpenter" <[email-masked]>
> the cost of the protocol registries is in practice a levy on domain
I think this makes sense, also since IETF is not in anyway creating
standards to make money directly from end users. Afterall IP addresses were
at one point literally free before it became a business affair.

Cheers!

---

From: Eliot Lear <[email-masked]>
Date: Sat, 12 Jul 2014 10:29:13 +0200

Hi,

On 7/12/14, 8:34 AM, Seun Ojedeji wrote:

> standards to make money directly from end users. Afterall IP addresses
> were at one point literally free before it became a business affair.
>

To me there are several aspects of stewardship to keep in mind.  Domain
names and unicast IP addresses are meant to be excludable resources. 
That is- if I pay for ofcourseimright.com, nobody else should have
access to the name.  The fee I pay serves two purposes: first and
foremost (at least in my mind) to see that in fact the resource is being
used, at least in some fashion.  The second purpose is to pay the
relatively nominal cost of administration of the IANA.

IETF protocol parameters registries are on the whole non-excludable
resources.  That I am using port 25 doesn't mean you can't; although the
purpose of port 25 is very clearly defined.  Should another registry be
created that has properties of excludable resources , then it should
probably be handled more like an IP address or a name.

Eliot

---

From: JFC Morfin <[email-masked]>
Date: Sat, 12 Jul 2014 11:24:34 +0200

Is there somewhere a IANA budget document or tax declaration so to 
understand better and the figures involved?
jfc

At 18:08 11/07/2014, S Moonesamy wrote:
>>I was thinking of IANA as the contracted registry operator for 
>>those IANA considerations in RFCs.
>>There is a cost to operating this which IETF as far as I am aware 
>>is not paying for.
>>
>>Who is paying?
>
>>Does gov.us define this as part of its contract with ICANN for 
>>IANA? Is it a cost that is being cross subsidised in the round from 
>This part is not clear.  The government of the United States 
>believes that it is part of the IANA contract.  In the past the IETF 
>has timidly expressed its view that the protocol registry is an IETF

---

From: McTim <[email-masked]>
Date: Sat, 12 Jul 2014 06:29:49 -0500

On Fri, Jul 11, 2014 at 9:32 PM, Miles Fidelman
<[email-masked]> wrote:
>>>>> not

http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority#History

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Jul 2014 08:13:23 -0400

> http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority#History

Not a particularly definitive, or detailed, source.

The model of standards body and designated registration authority is 
pretty well defined one.  For each specific case, how authority has been 
delegated, things get pretty murky.

For IANA (and be reflection ICANN), this all remains just a bit murky 
(at least to me).

Pretty clearly, one set of IANA responsibilities and authorities flow 
from RFC 2680, or rather RFC 2680 documents various practices and 
agreements, and another set from the NTIA contract.  And, as I was 
reminded RFC 2680 excludes domain registration from its scope and 
excludes charging from its scope.

So where, precisely, do the responsibilities for domain registration and 
IP address management come from, along with the authority to charge for 
those services.  By precisely, I mean chapter and verse reference to 
contractual documents (along the lines of "clauses 4.4 and 4.5 of RFC 
2860").

It strikes me that, whatever replaces those clauses, in a post NTIA 
world, is where a responsibility to financially support the full range 
of IANA functions, should be placed; and it's rather critical for this 
not to get overlooked in the transition.  I.e., part of IANA's post-NTIA 
"franchise" to manage domains and addresses should require support of 
the full range of IANA functions.  And, I guess that also raises the 
issue of what happens if, at some future date, IETF decides that the 
IANA functions under its purvue might better be served elsewhere?

Miles Fidelman

---

From: S Moonesamy <[email-masked]>
Date: Sat, 12 Jul 2014 05:15:19 -0700

Hello,
>understand better and the figures involved?

There may be some information at 
https://www.icann.org/public-comments/op-budget-fy15-2014-05-16-en  I 
don't recall whether it contains the figures mentioned above as it 
has been over a month since I took a quick look at the documents 
which were posted to that web page.

Regards,
S. Moonesamy

---

From: McTim <[email-masked]>
Date: Sat, 12 Jul 2014 11:22:52 -0500

It does show the evolution of the role over time, I thought you would
get that that was the point, apologies for being obtuse.

It does detail the RFCs from the early days where the Registry
functions are first mentioned.

In any case it is a starting point.

As far as specific other docs, well the ASO MoU is a good place to start:

http://archive.icann.org/en/aso/aso-mou-29oct04.htm  this is the
second, there was an earlier one in 99.

Of course there are earlier RFCs than this that lay out the address
registry scheme.

You can find them conveniently here:

http://www.ipamworldwide.com/ipv4-addressing.html

Start with 2050 Section 3 Registration perhaps

http://datatracker.ietf.org/doc/rfc2050/

but this has been obsoleted by 7020:

http://datatracker.ietf.org/doc/rfc7020/

On Sat, Jul 12, 2014 at 7:13 AM, Miles Fidelman
<[email-masked]> wrote:
> The model of standards body and designated registration authority is pretty
> well defined one.  For each specific case, how authority has been delegated,
> things get pretty murky.
>
> For IANA (and be reflection ICANN), this all remains just a bit murky (at
> least to me).
>
> Pretty clearly, one set of IANA responsibilities and authorities flow from
> RFC 2680, or rather RFC 2680 documents various practices and agreements, and
> another set from the NTIA contract.  And, as I was reminded RFC 2680
> excludes domain registration from its scope and excludes charging from its
> scope.
>
> So where, precisely, do the responsibilities for domain registration and IP
> address management come from, along with the authority to charge for those
> services.  By precisely, I mean chapter and verse reference to contractual
> documents (along the lines of "clauses 4.4 and 4.5 of RFC 2860").
>
> It strikes me that, whatever replaces those clauses, in a post NTIA world,
> is where a responsibility to financially support the full range of IANA
> functions, should be placed; and it's rather critical for this not to get
> overlooked in the transition.  I.e., part of IANA's post-NTIA "franchise" to
> manage domains and addresses should require support of the full range of
> IANA functions.  And, I guess that also raises the issue of what happens if,
> at some future date, IETF decides that the IANA functions under its purvue
> might better be served elsewhere?
>
>
> Miles Fidelman
>
> --

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sat, 12 Jul 2014 11:15:56 -0700

On 7/12/14 1:29 AM, Eliot Lear wrote:
> ... Domain

The uniqueness property of association (of mnemonic and 32bit int), as 
well as curation of protocol parameters, predate the current contractual 
regimes.
> used, at least in some fashion.

You appear to be making a claim that when the government provided unique 
identifiers at no cost to the requester that the unique identifiers were 
not used.

>    The second purpose is to pay the

I've made a cursory glance at the current budget DRC was kind enough to 
provide a link to, and $2.6m/yr appears to be the incumbent contractor's 
projected cost to carry out the IANA Function. That's 17 cents per 
"Community Anchor Institution" (schools, etc., with broadband), 
according to the USG [1] or a fractional penny per installed CPE within 
the United States [2], or about two quarters per square foot of data 
center -- just in Loudoun Country (Northern Virginia) -- I'm going to 
guess that amortized over aggregated data center acreage for the rest of 
the United States this number approaches a penny per foot. Budget 
reading, math and industry stats error corrections appreciated.

> probably be handled more like an IP address or a name.

I don't quite catch the subtle distinction between something unique, and 
something "excludable".

Eric

[1] http://www.broadbandmap.gov/summarize/nationwide
[2] 
http://en.wikipedia.org/wiki/List_of_countries_by_number_of_broadband_Internet_subscriptions
[3] 
http://www.washingtonpost.com/business/capitalbusiness/loudoun-county-tops-5-million-square-feet-of-data-centers/2013/10/25/dc213cd4-3c39-11e3-b6a9-da62c264f40e_story.html

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Jul 2014 17:38:06 -0400

--On Saturday, July 12, 2014 11:15 -0700 Eric Brunner-Williams
<[email-masked]> wrote:

> I've made a cursory glance at the current budget DRC was kind
> enough to provide a link to, and $2.6m/yr appears to be the
> incumbent contractor's projected cost to carry out the IANA
> Function. That's 17 cents per "Community Anchor Institution"
> (schools, etc., with broadband), according to the USG [1] or a
> fractional penny per installed CPE within the United States
> [2], or about two quarters per square foot of data center --
> just in Loudoun Country (Northern Virginia) -- I'm going to
> guess that amortized over aggregated data center acreage for
> the rest of the United States this number approaches a penny
> per foot. Budget reading, math and industry stats error
> corrections appreciated.

Assuming that your calculations are correct (I suspect they are
close enough for analysis purposes).   The "17 cents per..."
style of analysis seems to me to be useful in only two sets or
scenarios:

(1) To claim that IANA is a public good that should be paid out
of the public coffers without worrying too much about the
amounts involved.  If one makes that argument, one must, I
think, be prepared to argue that IANA is more important (in
terms of priority access to the public coffers) than other
public goods, such a preventing starvation, educating small
children, sundry emergency services such as police and fire
departments, etc.  I'm disinclined to go there; YMMD.

(2) If one has taxing authority with regard to the sources whose
resource impact is being measured and intends to use it.  ICANN
clearly does not have that authority (independent of whether it
can assess fees on entities who do business with it, a different
matter) and a further separation of ICANN from the US Government
also further separates it from anyone with such authority.
Even if ICANN's (or IANA's) ties to the government were closer,
I don't think additional (or new) taxes, especially on
"Community Anchor Institutions" who are mostly nonprofit and
tax-exempt would have much chance in today's legislative
environment in the US.

All of that is obvious independent of the question of whether,
if IANA is going to be treated as a public good or the
equivalent thereof (as several of the discussion threads on this
list effectively suggest even if they don't use those words), it
isn't at all clear why the costs should be measured, assessed,
or supported out of the US alone. 

The latter takes us to another issue to which I know you are as
sensitive as I am.   If the argument for community support of
IANA (generally and the protocol registries in particular) is,
as others have suggested, because everyone using the Internet
benefits from those services, and that principal source of that
support is DNS name-related revenues, then it seems to me that
there is no excuse at all for the ccTLDs --at least the  ccTLDs
who are operated on other than an cost-recovery basis-- being
exempt from paying for those services.    

IMO and for all sorts of reasons, it is not a good idea to try
to insist on that, but that suggests to me that the analyses of
the model and motivations need more thought.

   best,
   john

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Jul 2014 18:12:22 -0400

>>> relatively nominal cost of administration of the IANA.

I just spent some time pouring through the DOC-ICANN contract, the MOU 
between IETF and ICANN, and the "Affirmation of Committments"between DOC 
and ICANN (all courtesy of ICANN's web site, by the way).  As far as I 
can tell:

1. ALL of ICANN's responsibilities and authority to perform the IANA 
function currently flow from the DOC-ICANN contract.
2. That includes the responsibilities for protocol numbers and such.
3. IETF's role is defined in the MOU, but seems to be in addition to, 
and/or enabled by the DOC-ICANN contract.
4. If/when the contract lapses, any "official" responsibilities and 
authority end - except for what comes out of the transition process.

What I infer from this is that

1. The authority to charge for registry related activities, and use of 
those funds to pay for some of the other IANA functions, is all dictated 
by the DOC contract -- and it strike me as perfectly legitimate for DOC 
to require that the income stream support all of the IANA activities.  
In essence the contract is what grants ICANN it's franchise, and DOC can 
dictate the terms of that franchise.

2. If/when the contract lapses, absent a new governance mechanism, ICANN 
either a) has no authority to do anything, or b) has free reign to do 
whatever it wants within the constraints of it's bylaws (to the extent 
that anyone oversees compliance), terms of the MOU and Affirmation that 
outlive the contract, and the degree to which other players cooperate.

Apropos the current discussion, this suggests that, beyond some kind of 
"grant of authority" and associated oversight mechanisms, whatever 
replaces the current contract needs to address:
- what ICANN can and can't charge for (and limits on those charges)
- use of proceeds, specifically as regards support for ALL of the IANA 
functions

Cheers,

Miles Fidelman

---

From: David Conrad <[email-masked]>
Date: Sat, 12 Jul 2014 16:05:55 -0700

Miles,

On Jul 12, 2014, at 3:12 PM, Miles Fidelman <[email-masked]> wrote:
> 1. ALL of ICANN's responsibilities and authority to perform the IANA function currently flow from the DOC-ICANN contract.

> 2. That includes the responsibilities for protocol numbers and such.

I think this will be quite surprising (if not amusing) to (e.g.) folks at RIPE-NCC, AfriNIC, LACNIC, and APNIC. I know individuals at ARIN have argued that there is a top-down chain of authority through various US government agreements, but that always struck me more as transparent and silly CYA driven by a lawyer than anything anyone actually believed in.

It may also come as a surprise to many folks within the IETF (paging Brian Carpenter :)), particularly those who wrote RFCs 2860 and 6220.

> 3. IETF's role is defined in the MOU, but seems to be in addition to, and/or enabled by the DOC-ICANN contract.

I'm unclear why you think there is any relationship between the MoU and the IANA Functions contract.  How exactly does the IANA Functions contract enable the IETF/IAB/ICANN MoU?

> 4. If/when the contract lapses, any "official" responsibilities and authority end - except for what comes out of the transition process.

My impression has always been that the authority for the IANA Function operator (and, in fact, pretty much all other parts of Internet's system of unique identifiers) derives from the acceptance of the recipients of those resources to accept the coordination performed by the operator.  For example, in the case of the IP addresses, an RIR serves as a voluntary coordination point that facilitates a multilateral arrangement for the association of IP address blocks with ISPs and others. Without this coordination service, there is no way the system would scale since it would require myriad bilateral agreements along the lines of "We agree that I have 1.0.0.0/8 and you have 2.0.0.0/8". There is no law that ensures this association -- it is purely the voluntary agreement of the parties involved to accept the association that allows it to work.

A more thorough albeit dated (1996!) description of this view can be found in http://ccs.mit.edu/papers/CCSWP197/CCSWP197.html.

> 1. The authority to charge for registry related activities, and use of those funds to pay for some of the other IANA functions, is all dictated by the DOC contract -- and it strike me as perfectly legitimate for DOC to require that the income stream support all of the IANA activities.  In essence the contract is what grants ICANN it's franchise, and DOC can dictate the terms of that franchise.

Out of curiosity, why do you believe DoC has authority to grant the franchise on management of the Internet's system of unique identifiers?

As a reductio ad absurdum thought experiment, assume DoC decided that this whole multistakeholder thing was a mistake and they decided to grant "the franchise" of the IANA Functions to Evil Defense Contractor, Inc., completely ignoring any input from the IETF, IAB, or anyone else. EDC then decides to charge (say) $1000 for every protocol parameter allocation, modification, or deletion. What would stop the IETF/IESG/IAB from deciding to pick their own "IANA" and having that IANA provide protocol parameter allocation, modifications, and deletion services under the terms the IETF/IESG/IAB permits? 

Similarly, as another absurd thought experiment, there are some who argue that the U. S. Government owns all the address space. Suppose the USG decided to take back "their" address space, perhaps to sell it off to pay off the national debt.  Why do you think ISPs of the world would accept this assertion?

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Jul 2014 13:14:20 +1200

> It may also come as a surprise to many folks within the IETF (paging Brian Carpenter :)), particularly those who wrote RFCs 2860 and 6220.

Well, it's a very legalistic view in an area where there is actually
no law (I mean international law) and no need for law, since things
work perfectly well without it.

<ianal>In fact, the IETF/ICANN MoU is a signed and ratified document,
and I have been told in other contexts that such a document is exactly the
same thing as a contract if it ends up in court. Certainly the attention
paid to its wording by lawyers on both sides in 1999/2000 was exactly
what I have experienced in contract negotiations. Of course, if a court
had to decide between conflicting provisions of an NTIA/ICANN contract
and the IETF/ICANN MoU, one might trump the other. However, I think that
a lot of the ICANN lawyer's amendments to the MoU draft were intended
to avoid conflicting provisions. </ianal>

As far as I can see, the only problem that actually needs a solution
right now is: who is the watchdog with adequate teeth to ensure that if
ICANN takes bad decisions about TLD policy, they can be set back on
the right track?

Everything else is in the "not broken, don't fix" category as far
as I am concerned. The RIRs and the IETF have ways to deal with
bad decisions by ICANN in their own areas of concern.

Apart from that, +1 to David's comments.

  Brian

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Jul 2014 22:05:43 -0400

> It may also come as a surprise to many folks within the IETF (paging Brian Carpenter :)), particularly those who wrote RFCs 2860 and 6220.

Well, the RFC's specfically exclude domain and address functions, and 
preclude charging for anything - so that all comes from the DOC contract.

The DOC contract - 
https://www.icann.org/en/system/files/files/contract-01oct12-en.pdf - 
includes things like this under contractor responsibilities:

C.2.4 The Contractor is required to perform the IANA functions, which 
are critical for the
operation of the Internet’s core infrastructure, in a stable and secure 
manner. The IANA functions are administrative and technical in nature 
based on
established policies developed by interested and affected parties, as 
enumerated in Section C.1.3. The Contractor shall treat each of the IANA 
functions with equal priority
and process all request spromptly and efficiently.

C.2.9 Internet Assigned Numbers Authority (IANA) Functions include (1) 
the coordination
of the assignment of technical Internet protocol parameters; (2) the 
administration of certain
responsibilities associated with the Internet DNS root zone management; 
(3) the allocation of
Internet numbering resources; and (4) other services related to the 
management of the ARPA
and INT top level domains (TLDs).

Which I read as saying:
1. We're paying you to perform all the IANA functions.
2. You've got to coordinate with all the other stakeholders.

There's also a clause about:
- you can't charge the USG
- you CAN charge other people - but it has to be approved by the 
contract officer

To the extent that anybody has "chartered" ICANN to play IANA - that 
seems to be where it comes from, as a follow-on to the old SRI-NIC contract.
> I'm unclear why you think there is any relationship between the MoU and the IANA Functions contract.  How exactly does the IANA Functions contract enable the IETF/IAB/ICANN MoU?

See above.
> Out of curiosity, why do you believe DoC has authority to grant the franchise on management of the Internet's system of unique identifiers?

The contract, and a related document I came across where the DOC 
authorizes ICANN to charge registry fees.
> As a reductio ad absurdum thought experiment, assume DoC decided that this whole multistakeholder thing was a mistake and they decided to grant "the franchise" of the IANA Functions to Evil Defense…

Well, that is the $64,000 dollar question underlying all this transition 
stuff, isn't it.
> Similarly, as another absurd thought experiment, there are some who argue that the U. S. Government owns all the address space. Suppose the USG decided to take back "their" address space, perhaps t…
Chaos would ensue.

This collaborative, multi-stakeholder stuff has been an experiment from 
day one - so far a successful one, but there have been blips - some of 
the games the backbone providers tried to pull around the NSFnet 
backbone, Michigan Bell trying to pull their dark fiber tariff - and so 
far, community reaction has righted the ship. Still, we're heading into 
another set of uncharted waters, where one organization is positioned to 
wreak havoc (either directly, or by community reaction to poor 
decisions).  It seems only prudent to pay attention to some of these 
details.

Right now, the DOC contract is a very loose framework that seems to be 
working.  The transition group is charged with figuring out what comes 
next.  Let's try to work out some of the details.  The question of who 
pays for the IETF-related IANA functions seems to be one of those details.

Cheers,

Miles

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Jul 2014 22:12:50 -0400

> work perfectly well without it.

Arguably, things work because there's just enough law and contracts.  
Isn't the big concern all around "what happens when the very loose leash 
of the DOC contract expires?"  It could be everything just continues to 
work, or chaos could ensue.  The whole point of this multistakeholder 
discussion and transition process is to avoid chaos.
> to avoid conflicting provisions. </ianal>

Yes, it's a contract - but it exists in the context of the DOC contract 
that says:

Which, among other things is the framework under which ICANN charges for 
some IANA functions, and uses those funds to support the rest of the 
functions.

Which funding is the issue that started this particular branch of 
discussion - who pays after the contract expires.

> ICANN takes bad decisions about TLD policy, they can be set back on

That, and funding for the non-domain related functions!
> bad decisions by ICANN in their own areas of concern.

As much as I'm in agreement with "if it ain't broke, don't fix it" - 
there is this looming change and a transition process underway. Seems 
only prudent to take steps to avoid breakage resulting from too little, 
or too much change and transition.

Cheers,

Miles

---

From: David Conrad <[email-masked]>
Date: Sat, 12 Jul 2014 20:20:29 -0700

Miles,

On Jul 12, 2014, at 7:05 PM, Miles Fidelman <[email-masked]> wrote:
> Well, the RFC's specfically exclude domain and address functions, and preclude charging for anything - so that all comes from the DOC contract.

No. It means that policy issues are dealt with outside of the context of RFC 2860.  That does not imply that the authority rests within the DoC contract which did not even exist until the late '90s. If you traveled back in time to the mid-90s and asked the folks who ran the RIRs, I can say with some certainty that the authority for coordination of addresses came from the membership of the RIRs, not the US government (in fact, the RIRs provided funding for the IANA when the NSF/DARPA contracts ended and before DOC unilaterally asserted its authority to define the future of what eventually (and very unfortunately) became known as "Internet Governance").

> To the extent that anybody has "chartered" ICANN to play IANA - that seems to be where it comes from, as a follow-on to the old SRI-NIC contract.

That is one perspective, one that was popular within the US government and very few other places. There are other perspectives, including the one I've been mentioning and the arguments for those perspectives are as valid as yours are.

However, the arguments those differing perspectives lead to are also pointless because in the end, the role that the IANA Function operators performs is to implement what the communities it serves require it implements. It is a coordinative function that ISPs, resolver operators, registry operators, etc., voluntarily agree to participate in. If the IANA Function operators screw up, then the communities will choose to assign the function(s) to another entity. Period.

>> What would stop the IETF/IESG/IAB from deciding to pick their own "IANA" and having that IANA provide protocol parameter allocation, modifications, and deletion services under the terms the IETF/IESG/IAB permits?
> Well, that is the $64,000 dollar question underlying all this transition stuff, isn't it.

No. The transition stuff is trying to figure out how to not disrupt the way the Internet works while removing NTIA from the functions it provides. As far as I can tell, those functions are:

1) ensure ICANN has followed its own processes in validating changes to the root zone;
2) provide a mechanism by which ICANN can be held accountable for its actions;
3) facilitate obtaining exemptions for dealing with entities under sanction in order to provide registry services; and
4) reduce the risk ICANN will be subject to inappropriate legal, economic, and/or geo-political pressure.

(I've been told #3 isn't that big an issue anymore, but don't have direct knowledge -- haven't been at ICANN for 4 years now and I'm told things have changed)

However, instead of dealing with that issue, my impression is that people on this list and elsewhere have been far more focused on whether or not a mailing list is used for communication instead of a web-based forum and how that demonstrates ICANN is incompetent, inappropriate, and/or evil.

> The transition group is charged with figuring out what comes next.  Let's try to work out some of the details.  

Great idea!

> The question of who pays for the IETF-related IANA functions seems to be one of those details.

That is not a function that is currently performed by NTIA. Section 4.4 and 4.5 of RFC 2860 is explicit that ICANN may not charge for IETF-related IANA services. The existing arrangement appears to be working and I have heard no one (other than perhaps yourself) arguing that this is an issue that needs to be addressed as part of the transition. In particular, neither the chair of the IETF, the chair of the IAB, nor ICANN's CEO have suggested that the MOU needs to be revised/terminated to allow ICANN to charge for IETF-related registry services. I'm unclear why you think it is an issue.

Regards,
-drc

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sat, 12 Jul 2014 22:18:53 -0700

> style of analysis seems to me to be useful in only two sets or

My point John is merely that this function, for which the US Government 
takes some present interest, through both the Executive and Legislative 
branches, is presently implemented through a no-cost contract. Were 
Government to return to the prior contractual form, this particular 
item, when amortized across some nominal broad notion of users (Elliot, 
and Brian, have been making a user-pays argument, where user appears to 
be defined as domain registrants, privatization presumed, though a "user 
pays" claim for protocol parameters, generally, is rather narrow if 
limited to domain registrants, and has the effect of privileging a 
former monopoly retaining market power, and its sales channels, and 
trademark holders, with more access to policy making than other, larger 
definitions of "user"), has a "cost" that is rather small.

> amounts involved.

Before looking to whether or not the IANA is a "public good", it is a 
public function, authorized by legislation which in turn is interpreted 
and implemented by an agency of government.

>    If one makes that argument, one must, I
> think, be prepared to argue

Nope. See above.

> that IANA is more important (in
$7.2bn/$4.7bn. The BTOP. And the $0.17/yr salami slice can be taken 
before it is distributed to the subscriber CAIs.
> list effectively suggest even if they don't use those words) ...
The IANA function benefits the public. However, that isn't the issue.

Eric

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 13 Jul 2014 07:49:14 -0400

> 4) reduce the risk ICANN will be subject to inappropriate legal, economic, and/or geo-political pressure.

Isn't that what I just said?

> That is not a function that is currently performed by NTIA. Section 4.4 and 4.5 of RFC 2860 is explicit that ICANN may not charge for IETF-related IANA services. The existing arrangement appears to…

Umm.. yes, it is.  ICANN plays its role in the process, because the DOC 
contract says that it must perform those functions.  And it 
cross-subsidizes those functions from its income stream from other IANA 
functions.

Miles Fidelman

---

From: Eric Burger <[email-masked]>
Date: Sun, 13 Jul 2014 08:04:17 -0400

This is not just David's perception - these are the facts on the ground.

The IANA works because everyone ‘happens’ to use it. There are no contracts mandating it, no treaties mandating it, no laws mandating it. Tomorrow, someone could say, “I’m the new IANA function, use me!” In fact, that has happened: c.f. Name.Space, OpenNIC, New.net, etc. And… no one cared and for the most part, everyone uses the ICANN IANA directories.

If anything, those facts on the ground means we need to be MORE careful about how we proceed than sanguine. One can envision an organization imposing a treaty regime requiring the use of a particular IANA protocol parameters function, IP address function, and domain name function. That would most likely not be in the IETF’s interest.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 13 Jul 2014 15:06:45 +0300

> However, instead of dealing with that issue, my impression is that people on this list and elsewhere have been far more focused on whether or not a mailing list is used for communication instead of…

The above list is indeed good.

> That is not a function that is currently performed by NTIA. Section 4.4 and 4.5 of RFC 2860 is explicit that ICANN may not charge for IETF-related IANA services. The existing arrangement appears to…

For what it is worth, David is right above. I would like to suggest that focusing on the costs is the wrong way to approach the issue. Lets first ensure that we have a system that performs the right functions, and I think we are already close to that. From the 10.000 ft perspective the costs are not such a big issue that they should drive the transition in any particular direction. At least not for protocol parameters.

Jari

---

From: John C Klensin <[email-masked]>
Date: Sun, 13 Jul 2014 11:53:44 -0400

--On Sunday, July 13, 2014 07:49 -0400 Miles Fidelman
<[email-masked]> wrote:

>> That is not a function that is currently performed by NTIA.
>> Section 4.4 and 4.5 of RFC 2860 is explicit that ICANN may
>> not charge for IETF-related IANA services. The existing
>> arrangement appears to be working and I have heard no one
>> (other than perhaps yourself) arguing that this is an issue
>> that needs to be addressed as part of the transition. In
>> particular, neither the chair of the IETF, the chair of the
>> IAB, nor ICANN's CEO have suggested that the MOU needs to be
>> revised/terminated to allow ICANN to charge for IETF-related
>> registry services. I'm unclear why you think it is an issue.
> 
> Umm.. yes, it is.  ICANN plays its role in the process,
> because the DOC contract says that it must perform those
> functions.  And it cross-subsidizes those functions from its
> income stream from other IANA functions.

Miles,

I think what you (and a few others) are losing track of is that
there is both a legal contract and social contract involved in
this.  The latter has existed much longer, long before ICANN
came in being.

Had NTIA, as part of the initial ICANN contract, said "we don't
care what you do with IANA, the only thing we care about is the
path from your decisions about TLDs to distribution of the root
zone" we'd be having different "governance" debates today (I
agree with David about the odiousness of that term and believe
its use has distorted the discussion) but it still would have
been very much in ICANN's interest to preserve (and pay for) the
IANA function.   Similarly, even if one believes that the
IETF-IAB-ICANN MOU has no (or at least dubious) enforceable
legal status, it is documentation of the intent of parties
involved in IANA (out of mutual self-interest, not contractual
obligations) as to how those functions will be carried out,
thereby avoiding misunderstandings.

It is worth remembering that, significantly pre-ICANN, IANA
actually was the locus of the policy functions.  The IETF
_requested_ that IANA create registries and, and some cases,
make allocations; IANA occasionally said "no, that makes no
sense".  A large fraction of registrations occurred without IETF
involvement -- the level of detail and IETF authority in RFC
5226 and its predecessors not only didn't exist, but such a
document might well have been rejected by the IANA because it
exceeded the IETF's authority to approve such a thing (a
discussion that would have occurred within the IAB, by the way).
The transition to an IANA that was almost entirely an
administrative function rather than a policy one started before
ICANN but the formation of ICANN marks, IMO, the major
switchover. 

Even today, ICANN, at least IMO, draws a considerable portion of
its perceived legitimacy from hosting the IANA function.  If
only out of self-interest, I think the odds of their
intentionally and consciously abusing that function sufficiently
to cause other parties to make and carry out other plans are too
small to be worried about.  I thing we should probably worry
much more about the same sorts of "seemed like a good idea at
the time" moves, without adequate consultation to understand the
undesirable effects, that seem to have characterized the
transition move that started this thread.  That probably
reinforces being careful about the oversight questions but, at
least absent doomsday scenarios [1], doesn't have much to do
with finances.

The shift of policy authority to IANA's "clients" didn't prevent
misunderstandings and what we would now claim were attempts at
abuse.  There were early incidents of ICANN/IANA staff believing
that IANA's historic policy authority allowed them to review
IETF allocation requests and implement (or change) them
unilaterally.  Those incidents slipped under the radar of the
ICANN Board and stopped only after NTIA stepped in (after
requests from the direction of the IETF).

In part because I think even more goes on without effective,
in-depth oversight from the ICANN Board today than was the case
in ICANN's earliest days (but perhaps I'm just suffering from
nostalgic delusions), that history probably reinforces the case
for ICANN not being allowed to be self-overseeing, but it has
little or nothing to do with finances.

Similarly, one of the advantages of the early IANA arrangements
--in which the IETF/IESG was insulated from allocation decisions
rather than directly supervising them-- was that it provided
considerable protection against perceptions of business
conspiracies and antitrust claims.  Today, if someone claimed
that a registration had been denied (or one granted that
shouldn't have been) because the IESG was dominated by
competitors of the applicant and/or had appointed a biased
expert, things would get _lots_ more complicated.  Neither being
a lawyer nor a good predictor of the future, I can't guess
whether that situation would become more or less difficult
without even nominal US Government oversight/ supervision of
IANA, but I'd rather see people worried about that than about
the details of financial relationships.  I also think there may
be some lessons for the IETF and the IANA protocol registry
functions in the care that most of the RIRs have exerted to
separate actual allocation decisions from policy-making, but
those issues are not part of the divesture or oversight
questions and actually run counter to the tone and assumptions
of RFC 5226 and some later documents and actions.

     best,
      john

[1} I do worry about finances a bit more than Jari's note
suggests that he does.   The reason is the hypothesis that the
"domain name market" is a bit of a bubble that could collapse
(e.g., as the understanding becomes more general that users are
lots more dependent on search engines and local
bookmarks/favorites than on the details of DNS names at the top
few levels of the tree).  Should that bubble burst, drying up
new TLD applications and even significantly reducing
registrations and reregistrations in existing TLDs, ICANN and
other organizations that are dependent on the revenue stream
associated with the names market (including ISOC) could find
themselves faced with some very hard decisions about priorities,
decisions that, in the extreme case, could involving trading off
staff, offices, and travel against supporting IANA (and the
IETF) in the style to which they have become accustomed.  A few
years ago, I would have been confident that the RIRs would step
in again but, with the exhaustion of IPv4 space and allocations
of IPv6 space in very large blocks, their business (and revenue
flow) models aren't what they were a half-dozen years ago
either.    So there could, long-term, be a financial problem.
But it isn't the oversight / divesture problem and, IMO, should
not be used to distract from conversations about that problem.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Jul 2014 00:16:01 +0300

Thanks for your note, John. I think we are in agreement… perhaps even 
more than you assume :-) I just wanted to clarify my thinking regarding 
the finances part:

> few levels of the tree).

There are several scenarios where something like the above could
happen. My slightly smaller worry of the finances than yours is
not so much dependent on believing that such things could not
happen. They could, particularly on a longer timescales.

My opinion was based more on the relative size of the cost
associated with the protocol parameters function. And a personal
opinion about the likelihood of being able to finance that in some 
new scenario. Not hoping a bad scenario comes to reality, but
I am relatively confident about the kinds of things we could
do under different circumstances. YMMV.

Jari

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 13 Jul 2014 18:18:29 -0400

John,

Thanks for the thoughtful note.

I guess I'm just a bit more jaded about the strength of the social 
contract in the face of shifting legal contracts and economic 
considerations.  Yes - the Internet operates, and operates pretty well, 
because of a web of social contracts and conventions - but.... my 
perception is that there has always been a near-invisible hand that 
enabled and supported the social contracts - right back to the days of 
the initial RFCs.  If it weren't for the gentle, and sometimes not so 
gentle hands of the early DARPA and NSF program managers involved in the 
early days (and NASA, and DoE, ...) we could easily be living in a world 
of balkanized networks, and/or a world much more like that of the telcos 
and cable companies.

In the early days, it was a matter of key personalities, some of whom 
controlled everyone's funding,  that framed the cooperative governance 
style that has evolved for what has become global infrastructure 
(personally I give a lot of the credit to Bob Kahn, during his tenure as 
ARPANET PM, and Vint Cerf for the notion of transitioning IETF to ISOC 
stewardship).  And, of course, John Postel, when it comes to what's 
become IANA.

I'm a little less sanguine about how things might develop, now that the 
early players are getting a bit long in the tooth, and large pieces of 
both the network infrastructure and its supporting organizations have 
become "big business."  And, of course, we have the growing focus of 
government regulators entering the fray.

I see the NTIA contract as sort of the last legacy of a guiding hand 
that has nurtured and protected the social contracts that keep the net 
"working."  And I see the transition as an opportunity for a lot of 
things to go wrong - whether by intent (traditional regulators getting 
their nose into the tent, repressive governments doing their things, 
business interests doing their thing) or accident.  All going on in 
parallel with the wranglings over "network neutrality" work their way 
through the FCC and the courts.

I worry that the sentiment of "if it ain't broke, don't fix it" doesn't 
recognize that something really is shifting in the framework that has 
shaped Internet governance to date - and if we're not careful, a few 
years down the road we're going to be wringing our hands about details 
that we should have worried about today.

I think it behooves us to lift up the hood and understand, in detail, 
the interplay between legal contracts, social contracts, and general 
understanding and cultural conventions - as we go into this transition.

Regards,

Miles Fidelman

---

From: Peter Koch <[email-masked]>
Date: Mon, 14 Jul 2014 17:00:45 +0200

On Sun, Jul 13, 2014 at 03:06:45PM +0300, Jari Arkko wrote:

> For what it is worth, David is right above. I would like to suggest that focusing on the costs is the wrong way to approach the issue.

agree with "focussing", since this is not the IETF-IANA migration list.
However, somewhere down the priorities list there should be an item to think about
other options, probably including loooking for a different service
provider. At one of the recent IETF meetings, during an IANA session, we were
informed that the cost for the IETF part of the IANA function isn't even
assessed and instead subsumed under the overall IANA budget.  This likely takes
advantage of some synergies having the 3.25(*) pillars served at the same
place, but OTOH limits the exploration of said other options.  I'm not interested
in the actual figures now and here, nor in (alternative) sources of
funding, but in making sure we do have a way to get there.  As a side
effect, putting a cost against (opening) an IANA registry might give
valuable input to the standardization process.

-Peter

(*) 0.25 extra for the entangled subjects "names" and "root zone"

---

From: Jari Arkko <[email-masked]>
Date: Sun, 13 Jul 2014 04:25:24 +0300

First, I’m re-naming the thread where we deviate from the original issue.

> bad decisions by ICANN in their own areas of concern.

Indeed. There are contracts. There are ways to track performance. There are audits.

Jari

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Jul 2014 09:06:36 -0700

> Indeed. There are contracts. There are ways to track performance. There are audits.

An essential point to a legitimate contract is providing for the
possibility of switching to someone else.

To the extent that such provision is real and practical, then the
contract has meaningful, operational teeth.  To the extent it doesn't,
then we do not have real leverage.

The issue is not to be critical of the current service provider, but to
honestly consider what to do if we become disenchanted with them.  The
nature of contract-writing is to worry about this possibility, no matter
how unlikely we might think it.

d/

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 14 Jul 2014 11:07:52 -0700

> possibility of switching to someone else.

The 2011 NTIA NOI and follow-on RFP proposed the IANA Functions contract 
to be awarded through a competitive bid process, and for a finite term.

The subsequent contract was awarded to the sole bidder, upon re-tender, 
the incumbent contractor, for a term of three (3) years, extensible to 
five (5) years.

Removing either the finiteness of the term, or the competitive process 
of bidding, really should be explained by their respective advocates, if 
any.

Eric

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Jul 2014 11:11:36 -0700

> to be awarded through a competitive bid process, and for a finite term.

Term limitations are necessary, but not sufficient, to ensure that
switching is a realistic alternative.

The only way to make sure that necessary detail is covered is to
formulate a transition plan and then make sure that the service provider
is obligated to provide whatever information and assistance is needed to
achieve it.

For example, providers often develop assorted tools and information that
they claim as proprietary, which which are essential to the actual
operation.  This effectively locks the operation to that provider.

d/

---

From: Seun Ojedeji <[email-masked]>
Date: Mon, 14 Jul 2014 20:10:31 +0100

Hello Eric,

Pardon me if i may have missed something, this discussion seem to be going
in the line of maintaining the IANA contract regime. If yes, then who will
be the awarder and in whose capacity/authority will the awarder be doing
that?

While i also agree that there is really noting much about IP and Protocol
(although IP process to me may need some re-dress), i am not sure the way
to handle the names is by continuing the contracting approach. There is
absolutely no need to create another layer of lobbying politics; ICANN
should be self healing and IMO, review of the role of the AC/SO backed up
with an external process to resolve conflict may be helpful.

Regards

On Mon, Jul 14, 2014 at 7:07 PM, Eric Brunner-Williams <
[email-masked]> wrote:

> the incumbent contractor, for a term of three (3) years, extensible to five
> (5) years.
>
> Removing either the finiteness of the term, or the competitive process of
> bidding, really should be explained by their respective advocates, if any.
>
> Eric
>
>

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Jul 2014 15:14:57 -0400

Is not the threat of non-renewal the single oversight mechanism 
currently in place for ICANN?  And is not the central question of the 
transition, what should replace it?

Personally, I have seen very few cases of self-oversight - and none come 
immediately to mind.

Miles Fidelman

Seun Ojedeji wrote:
> Hello Eric,
>
> Pardon me if i may have missed something, this discussion seem to be 
> going in the line of maintaining the IANA contract regime. If yes, 
> then who will be the awarder and in whose capacity/authority will the 
> awarder be doing that?
>
> While i also agree that there is really noting much about IP and 
> Protocol (although IP process to me may need some re-dress), i am not 
> sure the way to handle the names is by continuing the contracting 
> approach. There is absolutely no need to create another layer of 
> lobbying politics; ICANN should be self healing and IMO, review of the 
> role of the AC/SO backed up with an external process to resolve 
> conflict may be helpful.
>
> Regards
>
>
> On Mon, Jul 14, 2014 at 7:07 PM, Eric Brunner-Williams 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     The 2011 NTIA NOI and follow-on RFP proposed the IANA Functions
>     contract to be awarded through a competitive bid process, and for
>     a finite term.
>
>     The subsequent contract was awarded to the sole bidder, upon
>     re-tender, the incumbent contractor, for a term of three (3)
>     years, extensible to five (5) years.
>
>     Removing either the finiteness of the term, or the competitive
>     process of bidding, really should be explained by their respective
>     advocates, if any.
>
>     Eric
>
>
>     [email-masked] <mailto:[email-masked]>
>     /Seun Ojedeji,
>     Federal University Oye-Ekiti
>     web: http://www.fuoye.edu.ng
>     Mobile: +2348035233535
>     //alt email:<http://goog_1872880453>[email-masked]
>     <mailto:[email-masked]>/
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Jul 2014 08:40:59 +1200

> of bidding, really should be explained by their respective advocates, if

Why does the arcane way that the NTIA contracts worked matter for
the future? We all know that the competitive appearance was just that
and nothing to do with reality. The question now is about teeth for
the watchdog.

    Brian

    Brian

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Jul 2014 13:42:36 -0700

> and nothing to do with reality. The question now is about teeth for

An important source of useful teeth is the reality of competitive
bidding.  That is, competitive bidding that is... you know... competitive.

d/

---

From: Seun Ojedeji <[email-masked]>
Date: Mon, 14 Jul 2014 22:34:44 +0100

On Mon, Jul 14, 2014 at 9:42 PM, Dave Crocker <[email-masked]> wrote:

> Would you classify the agreement with ICANN on protocol parameters as
being competitive? maybe not, but i am sure ICANN knows that the agreement
got teeth.

Cheers!

---

From: JFC Morfin <[email-masked]>
Date: Tue, 15 Jul 2014 00:21:48 +0200

At 21:14 14/07/2014, Miles Fidelman wrote:
>currently in place for ICANN?  And is not the central question of 
>the transition, what should replace it?

IMHO, the IANA contract should simply be replaced by a IANA protocol. 
This way every technology parameter provider and multi-registry 
ledger administrator could pass information in a consistant and 
responsible manner to every would be/VGN repository. Would a 
repository not be maintained properly users could switch to a more serious one.

What you call a "societal contract" is a multitude emergence: people 
just agree to do it for their convenience. If there is a better one 
(or less bad on - depends on politicals events, e.g. an ICANN 
Snowdenia) they may change their mind.

For example, let imagine that at some stage people start being fed-up 
working for Google for free and in addition paying their taxes: this 
may unballance the equilibrium. Why would people continue to pay for 
the ICANN DNS when some can organize naming in a better, cheaper and 
more reliable way? All these things are subject to competition: why 
to create IANA monopolies?

IETF is the source provider for protocol parameters.
ICANN is the source for DNS Class IN names.
NRO is the source for one IPv4 and 2 IPv6 numbering plans.

Probably large alliances (EU, China, ITU, Libre) will also claim for 
IPv6 numbering plans.
Every other network technology and namespaces will have their own 
parameters and names.
This way ISO will be able to directly maintain ISO 3166, 639, 15924, 10646.

The question only is: who takes the lead in normalizing the IANA 
protocol: the providers or the users side? RFC 6852 has left us in 
the middle of nowhere: there are global communities with their own 
formal or not standards, the only operational global communities are 
US, Chinese, Google, Apple, Windows, sometimes EU? and probably at 
some stage Libre and/or IUse ones.This leaves the internet as 
fragmented in many areas. The IANA should be another fragmentation 
occasion in having several pseudo-dominant or national or 
edge-provider repositories, but a single protocol for all.

I can only say that as a registered non-profit local public operator 
I will not trust any commercialized name/parameter system.
I am aware and sure that I am not alone. This is why we started the 
http://fsp4.net (fail safe plan for the net) alliance and confirmed 
its creation during the https://2014.rmll.info/?lang=en meeting last week.

Best
jfc

>Personally, I have seen very few cases of self-oversight - and none 
>come immediately to mind.
>
>Miles Fidelman
>
>Seun Ojedeji wrote:
>>Hello Eric,
>>
>>Pardon me if i may have missed something, this discussion seem to 
>>be going in the line of maintaining the IANA contract regime. If 
>>yes, then who will be the awarder and in whose capacity/authority 
>>will the awarder be doing that?
>>
>>Protocol (although IP process to me may need some re-dress), i am 
>>not sure the way to handle the names is by continuing the 
>>contracting approach. There is absolutely no need to create another 
>>layer of lobbying politics; ICANN should be self healing and IMO, 
>>review of the role of the AC/SO backed up with an external process 
>>to resolve conflict may be helpful.
>>
>>Regards
>>
>>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Jul 2014 16:00:31 +0300

Dave:

I agree, of course. (Although not as the only thing; any relationship needs an escalating set of remedies to deal with issues. If they arise.)

Jari

---

From: John Curran <[email-masked]>
Date: Tue, 15 Jul 2014 10:02:36 -0400

> to avoid conflicting provisions. </ianal>

Also, in a model absent NTIA contract, there would be nothing to conflict...

> ICANN takes bad decisions about TLD policy, they can be set back on

Hmm... "bad decisions about TLD policy" can be a very subjective topic.

It might be worth thinking about two distinct situations:

 - Situations where the contracted IANA party fails to follow the published
   guidance provided by the IETF (or a delegated authority) in administration
   of a given registry.  Some of this appears to be already well-addressed   
   in section 4.1/4.2 of RFC 2860 (and why public registry visibility, 
   reporting and SLA's are all quite useful...)

 - Situations where a delegated policy authority for a registry (e.g. one 
   of the general purpose subsets of the DNS root or IP spaces) should 
   chronically fail to represent the affected registry user community via 
   policy development done in an open, inclusive and transparent manner... 
   (i.e. in accordance with sections 3 & 4 of the IANA framework doc 
   <http://tools.ietf.org/html/draft-iab-iana-framework-02>)  Ideally,
   one would make the accountability to be very clearly stated to be
   performance against specific principles, and periodic assessment of 
   same, since anything else risks creating a mechanism which could be 
   inundated with individual appeals of policy development decisions, 
   rather than the actual question of whether the delegated policy 
   development body is following the IETF's expected IANA principles.

/John

Disclaimer: My views alone. This email message is provided "as-is", with no 
warranty expressed or implied.  Please use your own judgement when building 
global Internet coordination systems.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Jul 2014 10:20:48 -0400

> possibility of switching to someone else.

As something about which the IAB could properly have an opinion, what
is the possibility that the protocol parameters registry could shift
somewhere else?  (There are similar questions for domain names and for
numbers, of course, but those are problems that need to be worked out
in other communities, not here.  If you have opinions about those
topics, I urge you to take them to the relevant forums in the relevant
communities.)

I think the possibility that the IETF could change the provider for
the protocol parameters registry is pretty high, but the way we might
pay for that change is perhaps unclear.  That is, it's nice of ICANN
to provide us this service for free right now, and it's also really
great that they do a good, satisfying job.  If that should cease to be
the case, of course, the IAB could inform ICANN that we were making a
change, and then we could just start publishing the data on a
different set of web pages published somewhere else.  Since the IETF
is the change control authority for the data in the IANA registries,
there isn't (nominally) anyone else who could disagree with that
conclusion.  This has been the IETF and IAB position all along, and at
the igovupdate BoF in London we heard the Chair of the ICANN Board say
quite the same thing.  So, I don't think there's any real issue there.

The question is, how would we pay for the maintenance of such a
system?  Right now, we get this service at no cost to ourselves.  So
there might be a question of practical possibility.  But that seems to
me actually to be a question that we could just ask the IAOC.
Something like this: "For three scenarios -- of increasing, flat, and
declining revenues -- how would we pay for the IANA function if we had
to, and what might we have to give up?"  It seems that a budget
somewhere close to maintaining the tools systems or perhaps the RFC
Editor function would be a reasonable approximation for these
purposes, but I'm open to argument about why or why not.

Best regards,
A

-- 
Andrew Sullivan
[email-masked]

---

From: John Curran <[email-masked]>
Date: Tue, 15 Jul 2014 10:24:34 -0400

On Jul 12, 2014, at 10:05 PM, Miles Fidelman <[email-masked]> wrote:
> 
> Well, the RFC's specfically exclude domain and address functions, ...

RFC 2860 does not exclude domain and address functions - please read it again 
carefully. 

Section 4.1 says that the IANA will assign and register Internet protocol 
parameters per technical considerations specified by the IETF; section 4.3 
notes that two particular assigned spaces present "policy issues" in addition 
to the technical considerations, and places those "policy issues" outside the 
scope of the MOU.  It goes on further to note that ICANN needs to take care 
not to make conflicts with technical reservations within those same assigned 
spaces. 

Placing "policy issues" outside of the MOU space does not exclude the duty
of the IANA to maintain these registries; it is simply a recognition that 
there are delegations of policy authority for the general purpose portions
of these spaces to other parties (e.g. for IP spaces, it's in RFC 7020 and 
RFC 7249)

Remember, there is only one DNS root zone (registry) and one IPv4 space and 
one IPv6 space... each of these registry spaces consist of both technical/
specialized entries and "general purpose" entries, but in the end each space 
must have single consistent registry published containing all entries.  This
is particularly important when dealing with non-trivial publications protocols
such as DNSSEC.

Thanks,
/John

Disclaimer: My views alone.

---

From: John Curran <[email-masked]>
Date: Tue, 15 Jul 2014 10:44:56 -0400

> 3. IETF's role is defined in the MOU, but seems to be in addition to, and/or enabled by the DOC-ICANN contract.

Oh please...

Thought-exercise: If the IETF were to specify a entirely new naming protocol
or new Internet address protocol (including a new associated registry space),
the protocol specification by the IETF would, upon adoption of the appropriate
IANA Considerations section, cause a registry to come into being.  On day one,
the policy authority for that registry would be the IAB, with the IANA doing 
whatever form of administration was specified in the considerations section.

Now one would hope that if the IETF created a general-purpose registry space
(where pieces where to be eventually assigned to real-world entities rather 
than simply code points) that it would leverage existing organizations which 
strive to represent the affected user communities (e.g. ICANN, RIRs) but such 
delegation is _not_ inevitable.

The registry spaces are _created_ as a result of IETF's adoption of a protocol 
specification, and IETF wisely realizes it should provide for administration 
of same (hence the IANA).   It's probably not worth dwelling on this for the 
existing DNS, IPv4, and IPv6 address spaces, but the IETF's role is fundamental 
to the existence of these registries themselves, and not "in addition to, and/or 
enabled by" NTIA-DoC, ICANN, or any other party.

/John

Disclaimer: My view alone.

---

From: JFC Morfin <[email-masked]>
Date: Tue, 15 Jul 2014 18:40:38 +0200

John,

why to repeat the same error ad nauseam? In the hope it becomes true 
(it would then be a lie)? Or in order to eventually upset the other 
stakeholders and disrupt any conciliatory process. All of us know 
they are 40.000 possible roots (ICANN could claim all of them?) and 
256 per user, i.e a trillion of them. This is a basic fundamental 
element every serious multistakeholder must consider if they want we 
concur on an internet governance paradigm.

Talking of paradigm. One also must take into consideration RFC 6852 
in which most of the stakeholders involved in Internet 
standardization process explains that the internet "huge bounty" for 
the world results from a modern paradigm for standards they solemnly 
embrace. In this paradigm the economics of global markets, fueled by 
technological advancements, drive global deployment of standards 
***regardless of their formal status***.and contribute to the 
creation of ***global communities, benefiting humanity***

What an odd approach to read this as leading in the end at "each 
space must have single consistent registry published containing all 
entries" outside of any inter-community agreement.

Let be frank, an ICANN-IETF agreement will solve nothing as long as 
it is not a global agreement, global meaning here both worldwide, on 
every involved matter, and by every stakeholder (and every VGN is a 
stakeholder). Trying to pursue the ICANN scope in the way it is 
currently designed will only spur the fragmentation of the Internet 
into "global communities, benefiting humanity" and multiply them by 
nations, languages, trades, political lines, commercial interests 
instead of helping their compatibility.

Unless, obviously, unless your strategy is to reach a situation of 
self-organized criticality because you have in mind a self-organized 
criticality control scheme 
(http://en.wikipedia.org/wiki/Self-organized_criticality_control). In 
such a case please have a look at the "complex network" link in there 
(in relation to RFC 3439). As you know my own scheme is VGNs. 
However, I do not know which level of disruption will be necessary 
for it to self-apply.

jfc

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Jul 2014 12:50:54 -0400

On Tue, Jul 15, 2014 at 06:40:38PM +0200, JFC Morfin wrote:
> >Remember, there is only one DNS root zone (registry) 

> why to repeat the same error ad nauseam? 

I presume you meant the one quoted above.  If so, it's because it's
technically true, not an error.  I have explained why several times,
but the key thing to repeat to yourself is, "CNAME."

Of course, anyone _can_ have their own picture of a root.  People do
this effectively every time they run a split horizon.  But split
horizons cause all kinds of trouble, and increase user confusion, and
therefore cost real money in the form of support calls.  The IAB has
talked about this already.  "Single root" is not a political position,
it's a fact of mathematics.  It's just a distraction to talk about
multiple roots.  I'd ask that we not investigate that pointless
rathole (again) on this list.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John Curran <[email-masked]>
Date: Tue, 15 Jul 2014 12:58:37 -0400

On Jul 15, 2014, at 12:40 PM, JFC Morfin <[email-masked]> wrote:
> What an odd approach to read this as leading in the end at "each space must have single consistent registry published containing all entries" outside of any inter-community agreement.

JFC - We've been here before... My reference (to a single consistent registry
for each space) is with respect to the specific community of users who happen 
to find value in the identifier coordination provided by the "default" registries 
administered by the IANA at behest of the IETF.  Clearly, other communities
can use whatever coordination mechanisms and values they choose (with obvious
interoperability implications for communications between communities...)

I expect most of the readers of this list are interested in the coordination
resulting from these singular IANA registries, as opposed to the frameworks 
for multiple instances of registries with self-organizing communities (but I
easily could be mistaken.)

Thanks!
/John

Disclaimers: My views alone.

---

From: Eric Burger <[email-masked]>
Date: Tue, 15 Jul 2014 13:33:26 -0400

If the proposal is to have gobs of new registries, that’s a bad idea. Been there and luckily not too much bad happened, but one can envision how lots of badness can happen in the future.

However, if the proposal is to have gobs of redundant, distributed, cryptographically secure (meaning compromise is obvious) of an allocation data base, that is an excellent idea. BitCoin works without a centralized data base, so we have existence proofs, too. I vaguely recall something about “working code” and the IETF…

That could work for IP address allocation, which would admittedly be a less than ideal situation for the RIR’s businesses. For this scheme to work for the parameters directory, we would need a technology such that only the IETF Trust (as holder of the copyright) could update it. I really do not see it working for the DNS root zone, because what goes in, and what does not go in, is a matter of politics, not a matter of a sufficient number of uncompromised nodes agreeing on what a value is.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 15 Jul 2014 10:31:19 -0700

Hi Andrew,
>quite the same thing.  So, I don't think there's any real issue there.

There are eleven other groups represented in the discussions.  The 
ICANN Board is not part of those groups.  If there isn't anyone who 
would disagree with that conclusion it may help if that position 
could be expressed publicly.  The IETF could then have its (internal) 
discussion about the questions in your message and the other messages 
posted to this mailing list.

Regards,
S. Moonesamy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Jul 2014 13:51:37 -0400

> that one has to protect ICANN's assets.

All of which is the reason I keep suggesting a split in the IANA
responsibilities.

The whole problem of Internet governance is that there are a small number
of functions that either have a 'one ring to rule them all' quality to them
or people imagine that they do (which is just as much a problem).

We do not need oversight of IANA.

What we need is oversight of a small subset of IANA functions. Less than 5%
of the whole.

The protocol registries are not a control point. At the application layer
the Internet has got on fine without an SRV prefix registry for over a
decade. Having a registry is better and makes things a lot easier but many
unofficial registries stepped into the role of avoiding collisions when it
was needed.

Its the assignments that go out to external organizations that are the
problem. That is the only area where the problem of ICANN or IANA playing
favorites can come up. At the moment there are the following areas:

IPv4 allocations (exhausted)

IPv6 allocations (might become necessary but should never become an
essential concern in our lifetimes as the RIRs can reduce the increments
they allocate)

AS numbers (could become an issue but not very likely to, it is in any case
desirable to limit supply unnecessarily as this imposes costs on routers.)

X.500 OID arc allocations to organizations (a convenience function only
that could easily be met by others.)

Those are the only areas where 'oversight' is necessary in the IANA
functions. In all other areas the consequence of IANA refusing to issue a
validly approved registration would be that the IANA registry would be
bypassed and a new registry emerge.

The biggest problem with IANA registrations today is when they don't
actually get requested. As in the recent April Fools RFC that assigned an
OID on the PKIX arc but didn't register it. And that is hardly an IANA
issue.

---

From: John Curran <[email-masked]>
Date: Tue, 15 Jul 2014 13:52:54 -0400

> That could work for IP address allocation, which would admittedly be a less than ideal situation for the RIR’s businesses. For this scheme to work for the parameters directory, we would need a tech…

There's no reason for the IETF shouldn't explore new and innovative
mechanisms for identifier coordination, as long as the resulting 
identifiers are useful to the affected community (remember that one 
side effect of the current mechanisms is some degree of routing 
aggregation for routine cases.)  If a better mechanism comes along, 
the affected community is very likely figure out how to fund it 
one way or the other.

(However, I think much of the present IANA Stewardship discussion 
should be focused on how to keep the current IANA model running in 
a proposed post-NTIA world, since there's quite a bit of real-world
reliance on it today)

/John

---

From: Steve Crocker <[email-masked]>
Date: Tue, 15 Jul 2014 13:53:17 -0400

On Jul 15, 2014, at 1:31 PM, S Moonesamy <[email-masked]> wrote:

> There are eleven other groups represented in the discussions.  The ICANN Board is not part of those groups.  If there isn't anyone who would disagree with that conclusion it may help if that position could be expressed publicly.  The IETF could then have its (internal) discussion about the questions in your message and the other messages posted to this mailing list.

I’ve been watching this thread.  I’m not sure I understand precisely what the issue is, but I’m happy to repeat what I said during the igovupdate BoF in London.

The registries maintained by IANA on behalf of the IETF, viz the port assignments, the PEN assignments and the various protocol parameter registries are under the control of the IETF.  The operative agreements are the ones between the IETF and ICANN.  I believe these are an MoU and an SLA.  If the IETF wished to use some other organization for this service, they can do so.  (I haven’t checked recently, but I suspect there are some words in the agreement about giving notice.)  ICANN does not have any rights to the information in the registries, so the entire corpus can be served by someone else.  That said, ICANN was purpose built to provide the IANA function and we consider it an integral part of our operation.  We fully expect to continue the IANA operation as a service to the community and we are committed to doing so in a manner that meets the needs and expectations of the multiple parties it serves.

Steve Crocker
Chair, ICANN Board of Directors

---

From: David Conrad <[email-masked]>
Date: Tue, 15 Jul 2014 11:01:25 -0700

Hi,

On Jul 15, 2014, at 10:31 AM, S Moonesamy <[email-masked]> wrote:
>> That is, it's nice of ICANN
>> different set of web pages published somewhere else.  

Given the various references (some hardwired?) to IANA.ORG, that might get a bit confusing. Perhaps it might be important to ensure that there be a clear understanding that the IANA.ORG domain name is 'owned' by the IAB/IETF and/or associated with the protocol parameters function?

>> This has been the IETF and IAB position all along, and at
> There are eleven other groups represented in the discussions.  The ICANN Board is not part of those groups.  If there isn't anyone who would disagree with that conclusion it may help if that position could be expressed publicly.  

Well, the position was expressed publicly (it's in the transcript of the igovupdate session).  Perhaps you mean expressed formally in writing?

Regards,
-drc

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 15 Jul 2014 14:46:41 -0400

> a proposed post-NTIA world, since there's quite a bit of real-world

+1, and as a related principle, the groups contributing the pieces of the final proposal to the current ICANN-convened "IANA stewardship transition proposal process" should be looking at all (and only) the changes necessary and sufficient for a robust, reliable post-NTIA IANA. Processes for improvement in the future are important and interesting, but also separate. 

From what I've heard here and in assorted other public meetings and discussion, this is the IAB's and IETF's intention in the ianaplan process. It seems like the right one, as long as the ability is preserved to evolve in the future as needed.

best,
Suzanne
(no hats)

---

From: John Curran <[email-masked]>
Date: Tue, 15 Jul 2014 15:10:05 -0400

On Jul 15, 2014, at 1:53 PM, Steve Crocker <[email-masked]> wrote:

> The registries maintained by IANA on behalf of the IETF, viz the port assignments, the PEN assignments and the various protocol parameter registries are under the control of the IETF.  The operative agreements are the ones between the IETF and ICANN.  I believe these are an MoU and an SLA.  If the IETF wished to use some other organization for this service, they can do so.  (I haven’t checked recently, but I suspect there are some words in the agreement about giving notice.)  ICANN does not have any rights to the information in the registries, so the entire corpus can be served by someone else.  

While I seriously doubt such a change would be prudent from an overall Internet
stability perspective, it is probably a worthwhile thought exercise which would 
help somewhat in understanding the existing relationships between the parties.

Presume (for sake of argument) that we consider the IETF (collectively) to be 
policy authority for the technical "protocol parameter" registries, the RIRs
(collectively) the policy authority for the general-purpose portion of the 
IPv4, IPv6, and ASN spaces, and ICANN as the policy authority for the general-
purpose portion of the DNS root zone.  I say "for sake of argument" because 
everyone has their own view about such authority, origins, constraints, and 
we could probably fill several tomes with alternative theories and structures.

So, proceeding ahead with the respective authorities "as given", what exactly
would be the practical result of the changing the IANA registry operator to 
some other hypothetical party (e.g. "XYZ Corp.")

For the IETF, the "IANA" would be some new team at XYZ, running similar systems
to the existing IANA team for generating and updating various protocol parameter 
tables on IANA.ORG.  If the RIRs are the authority for the general-purpose address 
space, then the not-yet-assigned (e.g. in IPv6) and technical entries in IPv4 and
IPv6 spaces would also be maintained by the "IANA".  The in-addr.arpa and IPv6
zones would need to be generated by this new IANA team.  Requests for new ASN 
or IPv6 blocks from the RIRs would be handled by this team, based on established 
global number resource policy.

An interesting question question would be with respect to administration of global 
DNS policy; one would think this would also be done by the IANA team, but it is 
potentially too integrated with the policy development body (ICANN) to now be 
discernible as an actual distinct function. It might instead require that "IANA" 
feed its information on the specialized and technical portions of the DNS to be 
integrated into a single space and published by ICANN (i.e. we've had the policy 
authority, policy development, policy administration, and publication together 
for so long that they are effectively integrated, as opposed to the original
ICANN model where ICANN was to be simply the accountability/oversight body for 
the Internet identifier system as well as the IANA record-keeper, but as opposed
to having primary policy development responsibilities as well.

> That said, ICANN was purpose built to provide the IANA function and we consider it an integral part of our operation.  We fully expect to continue the IANA operation as a service to the community and we are committed to doing so in a manner that meets the needs and expectations of the multiple parties it serves.

I believe that it's generally recognized that ICANN does an excellent job 
providing the IANA services, and personally have every hope that it continues 
to serve in that role for a very, very long time.

An interesting exercise to consider alternatives, nonetheless...
/John

---

From: S Moonesamy <[email-masked]>
Date: Tue, 15 Jul 2014 12:09:27 -0700

Hi David,
At 11:01 15-07-2014, David Conrad wrote:
>Given the various references (some hardwired?) to IANA.ORG, that 
>might get a bit confusing. Perhaps it might be important to ensure 
>that there be a clear understanding that the IANA.ORG domain name is 
>'owned' by the IAB/IETF and/or associated with the protocol 
>parameters function?

I have been thinking about the domain name.  I think that IANA.ORG is 
not an IETF asset.  The association of the protocol parameters 
function with the domain name could be a headache.  My guess would be 
not to deal with that now.

>Well, the position was expressed publicly (it's in the transcript of 
>the igovupdate session).  Perhaps you mean expressed formally in writing?

I'll explain that in my response to Dr Crocker instead of here to 
keep that in one message.

Regards,
S. Moonesamy

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Jul 2014 21:19:59 +0200

>From my perspective, yes.  There has been no credible alternative
proposed, and we have repeatedly all acknowledged that at least as far
as the protocol parameters are concerned, there have been no credible
complaints in the recent past.  Quite the opposite.  And what's more,
most of the discussion here has all been about how to go about keeping
things in a good state.  That is not to say there isn't room for
improvement in some areas, but the existing processes allow for that
improvement to take place.

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 15 Jul 2014 15:31:18 -0400

On Tue, Jul 15, 2014 at 11:01:25AM -0700, David Conrad wrote:
> 
> Given the various references (some hardwired?) to IANA.ORG, that might get a bit confusing. 

If we split the different IANA functions apart (as the idea of the
IETF going elsewhere with its protocol parameters implies), the name
"IANA" would presumably be wrong, so maybe we couldn't stick with
iana.org anyway.  Anyway, whatever happens it'd be part of the cost of
"changing providers".

Just to be clear, in my opinion the idea of splitting the IANA
function is in general a bad one.  In some important senses, IP
addresses and domain names are just different parameters of protocols
anyway.  They each happen to have detailed policy implications that
gives good reason to split the policy functions for them away from
other protocol parameters.  There's also the fact of close
co-ordination needed when special-purpose registries get updated
(particularly when they're overlapping, like parts of the IP space and
some TLDs); it's much easier to ensure that co-ordination with smaller
numbers of people needing to be involved.  Therefore, I believe that
any possible advantage would have to be pretty huge in order to cause
us to split off -- something along the lines of dealing with willful
divergence that couldn't be remedied.  For example, suppose IANA added
something to a registry in express contradiction to the IETF's
instructions.  Note that this might not be an IANA choice.  Given
ICANN's numerous office presences, I can certainly imagine a
circumstance where some court with jurisdiction over ICANN but not the
IETF ordered the "wrong" outcome.

So, I think we need to have a good idea of what we'd have to do, what
it'd cost us, and so on.  That's just responsible contingency
planning.  But we should not be supposing that the effort would be
cheap or easy or in any way a happy outcome.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Jul 2014 12:31:55 -0700

On 7/15/2014 12:31 PM, Andrew Sullivan wrote:
> planning. 

Exactly.

d/

---

From: S Moonesamy <[email-masked]>
Date: Tue, 15 Jul 2014 15:01:45 -0700

Dear Dr Crocker,
At 10:53 15-07-2014, Steve Crocker wrote:
>I've been watching this thread.  I'm not sure I understand precisely 
>what the issue is, but I'm happy to repeat what I said during the 
>igovupdate BoF in London.

Thank you for being clear about the position of the ICANN Board of 
Directors.  I should have made it clear that it is not an 
issue.  I'll explain.  Quoting the IETF Chair (out of context):

  "The coordination group is likely to be ultimately responsible for
   delivering a combined transition proposal to NTIA ..."

In my opinion it would bring some clarity, and maybe some progress, 
if there is some agreement about a topic which is not considered as 
an issue that the coordination group would have to look into.  The 
IETF has a documented position about the Protocol Parameter 
Registry.  Speaking for myself, I do not see any disagreement between 
the position of the ICANN Board of Directors and the IETF 
position.  I don't know the position of the groups which are part of 
the coordination group.  I could presume that it is similar to the 
position of the ICANN Board of Directors.  In this case I think that 
it is better to ask.  I used the word "publicly" as I think that it 
is better to keep things transparent.

Regards,
S. Moonesamy

---

From: JFC Morfin <[email-masked]>
Date: Wed, 16 Jul 2014 00:48:07 +0200

>easily could be mistaken.)

Dear John,

you are most probably mistaken. However this your opinion vs. mine. 
The issue is that ICANN is only one of the potential 40.000 ledgers 
(registry of registries) admitted by the DNS, and has no experience 
about such a situation of competition (it should have fostered). When 
you discover yourself 40.000 possible competitors and in addition a 
trillon of independent alternatives, you can hardly organize yourself 
as a monopoly.

ICANN has to present to the NTIA a credible description of its 
project to match a deregulation process where regular competition is 
introduced. No real difference with the 1977/1987 period. The 
question is how the incumbent is to manage its relations with the new 
comers and welcome them.

This question is going to be discussed by 192 other States, by the US 
Congress, by DSPs (digital services providers) all over the planet, 
by users all over the world. The answer will be by 193 digital 
services, privacy, revenue tax legislations around the world.

If you wish IETF/IAB to limit their considerations to the US VGN, let 
be it. But do not be surprised that the 192 other countries consider 
the IETF/IAB as US standardization consulting bodies, read ICP-3, and 
ask ITU to put some order into what is becoming a commercial (cf. RFC 
6852) as a multi-"global community beniffiting humanity" fragmented 
economic system.

jfc

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 15 Jul 2014 16:27:28 -0700

On 7/15/14 12:10 PM, John Curran wrote:
> stability perspective ...

See below.

> tables on IANA.ORG.

When Pinkus Warburg did the management buyout of the North American 
Numbering Plan Administrator business unit from Lockheed Martin in 1999 
everything remained the same -- office space, management, and hardly 
surprisingly, the NANPA Function, mandated in the Telecommunications Act 
of 1996. (Yes, the L-M office space was dowdy.)

This is "below." The Chicago NPAC did not go down, nor did the overall 
circuit switching system (in +1 only) become unstable in 1999, though 
its ownership changed.

Eric

---

From: John Curran <[email-masked]>
Date: Tue, 15 Jul 2014 19:59:19 -0400

>> stability perspective ...

Actually, there are much more relevant transitions that have already been
successfully accomplished for various portions of this space [SRI->GSI/NSI,
NSI->ARIN, DDN/ISI->ICANN, ARIN->ICANN], and yes, the Internet continued
throughout.  The fact that we can transition providers for these services
still does not mean we should do so without good cause.

FYI,
/John