Subject: Re: [Ianaplan] draft-ietf-ianaplan-icg-response-02 working group last call

From: "Richard Hill" <[email-masked]>
Date: Sat, 1 Nov 2014 10:10:08 +0100

Please see below,

Thanks and best,
Richard

> -----Original Message-----
> From: Ianaplan [mailto:[email-masked]]On Behalf Of Alissa
> Cooper
> Sent: samedi, 1. novembre 2014 01:12
> To: Marc Blanchet
> Cc: [email-masked]
> Subject: Re: [Ianaplan] draft-ietf-ianaplan-icg-response-02 working
> group last call
>
>
> I’d like to pick up on one comment I made in my last review of
> the document that did not get sufficiently addressed. It concerns
> this text:
>
> "To address concerns regarding appropriate contingencies to transition
>    to another operator, the IAOC is asked to conclude a supplemental
>    agreement that-
>   ...
>
>    2.  requires the transfer of any associated marks and identifiers to
>        subsequent operators."
>
> My problem with this is that one mark cannot be transferred to
> two operators.

Any type of property, including intellectual property such as copyrights and
trademarks, can be jointly owned by two or more legal entities (physical
persons and/or legal persons).

Of course the "two operators"  would have to sort out and agree how they
would share the mark in question, but that is their problem.

>So if we end up in a situation where there are
> multiple IANA operators for different registries, how will it be
> decided who gets the existing marks?

As mentioned above, the multiple operators would have to agree amongst
themselves.

>If I were the current owner
> of such marks, I don’t see how I could agree to this provision
> without foreclosing the possibility that there may be multiple
> simultaneous operators in the future.

I don't agree.  It just makes a future transition somewhat more complicated,
because the "multiple simultaneous operators" would have to agree how to
handle the situation.

>This is why I think this
> requirement should be stated as requiring “cooperation with
> subsequent operators to minimize confusion" associated with marks
> and identifiers, or some similar language that provides a
> safeguard in the event of transition but does not mandate
> specific transfer actions related to marks and identifiers.

You seem to be reopening this issue.

A simple solution, which had been suggested, is that the mark and domain
name be transferred to the IETF Trust, which surely could be relied upon to
allow them to be used appropriately by whoever (one or more entities)
provides the IANA function now or in the future.

I'm OK with Eliot's compromise language in "02".  If people think that that
results in a situation that is too complex, then I suggest that we adopt the
simple solution outlined above.

I'd be happy to propose specific language if it is agreed that we do down
that path.

>
> I also still find it quite problematic that this section requires
> the IAOC to conclude supplemental agreements, instead of
> maintaining the existing relationship that the IETF has with the
> IAOC wherein it is the IAOC’s responsibility to determine the
> format in which is carries out its responsibilities on behalf of the IETF.

I find that the language in "02" is not as clear and definitive as I would
have liked it to be, but I'm OK with that language.  But I would likely not
be OK with anything weaker.

>
> Alissa
>
> On Oct 28, 2014, at 7:42 AM, Marc Blanchet
> <[email-masked]> wrote:
>
> > Hello,
> > given the proposed timeline agreed during our last interim
> meeting and based on that the outstanding issues should have been
> addressed in the -02 version, this message starts a working group
> last call on draft-ietf-ianaplan-icg-response-02.  This working
> group last call will end november 11, 23h59 UTC. Given that our
> meeting is scheduled on november 10th, it would be useful if
> people send their comments prior to the meeting so they can be
> addressed or discussed before or during the meeting.
> >
> > Draft: http://www.ietf.org/id/draft-ietf-ianaplan-icg-response-02.txt
> >
> > Please send comments to the list.
> >
> > Regards, Marc&Leslie, co-chairs.
> > _______________________________________________
> > Ianaplan mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ianaplan
>
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 01 Nov 2014 10:41:34 +0000

Alissa's point goes a little beyond my comment on the same
text, but having read this, I share her concerns.

S

On 01/11/14 00:11, Alissa Cooper wrote:
> I’d like to pick up on one comment I made in my last review of the
> document that did not get sufficiently addressed. It concerns this
> text:
> 
> "To address concerns regarding appropriate contingencies to
> transition to another operator, the IAOC is asked to conclude a
> supplemental agreement that- ...
> 
> My problem with this is that one mark cannot be transferred to two
> operators. So if we end up in a situation where there are multiple
> IANA operators for different registries, how will it be decided who
> gets the existing marks? If I were the current owner of such marks, I
> don’t see how I could agree to this provision without foreclosing the
> possibility that there may be multiple simultaneous operators in the
> future. This is why I think this requirement should be stated as
> requiring “cooperation with subsequent operators to minimize
> confusion" associated with marks and identifiers, or some similar
> language that provides a safeguard in the event of transition but
> does not mandate specific transfer actions related to marks and
> identifiers.
> 
> I also still find it quite problematic that this section requires the
> IAOC to conclude supplemental agreements, instead of maintaining the
> existing relationship that the IETF has with the IAOC wherein it is
> the IAOC’s responsibility to determine the format in which is carries
> out its responsibilities on behalf of the IETF.
> 
> Alissa
> 
>> Hello, given the proposed timeline agreed during our last interim
>> meeting is scheduled on november 10th, it would be useful if people
>> send their comments prior to the meeting so they can be addressed
>> or discussed before or during the meeting.
>> 
>> Draft:
>> http://www.ietf.org/id/draft-ietf-ianaplan-icg-response-02.txt
>> 
>> _______________________________________________ Ianaplan mailing
>> list [email-masked] 
> _______________________________________________ Ianaplan mailing
> list [email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 02 Nov 2014 04:57:40 +0900

For the record, I read "transfer ... to subsequent operators" as 
transfer in temporal succession. So e.g. transfer to operator A ten 
years down the line, and then to operator B maybe twenty years down the 
line.

Of course it can also be read the way Alissa read it, so it should be 
clarified or changed, maybe along the lines that Richard suggests below.

Regards,   Martin.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 2 Nov 2014 08:16:16 -0800

I agree as well. 

> On Nov 1, 2014, at 3:41 AM, Stephen Farrell <[email-masked]> wrote:
> 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 3 Nov 2014 16:19:39 +0000

Agreed. "Cooperation with subsequent operators to minimize confusion"
gives us enough wiggle-room to be able to manage some likely transition
situations. The prior language probably doesn't.

Jon Peterson
Neustar, Inc.

On 11/2/14, 7:16 AM, "Bernard Aboba" <[email-masked]> wrote:

>>> I¹d like to pick up on one comment I made in my last review of the
>>> don¹t see how I could agree to this provision without foreclosing the
>>> requiring ³cooperation with subsequent operators to minimize
>>> the IAOC¹s responsibility to determine the format in which is carries

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 3 Nov 2014 18:23:28 +0100

Sorry, I don't agree with that.  That language is too vague for me.

If people are not comfortable with the language that is currently in 02,
then I suggest that we develop language to the effect that the intellectual
property rights and the domain name IANA.ORG will be transferred to the ISOC
Trust (or whatever part of ISOC is the appropriate entity to receive it).

In my view, the mark, and the domain name, belong to ISOC morally, if not
legally and, as I said before, I'm sure that everybody would agree that ISOC
will allow whatever entity or entities are providing the IANA function to
use the mark and the domain name.

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Peterson,
> Jon
> Sent: lundi, 3. novembre 2014 17:20
> To: Bernard Aboba; Stephen Farrell
> Cc: Marc Blanchet; Alissa Cooper; [email-masked]

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 03 Nov 2014 12:37:47 -0500

+1

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

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Nov 2014 13:09:24 -0500

> Trust (or whatever part of ISOC is the appropriate entity to receive it).

I think that idea is completely unworkable, and I strongly oppose
adding such language to the draft.

> legally and

Certainly not legally, and I don't understand the "moral" argument
either.  ISOC has never itself performed the IANA function.  Why does
ISOC have a better claim than the organization that has been providing
the service for more than 10 years?

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 3 Nov 2014 19:14:19 +0100

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Andrew
> Sullivan
> Sent: lundi, 3. novembre 2014 19:09
> To: [email-masked]

SNIP

> the service for more than 10 years?

Because the function had been provided by Jon Postel for many years prior to
that pursuant to various RFCs.  John did that under contract from the US
government, as an employee (or whatever) of various organizations.

Legally, that has nothing to do with ISOC.  But, to me, it has everything to
do with the Internet technical community and the IETF.  And ISOC is the
legal parent of the IETF.

So, since the IANA function was originally an emanation of the IETF, I think
that the associated intellectual property rights ought to be associated with
ISOC, the legal parent of the IETF.

---

From: Olivier MJ Crepin-Leblond <[email-masked]>
Date: Mon, 03 Nov 2014 19:19:34 +0100

> use the mark and the domain name.

...and thus was the can of worms opened. I disagree with entering the
field of property rights wrt IANA itself. Next we'll add that "Internet"
is a Trademark of DARPA. This is not constructive.
Kind regards,

Olivier

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Nov 2014 13:30:07 -0500

On Mon, Nov 03, 2014 at 07:14:19PM +0100, Richard Hill wrote:
> So, since the IANA function was originally an emanation of the IETF

No, it was not.  It was an emanation of someone to whom various
interested parties deferred.  The IETF didn't exist yet, at least in
the form it subsequently took.

In general, I think foundational arguments in this area are likely to
get us into a dark and very wet swamp.  It seems to me that we need to
concentrate on what outcome we want ("stuff stays the same"), and what
to do in case things fall apart.  "Stay the same" requires, as far as
I can tell, that we not try to negotiate for things we're unlikely to
get, because once you start negotiating you have to decide what things
you're willing to give up, and I think we don't want to give things up
because we like the way things are.  This means we need a different
plan for what to do in case things fall apart.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Mon, 03 Nov 2014 10:35:31 -0800

On 11/3/2014 10:30 AM, Andrew Sullivan wrote:
> It seems to me that we need to
> to do in case things fall apart. 

+10.0

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 3 Nov 2014 21:30:28 +0100

Please see below.

Thanks and best,
Richard

> Sent: lundi, 3. novembre 2014 19:30
> To: [email-masked]

The IETF was created in 1986, see:

  http://www.ietf.org/glossary.html#IETF

I already referred to the early history of the IANA function in a previous
E-Mail, see:

  http://www.ietf.org/mail-archive/web/ianaplan/current/msg00570.html

As that E-Mail says, the  first formal reference to "IANA" seems to be in
RFC 1060, of 1990.

So the IANA function was an emanation of the IETF.

> concentrate on what outcome we want ("stuff stays the same"),

Yes.  But we differ on what "staying the same" means.

To me, it means that ICANN should not have unfettered control of the mark
IANA and the domain name IANA.ORG.

> and what

Exactly.  Trying to negotiate with ICANN if things do fall apart is going to
be messy.  Anybody who has gone through a divorce, or has friends who have
gone through divorces, should understand what I'm referring to.

>"Stay the same" requires, as far as
> get,

Why do you assume that?  As Milton has pointed out, ICANN is bound to
implement whatever the consenus is of the global multi-stakeholder
community.  So there won't be  negotiation between ICANN and whoever.  ICANN
will do whatever the consensus plan presented by the ICG says it should do.

>because once you start negotiating you have to decide what things
> because we like the way things are.

You've lost me.  I can't see any scenario under which there is anything to
negotiate, see above.

> This means we need a different

Why not keep it simple, and transfer the mark and the domain name IANA.ORG
to the IETF Trust?

---

From: Dave Crocker <[email-masked]>
Date: Mon, 03 Nov 2014 12:57:15 -0800

As Andrew notes, this has nothing to do with current concerns, so I've
changed the Subject.

On 11/3/2014 12:30 PM, Richard Hill wrote:
>> interested parties deferred. 
...
> So the IANA function was an emanation of the IETF.

This confuses nomenclature with function.  In this case, the
nomenclature came long after the function had been in continuous operation.

The Wikipedia entry on IANA's history matches my understanding of things
-- which matches what I usually hear others from that early timeframe cite:

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

 -- and it notes that the /function/ dates back to the early 70s. This
also matches IANA's own reporting of its history:

https://www.iana.org/about/presentations/davies-berlin-domainpulse-060208.pdf

> Yes.  But we differ on what "staying the same" means.

Independent of an origins debate, we have had a stable operation of
IETF/ICANN/IANA/USG for something like 17 years.  That provides a pretty
reasonable baseline for assessing what it means to have things "stay the
same".

This, of course, is entirely distinct from determining what constitutes
reasonable components of the next agreement with ICANN...

One would think that removal of the USG from the equation would be
considered as a significant environmental change.

d/

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Nov 2014 16:28:31 -0500

> IANA and the domain name IANA.ORG.

So, that's the "different" meaning of "same"?  They have control of
those items now, and they got it as part of the arrangement that
created the NTIA agreement in the first place.  Stamping our foot
about moral authority (particularly when it's as dubious as this)
isn't a strong bargaining position.
 
> gone through divorces, should understand what I'm referring to.

As I've argued repeatedly, in case of separation of the various IANA
portions from one another, the cases boil down to two: either we have
a co-operative separation (in which case, there'll be a pointer
installed immediately to wherever the new registry is), or we have a
hostile situation (in which case, no amount of agreement in advance
will help, because everything will be contested and we'll have to act
much faster than any legal process will permit).  

If people are genuinely worried about this problem, then the right
thing to do is not to try to get control of "IANA".  As Alissa keeps
saying, we still can't split a mark three ways.  Therefore, if we are
really concerned about arranging for that, we should create a separate
mark and domain name now.  We should start using the new name instead
of "IANA" in the newly-minted "Protocol Parameter Registry
Considerations" section.  We should publish another document that
says, "IANA now renamed NEWREG for protocol parameters", thereby
telling everyone that they can read "NEWREG" for "IANA" in all old
documents wherever a parameter is called out.  And we can point the
"NEWREG" site to the IANA site (probably by judicious use of a DNAME),
thereby preserving operation exactly as it currently functions. 

Again, I think it is entirely premature and foolish to do that now.
It would send exactly the wrong message when it is obviously better
that the various functions stay together and in the incumbent
operator.  There is effectively zero risk right now that we're going
to exercise this sort of thing in the short term, so we have lots of
time to undertake such a strategy in the future should there appear to
be any chance at all that we might need it.

> community.  

I think Milton is wrong about that.  What incentive does ICANN have to
accept a term that it doesn't like if the NTIA says it should do it?
NTIA has already announced its intention to change things.  If the
terms of that change are not to ICANN's liking, then ICANN can do one
of three things: 1. roll over anyway, 2. hold out and see if NTIA
blinks, 3. open negotiations with NTIA on extension of the existing
agreement.  It seems to me that (1) is unlikely and (3) is not what we
want.  (2) is unappealing, so we should avoid creating situations that
could cause that when there's not a significant upside for us.  
 
> Why not keep it simple, and transfer the mark and the domain name IANA.ORG

I don't believe that's simple at all.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 3 Nov 2014 22:54:05 +0100

> Sent: lundi, 3. novembre 2014 22:29
> To: [email-masked]
> Subject: [Ianaplan] control and negotiation (was Re:
> draft-ietf-ianaplan-icg-response-02 working group last call)
>
>
> created the NTIA agreement in the first place.

Yes. And the question now is what to do, given that NTIA is no longer going
to be involved.

>Stamping our foot

As I said before, it's not about bargaining.  ICANN is bound to implement
whatever is in the final proposal that the ICG will transmit to NTIA.

> much faster than any legal process will permit).

No, if the mark and the domain name are transferred to the IETF Trust now,
then there would be no hostile situation regarding the mark and the domain
name, and no legal actions would be rquired.

> saying, we still can't split a mark three ways.

That is not correct.  The IETF Trust (or whoever owns the mark) can license
it to one or more entities.

>Therefore, if we are
> mark and domain name now.

That seems more complicated than transferring the mark to the IETF Trust.

>We should start using the new name instead

No.  ICANN is bound to implement whatever is in the ICG proposal.  It is not
bound to implement what might be asked for after that.

> accept a term that it doesn't like if the NTIA says it should do it?

Because NTIA may decide not to transition the IANA function.  Or to reopen
the contract and consider awarding the contract for the IANA function to
some other entity or set of entities.

> NTIA has already announced its intention to change things.

Yes, on the basis of "an appropriate transition plan".  And we are crafting
one part of that plan.

>If the
> agreement.  It seems to me that (1) is unlikely

Why?  NTIA asked ICANN to prepare a transtion plan.  In turn, ICANN tasked
the ICG to prepare that plan.  So the plan that will be transmitted by the
ICG will be ICANN's plan.

Why would ICANN turn around and tell NTIA, "no that isn't really our plan,
our plan is slightly different"?  What legitimacy would that have?

> and (3) is not what we

Why not?  Because ICANN will say no?  As explained above, that doesn't make
sense to me.  But, as I said before, maybe I'm not sufficiently intelligent
to understand.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 03 Nov 2014 14:03:19 -0800

Hi Andrew,

It seems a good time to review why we are at this point, and what can be
done.

We are seeking what amounts to backward compatibility - that is, things
keep going the way they were, even in the face of an IANA operator
change.  That means, at least to me, that the links that are spread
hither and yon continue to work.

You have stated that you deem it unreasonable to impose post-contract
responsibilities on the current contract holder.  Fair enough.
You and Milton came to what seemed like a reasonable compromise which
was that the next IANA functions operator be transferred the material.
Then Alissa suggested there might need to be more than one, and
therefore, that a mark could not be split three ways.

The fundamental goal is that links continue to work.  I suggest that if
the IETF/IAB or IETF trust takes control of the name, it do so with the
understanding that it take responsibility for seeing that backward
compatibility continue for each customer (names, numbers, protocol
parameters, in particular) for so long as it is safe to do so.  If
someone else wants to take control of the name, they should make that
same promise.

How does that sound to you in principle?

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Nov 2014 17:20:35 -0500

> ICG will be ICANN's plan.

But ICG has to submit something that achieves broad multistakeholder
support.  ICANN is in a position, if we insist on something they don't
like, to bring the whole thing to a halt a the ICG.  If the ICG
overrules and says, "Nope, gonna do it that way," then the NTIA
requirement for Internet community support will be demonstrably
missed.

People who think we get to choose whatever we want, regardless of how
acceptable it is to ICANN, have a different world-view than mine.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 3 Nov 2014 17:26:18 -0500

> How does that sound to you in principle?

My objection to moving the relevant bits to the IETF Trust has never
been one of principle.  It's been one of practicality: I don't see any
incentive whatsoever for ICANN to give up that property without
getting something in return, and I can't think of anything I want to
give up more than iana.org in case there's more than one operator.   

Again, to be clear, I think that would be a very bad outcome.  I don't
think it would be good to have to split the iana.org stuff, and I
think we should avoid it.  But I think it is preposterous to imagine
that ICANN is going to give away an asset just because we want it,
without extracting some concession.  Therefore, it'd be fine to say to
the IAOC, "Please ask for this."  But if they don't get it, what then?

The burden of proof, IMO, is on those who claim that ICANN will simply
have to give up control of that asset.  I've yet to see a good
argument that they will, and I note it is somewhat unusual in the US
for a government department to force a corporation to give up an asset
without any compensation.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Nov 2014 11:43:25 +1300

> give up more than iana.org in case there's more than one operator.

Exactly. An IANA by any other name would smell as sweet. If I have to
change a few bookmarks to registry.ietf.org, I really don't care very
much; that would be the least of my worries if there was a break-up.

   Brian

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 03 Nov 2014 17:43:57 -0500

> without any compensation.

As far as the USG is concerned, ICANN is a contractor - nothing more, 
nothing less.  Generally, unless there are clear exceptions in law, 
regulation, or contract, work performed under contract is the property 
of the contractee (USG), not the contractor (ICANN).

By all rights, IMHO, iana.org should have been registered by either the 
USG, or SRI - back when John Postel was doing the work; and transferred 
to the USG when the work moved - with the USG delegating management to 
ICANN, as part of the contract.  Instead, ICANN unilaterally staked a 
claim to the domain, by registering it.

Yes, possession is nine 10ths of the law - but what we're talking about 
here is an oversight to be rectified, not an overstepping to be ratified.

Why NOT take the opportunity to at least attempt to fix this.  This is 
the best opportunity to do so, and perhaps the last that would not 
involve the potential for hostile litigation at some point down the line.

As to burden of proof re. whether or not ICANN will "simply give up 
control" - well.. seems to me that the best way to find out is to run 
the experiment.  Put it in our proposal, stand fast, and stand fast.  At 
the very least, it puts IETF in a stronger negotiating position for 
getting to compromise language.

Miles Fidelman

---

From: Eliot Lear <[email-masked]>
Date: Mon, 03 Nov 2014 14:45:09 -0800

> give up more than iana.org in case there's more than one operator. 

There are two arguments to be made.  First, and perhaps most
importantly, it's not theirs..  It's the community's, and this is true
on its face.  How can it be said that IANA.ORG is not part and parcel of
the IANA functions? Second we have stated a legitimate requirement for
continuity of service that the NTIA is in a position to make clear is a
requirement; that is part of security and stability of the IANA
functions service.  For ICANN to say "no" would discredit them, given
the first argument.  Nor should they say "no".  It would be bad for
everyone.

As I wrote, I am not wedded, nor was I ever wedded, to the IETF Trust
having to have a role here.  I was satisfied with any successor taking
the name, as you and Milton agreed.  My sole issue is continuity of
service in the face of transition, including backward compatibility.

Finally, I expect that when we publish this document, we are not done. 
Rather there will be discussions about how to meet the legitimate
requirements we have laid out, such that the other parties are
satisfied.  That may require changes to the resulting response.  That is
already built into the ICG's timeline.

Eliot

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 3 Nov 2014 17:12:58 -0800

Hi Eliot,

On Nov 3, 2014, at 2:03 PM, Eliot Lear <[email-masked]> wrote:

>  I suggest that if

This is so close to the language that I suggested that it’s hard for me to tell the difference between what you’re suggesting and what I suggested. To state the above requirement concisely:

"Whoever owns the marks and identifiers has responsibility for ensuring backwards compatibility in the event that IANA operations shift to different entit(ies).”

The requirement is that the owner of the marks/identifiers has to enable a smooth transition of the operations — regardless of whether the marks owner is the same as the operator or different or if there are multiple operators. Because the current owner is ICANN, this requirement would fall on ICANN.

I would be satisfied if we substitute the above requirement in place of the one currently in the draft about the transfer of marks and identifiers. Do I read your email correctly that you would be satisfied as well?

Alissa

---

From: Eliot Lear <[email-masked]>
Date: Mon, 03 Nov 2014 17:15:58 -0800

> I would be satisfied if we substitute the above requirement in place of the one currently in the draft about the transfer of marks and identifiers. Do I read your email correctly that you would be…

Very much so!!

Eliot

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 3 Nov 2014 17:23:39 -0800

Hi Richard,

> would share the mark in question, but that is their problem.

If the whole point of the above requirement is to increase the certainty that transitioning to new operator(s) would be smooth, then the fact that the sharing would have to be sorted out between the parties severely undercuts the rationale for the requirement in the first place. In particular, although none of these possible scenarios are very likely, the most likely ones all involve ICANN continuing to operate some of the functions, IMO. Under that assumption, what you’re saying is that the transition plan must require ICANN to transfer its marks and identifiers to a subsequent operator, but if the situation arises where ICANN were to share the IANA operations responsibilities with another operator, then the transition plan is mute on the topic and the two operators can work things out any way they like. This makes little sense and it strikes me that it puts the protocol parameters in a much worse situation than if the current contractor is obligated to cooperate with subsequent operators to minimize confusion (or ensure backwards compatibility, in Eliot’s words). Either of those standards puts the obligation on ICANN to achieve the desired outcome, rather than to use a particular means which may or may not achieve the desired outcome.

> You seem to be reopening this issue.

There has been no consensus called on this issue, so I don’t see why you would accuse me of “re-opening” an issue that is already open. The amount of list traffic on this topic since Friday demonstrates fairly well that the issue is indeed still open and ripe for debate.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 3 Nov 2014 17:26:54 -0800

Hi Eliot,

>> I would be satisfied if we substitute the above requirement in place of the one currently in the draft about the transfer of marks and identifiers. Do I read your email correctly that you would be…

Cool. So I would suggest something like this:

...

   2.  requires the owner of any associated marks and identifiers to ensure backwards compatibility with subsequent operators.”

Alissa

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 4 Nov 2014 10:18:55 +0100

I think that Eliot's proposal below is excellent.

Best,
Ricard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Eliot Lear
> Sent: lundi, 3. novembre 2014 23:03
> To: Andrew Sullivan; [email-masked]
> Subject: Re: [Ianaplan] control and negotiation (was Re:

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 4 Nov 2014 10:25:28 +0100

> Sent: lundi, 3. novembre 2014 23:21
> To: [email-masked]
> support.  ICANN is in a position,

You've lost me again.  As I understand the situation, NTIA asked ICANN to
convene a process to produce a transition plan.  ICANN chartered the ICG to
do that. The ICG has asked each of the operational communities to produce a
plan for what concerns them.

This group is doing that.  The output of this group will go to ICG, and then
to NTIA.

So, for the purposes of this exercise we *are* ICANN.  Indeed, ICANN is
comprised of its constituencies.

So when you say "ICANN is in a position", I don't understand what you mean.

Do you mean "the ICANN Board", or "the ICANN staff"?  Or something else?

>if we insist on something they don't
> like, to bring the whole thing to a halt a the ICG.

As far as I know, the ICG is an emanation of ICANN, and neither the ICANN
Board nor the ICANN staff are going to tell ICG what to do or not to do.

> If the ICG
> overrules and says, "Nope, gonna do it that way,"

What would the ICG overrule?  Again, the ICG has been chartered by ICANN to
prepare a proposal, and that proposal will not be subject to approval by the
ICANN Board.

>then the NTIA

Indeed, we seem to have rather different world views, because, to me, this
process is ICANN, whereas you seem to think that it is outside ICANN.  Maybe
the difference in views is due to my incipient senility.

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 4 Nov 2014 10:26:09 +0100

Miles has said what I meant to say, but better.

So I support what Miles says.

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Miles
> Fidelman
> Sent: lundi, 3. novembre 2014 23:44
> To: [email-masked]

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 4 Nov 2014 10:26:47 +0100

I fully agree with what Eliot says below.

Best,
Richard

> Sent: lundi, 3. novembre 2014 23:45

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 4 Nov 2014 10:39:13 +0100

> From: Alissa Cooper [mailto:[email-masked]]
> Sent: mardi, 4. novembre 2014 02:24
> To: [email-masked]
> Cc: Marc Blanchet; [email-masked]
> Subject: control and negotiation (was Re:
> If the whole point of the above requirement is to increase the
> certainty that transitioning to new operator(s) would be smooth,
> then the fact that the sharing would have to be sorted out
> between the parties severely undercuts the rationale for the
> requirement in the first place.

That's true.  And that's why I now think that the only sensible solution is
to transfer the mark and the domain name to the IETF Trust (or whatever),
with the condition that the IETF Trust make the mark and the domain name
available, free of charge, to whatever entity or entities provide the IANA
function.

>In particular, although none of
> these possible scenarios are very likely, the most likely ones
> all involve ICANN continuing to operate some of the functions,
> IMO. Under that assumption, what you’re saying is that the
> transition plan must require ICANN to transfer its marks and
> identifiers to a subsequent operator, but if the situation arises
> where ICANN were to share the IANA operations responsibilities
> with another operator, then the transition plan is mute on the
> topic and the two operators can work things out any way they
> like. This makes little sense and it strikes me that it puts the
> protocol parameters in a much worse situation than if the current
> contractor is obligated to cooperate with subsequent operators to
> minimize confusion (or ensure backwards compatibility, in Eliot’s
> words). Either of those standards puts the obligation on ICANN to
> achieve the desired outcome, rather than to use a particular
> means which may or may not achieve the desired outcome.

Yes, so see above regarding a simpler solution, and see below for specific
language.

> There has been no consensus called on this issue, so I don’t see
> why you would accuse me of “re-opening” an issue that is already
> open.

I was under the impression that some agreement had been reached during the
webcast.  I apologize for misunderstanding. And I certainly had no intention
of "accusing": I think that it is perfectly permissible to reopen issues.

>The amount of list traffic on this topic since Friday
> demonstrates fairly well that the issue is indeed still open and
> ripe for debate.

Indeed.  So here is my proposal for actual language, which would replace the
language currently in draft "02"

"2.  results in the transfer of any associated marks and identifiers to the
IETF Trust, with the understanding that current and subsequent operators of
the IANA function shall be allowed to use them free of charge."

For clarity, the full clause would then read:

"To address concerns regarding appropriate contingencies to transition to
another operator, the IAOC is asked to conclude a supplemental agreement
that-

"1.  maintains the IANA functions operator's obligations established under
C.7.3 and I.61 of the current IANA functions contract between ICANN and the
NTIA [NTIA-Contract];

"and

"2.  results in the transfer of any associated marks and identifiers to the
IETF Trust, with the understanding that current and subsequent operators of
the IANA function shall be allowed to use them free of charge."

Best,
Richard

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 4 Nov 2014 10:46:40 +0100

Thank you for this, but I still prefer the language that I proposed in my
previous message, that is:

Best,
Richard

> Sent: mardi, 4. novembre 2014 02:27
> To: Eliot Lear
> Cc: [email-masked]; Andrew Sullivan
> >> This is so close to the language that I suggested that it’s
> hard for me to tell the difference between what you’re suggesting
> and what I suggested. To state the above requirement concisely:
> >>
> >> "Whoever owns the marks and identifiers has responsibility for
> ensuring backwards compatibility in the event that IANA
> operations shift to different entit(ies).”
> >>
> >> The requirement is that the owner of the marks/identifiers has
> to enable a smooth transition of the operations — regardless of
> whether the marks owner is the same as the operator or different
> or if there are multiple operators. Because the current owner is
> ICANN, this requirement would fall on ICANN.
> >>
> >> I would be satisfied if we substitute the above requirement in
> place of the one currently in the draft about the transfer of
> marks and identifiers. Do I read your email correctly that you
> would be satisfied as well?
> >
> > Very much so!!
>
>    2.  requires the owner of any associated marks and identifiers
> to ensure backwards compatibility with subsequent operators.”
>
> Alissa
>
>
> >
> > Eliot
> >
>

---

From: Jefsey <[email-masked]>
Date: Tue, 04 Nov 2014 12:09:13 +0100

>use the mark and the domain name.

Dear Richard,

In my view the mark, domain name, etc. belong to the Internet Users. 
And I do not trust anything which is non-accountable, i.e. subject to 
a trusted sovereign power having the capability to inforce it at 
national level, and a dominant coalition or the UN at international level.

Now, if it pleases ISOC people's ego to retain iana.org in the "IN" 
ICANN/NTIA class under BCP 78, IUsers have 255 homeroots we can use 
to access the IUANA (http://iuana.org).
Cheers !
jfc

---

From: Jefsey <[email-masked]>
Date: Tue, 04 Nov 2014 12:54:38 +0100

At 19:19 03/11/2014, Olivier MJ Crepin-Leblond wrote:
>is a Trademark of DARPA.

Olivier,

unfortunately under the RFC 2860 Section 4.3. it is not only a 
property of the IETF Trust (ISOC transfered its rights) imposing the 
BCP 78 licence on RFCs, but under the control of the IETF leaders 
(cf. RFC 3935). The members of the Trust are the IAOC (IETF 
Administrative Oversight Committee) members because BCP 101 already 
gives the IASA (IETF Administrative Support Activity) the duty of 
managing the IETF's IPR.

The IETF Trustee, i.e. the true legal active owner of the internet logic are:

    o  Two members appointed by the IETF Nominations Committee (NomCom);
    o  One member appointed by the IESG;
    o  One member appointed by the IAB;
    o  One member appointed by the ISOC Board of Trustees;
    o  The IETF Chair (ex officio);
    o  The IAB Chair (ex officio);
    o  The ISOC President/CEO (ex officio).

Currently they are:
Jari Arkko, Scott Bradner, Randy Bush,Tobias Gondrom (Chair), Chris 
Griffiths, Bob Hinden; Russ Housley, Ray Pelletier,  Kathy Brown

>This is not constructive.

I understand your concern but is it constructive to maintain the 
status-quo on something that worked but which is losing the reason 
why it worked: sovereignty and USCC procurement QA.

How many Aircraft Carriers ICANN?

The question is not only the ICANN accountability it is also its 
operational capacity to enforce its decisions.
jfc

---

From: Jefsey <[email-masked]>
Date: Tue, 04 Nov 2014 12:38:02 +0100

>whatever is in the final proposal that the ICG will transmit to NTIA.

Bound by what?
Once the NTIA is gone, the bound is broken.
jfc

---

From: Jefsey <[email-masked]>
Date: Tue, 04 Nov 2014 12:54:28 +0100

Eliot,

if there is blunt transfer this will result from a clash, probably 
pursued by a standing conflict. Who ever is the owner of the name, 
the name will resolve where the root administrator decides. What 
ICANN is building is the ICANN VGN as an heir of the US VGN. I do not 
know how many users will follow them (I suppose, at least initially, 
a very large number). ICANN duties and survival interests will go (1) 
to its users and (2) to whatever may main retain these users.

This is is why they need to stay in control of names and addresses 
which are operational issues. Protocol parameters are of secondary 
interest as they complete protocols which (1) are not changing and 
being implemented every day and (2) can be obtained elsewhere (as 
authorized by RFC 2860).

This means that if the IETF wants to stay as the immutable core of 
the lower layers of the IP technology it is to support the ICANN VGN 
competition, i.e. root operators supporting their own IANA blend 
(names, addresses from RIRs and ITU, parameters from the various 
packet switeched technologies supported by the various ISPs). unless 
the target is to fragment the digital ecosystem use.

I advise everyone to carefully read the Indian revised motion at PP14 
because this IS what IS going to happen as demanded by States, and 
this is probably a good hint of what the IUsers are going to 
implement. (nb. I use "IS" "ARE" "BE" as we [IUCG] use to do when we 
consider something which is beyond our normative reach).

jfc

---

From: Jefsey <[email-masked]>
Date: Tue, 04 Nov 2014 13:00:59 +0100

At 23:43 03/11/2014, Miles Fidelman wrote:
>As far as the USG is concerned, ICANN is a contractor - nothing 
>more, nothing less.

No. This is what ICANN wants you to think.

1) ICANN is the planned successor for DNS Key functions
2) this being said it considers that the NTIA has to relinquish the 
whole IANA contract so it may control the RIRs before Putin builds his WIR.

If it does not it will file a complaint with the FCC showing how it 
embarasses its DNS key function's owner role and create havoc in the 
address space allocation.
jfc

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 04 Nov 2014 07:21:23 -0500

Agree.  Specificity is as important in contractual language as it is in 
a protocol spec.  Lack of clarity would only prolong conflict (e.g., 
litigation) if this clause ever has to be executed.  I'd go further, and 
explicitly add "including registration of the iana.org domain" to the 
language.

Miles Fidelman

---

From: John Curran <[email-masked]>
Date: Tue, 4 Nov 2014 15:03:51 +0000

> plan for what to do in case things fall apart.

I've been trying to stay out of this particular thread, but feel compelled
to respond to the above in light of how far astray it is from the task 
now underway.

I am not certain that "negotiation" is a constructive way to look at this 
problem space.  The ICG team needs to generate a single proposal to go to 
NTIA, and said proposal should address any issues that might arise with 
the transition of the stewardship for the IANA functions.

If the IETF feels that there are no issues with respect to the IANA marks 
and domain name, then it doesn't need to raise the issue (and as per charter, 
should do the minimum possible and not mention it.)  This presumes that the 
IETF is satisfied with any possible outcome with respect to the marks and 
domain name, i.e. that there is no issue with respect to them during an 
IANA stewardship transition.

If the IETF feels that there is a potential issue with respect to the marks 
and domain name during a stewardship transition from NTIA or with respect to 
any potential future IANA operator transition, then it should be mentioned 
in the IETF submission to the ICG.  If nothing else, the present shared usage 
of the marks and domain should be noted in the response as an existing working 
arrangement under "Section II. Existing, Pre-Transition Arrangements"

If the IETF feels that there is a potential issue, and furthermore that it 
has a preferred solution to that issue, then it should not only mention the 
issue, but note its _preferred_ solution.  That's not an ultimatum, but simply 
an expression of one or more possible solutions to the issue.

None of this involves negotiation, posturing, or planning for failure; it is
simply be fulfilling the request by the ICG to provide complete responses -
if the IETF feels there is a potential issue with the present arrangements
in this area post-transition, then it is my understanding that the IETF 
is obligated to at least note the existing working arrangement in its RFP 
response to the ICG.

/John

Disclaimer: my views alone.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 4 Nov 2014 15:39:49 +0000

I agree. 

The terms "associated marks and identifiers" seem somewhat under defined but I'd like to make two points about this the text that reads

      subsequent operators.

A) I don't think we need this 

Yep it would be great if the location where stuff used to be had a pointer to the new location but the protocol registry is largely used by standards people and theses people will know how to find the location of the registry. The only way I can ever find anything in IANA is google. I don't see why we need any trade marks transferred for us to run a parameter registry. If we do need them, we should ask for the right to use them, not ownership. 

B) I think other people will need this more than the IETF does 

I think whoever deals with names is more likely to have a real need for the domain

If people want to transfer these to IETF Trust, great, but I find that possibility pretty unlikely. This is not the hill the we want to die on. We can easily go on without this trademark or domain name. I do not want the important parts of this draft messed up because we got fixated on trying to get something that we do not really need. 

Related to this, I find the phrase "IAOC is asked to conclude a supplemental agreement that ..." weird. Does this mean IAOC has to do this? or that IETF wishes that they try to get that? or what? I have no idea, but one thing I am sure about is that this draft is the wrong place and wrong time to change the relationship between IETF and IAOC. This should be phrased such that it is clear it is within in the normal existing relationship of the IETF and IAOC. 

Cullen

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Nov 2014 16:10:59 +0000

Insisting on the transfer of domains, marks, and identifiers to ourselves
is not likely to prevent the contingencies we're concerned about - it is
more likely to precipitate them, by turning this process into a
confrontation. I think we would need a very different mandate as an
organization to take this step. It is both reckless and unnecessary.

Jon Peterson
Neustar, Inc.

On 11/4/14, 4:21 AM, "Miles Fidelman" <[email-masked]> wrote:

>>>>> This is so close to the language that I suggested that it¹s
>>> hard for me to tell the difference between what you¹re suggesting
>>> operations shift to different entit(ies).²
>>> to enable a smooth transition of the operations ‹ regardless of
>>> to ensure backwards compatibility with subsequent operators.²
>>>
>>> Alissa
>>>
>>>
>>>> Eliot
>>>>

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 04 Nov 2014 11:27:33 -0500

Better deal with confrontation now, when NTIA is still in the picture, 
and when there really isn't any time pressure to deal with (if things 
drag out, or if NTIA isn't satisfied, they'll just extend the contract).

The whole point of clearly defined contract documents is to avoid 
conflict at times when time IS a problem - such as in the eventuality 
that IETF, or one of the other players, decides that they have to cancel 
(or threaten to cancel) their contracts with ICANN.

Better conflict now, during negotiations over the transition, than later 
- when unclear language can really cause negative impact on Internet 
operations.

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 04 Nov 2014 11:35:49 -0500

> is obligated to at least note the existing working arrangement in its RFP

As the submission, from the multiple stake-holder communities hit the 
ICG, and as those sitting at the ICG table attempt to reconcile the 
multiple proposals into one, do you really believe there isn't going to 
be any conflict and negotiation involved in merging things into a single 
proposal that everyone will sign off on?

Personally, I think that considerable conflict and negotiation can't be 
avoided - and I expect, at some point, NTIA is going to have to step in 
and play mediator.  (Just one man's opinion, of course).

Miles Fidelman

---

From: John Curran <[email-masked]>
Date: Tue, 4 Nov 2014 17:48:38 +0000

On Nov 4, 2014, at 4:35 PM, Miles Fidelman <[email-masked]> wrote:
>> ....
> As the submission, from the multiple stake-holder communities hit the ICG, and as those sitting at the ICG table attempt to reconcile the multiple proposals into one, do you really believe there isn't going to be any conflict and negotiation involved in merging things into a single proposal that everyone will sign off on?

I was quite specific: _responding to ICG RFP_ only requires identification of the
current working arrangements among the various parties, not negotiations.

> Personally, I think that considerable conflict and negotiation can't be avoided - and I expect, at some point, NTIA is going to have to step in and play mediator.  (Just one man's opinion, of course).

Quite unlikely: we have one opportunity to work together to prepare a transition 
plan for the stewardship of the IANA - if we are unable to accomplish that,
the failure is entirely ours (not USG/NTIA) and one should expect the status 
quo to be sustained....

If the community can't come together to make a cohesive plan, then it
would irresponsible to transition IANA to their collective stewardship.

/John

---

From: Eliot Lear <[email-masked]>
Date: Tue, 04 Nov 2014 10:20:40 -0800

Just on this point.

> Related to this, I find the phrase "IAOC is asked to conclude a supplemental agreement that ..." weird. Does this mean IAOC has to do this? or that IETF wishes that they try to get that? or what? I…

We are not changing the relationship in the document.  The point is that
the IAOC is the arm of our organization that makes these sorts of
arrangements.  In this case matters are complicated by the fact that the
responsibility is shared, as per RFC 6220, with the IAB (amongst
others), and we are producing a response document that identifies needs
that should be addressed.  We could simply say that "A supplemental
agreement should be concluded that says," and leave as an inference that
it is in fact the IAOC, but a normal human being might not quite follow
that.

Eliot

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 4 Nov 2014 18:25:45 +0000

> it is in fact the IAOC, but a normal human being might not quite follow

what do you mean by the word "conclude" here ? I'm trying to get at is this something you would like the IAOC to try and achieve along with many other goals of a negation or is this something that they absolutely have to achieve to be allowed to agree to the outcome of the negotiation.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 04 Nov 2014 10:28:45 -0800

On 11/4/14, 10:25 AM, Cullen Jennings (fluffy) wrote:
> what do you mean by the word "conclude" here ?

As in "conclude an agreement" or make an agreement.

>  I'm trying to get at is this something you would like the IAOC to try and achieve along with many other goals of a negation or is this something that they absolutely have to achieve to be allowed to agree to the outcome of the negotiation. 
>
>

Some form of agreement is necessary to address the concerns raised.

Eliot

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 04 Nov 2014 13:34:00 -0500

> it is in fact the IAOC, but a normal human being might not quite follow

Seems to me that a "normal human being" might not understand that IAOC 
is an "the arm of our organization that makes these sorts of arrangements."

It might be clearer to say something like "Acting through the IAOC, 
IETF's contracting body, A supplemental agreement should be concluded 
that says,"

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 04 Nov 2014 13:35:26 -0500

> Some form of agreement is necessary to address the concerns raised.

I believe that the earlier conclusion was that the intent is that such 
an agreement be concluded before the NTIA transition, and that such an 
agreement be a necessary precursor to any transition.

Miles Fidelman

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 4 Nov 2014 18:41:58 +0000

> Some form of agreement is necessary to address the concerns raised.

Ok, well that sounds like you are saying this draft would be telling IAOC that they had to do this and that gets back to my "this is not the hill to die on"

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Nov 2014 08:48:38 +1300

> organization to take this step. It is both reckless and unnecessary.

Exactly.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Nov 2014 08:52:59 +1300

On 05/11/2014 04:03, John Curran wrote:
...
> in the IETF submission to the ICG.  

If there is an issue, it's the very minor one of having to
switch to a different domain name for certain purposes. IMHO
that is not worth serious concern, but it might be worth
mentioning that there are shared names and marks.

   Brian

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 04 Nov 2014 15:16:35 -0500

>> organization to take this step. It is both reckless and unnecessary.

Acting on the assumption that NTIA going away changes things - it 
strikes me that the IETF needs to step up, and assert itself, and assume 
the responsibilities that go with being the standards body it purports 
to be.

Ultimately, the overall plan that reaches NTIA has to be very clear about:
- who does what
- how everyone is held accountable

Being wishy washy, is unbecoming and unproductive.

Miles Fidelman

---

From: Eliot Lear <[email-masked]>
Date: Tue, 04 Nov 2014 12:48:42 -0800

On 11/4/14, 10:41 AM, Cullen Jennings (fluffy) wrote:
> Ok, well that sounds like you are saying this draft would be telling
> IAOC that they had to do this and that gets back to my "this is not
> the hill to die on" 

That would be an exaggeration, to say the least.  Our processes don't
really provide for other ways forward, and we should be able to count on
the IAOC will do their job, which they've been doing for quite some
time.  If we do not lay out the issue clearly enough, they also will not
know what we are asking them to do.  That is what the text does.

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 4 Nov 2014 15:52:32 -0500

On Tue, Nov 04, 2014 at 03:16:35PM -0500, Miles Fidelman wrote:
> that the IETF needs to step up, and assert itself, and assume the
> responsibilities that go with being the standards body it purports to be.
> 

Oy, the Boss of Internetz again.  The IETF does in fact assume the
responsibilities of being that standards body.  The responsibilities
are entirely in the realm of making standards that people can actually
use, rather than standards that ensure continued existence of a paid
bureaucracy.

This "actually used" criterion is the _exact_ reason I keep saying
that control over iana.org isn't something worth trying to get,
because it cannot make any difference to future action.  If in the
event of a registry split there is co-operation, the pointer will be
there.  If there is controversy, we'll have to do an emergency
transition anyway.

Every time I say that, someone says, "Well, in the event of a
controversial split, having a contract term will put you in a better
legal position," as though that is any kind of help.  In the case of
such a split, we will need to put up a new registry at a new URI
immediately, while the legal situation works itself out.  Having done
that, what possible utility will there be in going back?

This isn't being wishy-washy.  It's being clear-eyed and cold about
what _actually_ would be important in the event of a controversial
split.  Keeping a trademark will be among the very least of our
worries, and I think focussing on it is focussing on the form rather
than the content.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Tue, 4 Nov 2014 10:57:46 -1000

> Instead, ICANN unilaterally staked a  claim to the domain, by registering it.

% whois -h whois.pir.org iana.org
Domain Name:IANA.ORG
Domain ID: D1073204-LROR
Creation Date: 1995-06-05T04:00:00Z
...

There may be more to the story of IANA.ORG than you are implying.

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

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 04 Nov 2014 16:07:53 -0500

> use, rather than standards that ensure continued existence of a paid

Generally, part of the responsibility that goes with being a standards 
body goes beyond simply promulgating "good standards."

In many cases, that includes things like compliance testing (something 
that, IMHO, the IETF and the Internet community rather fall down on).

In the case of many Internet standards, responsibilities include 
definition and oversight of registries - and the whole point of the NTIA 
transition is to define that oversight in a post-NTIA world. Isn't that 
the whole point of including accountability and transition clauses in 
the MoU and the proposal we're working on?

And, if so, accountability has to include "teeth" to enforce things.

Somehow, this "oh, if ICANN doesn't do the job, we'll take our ball and 
move it elsewhere" seems a rather timid attitude and approach.
> that, what possible utility will there be in going back?

Why should we put ourselves in that position?  If we have the authority 
to cancel the MoU, why not assert the authority to take back full 
control of the registries when doing so?
> worries, and I think focussing on it is focussing on the form rather

It's one detail among many.  In contracts, as with protocol specs, the 
devil is in the details.

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 04 Nov 2014 16:13:04 -0500

> (ICANN CTO, but speaking only for myself. Really.)

Well, it might be helpful to know that history.  At one point, SRI was 
IANA, now ICANN has registered it.  How did that come to be?

Given that the IANA function was originally being performed at the 
behest of the USG, and still is, who actually has legitimate claim to 
the trademark, and how does that play against the domain registration 
policy?

It strikes me that this is something that should be cleared up as part 
of this process.

Arguably, the cleanest way of handling this specific detail would be for 
the USG (NTIA) to assert ownership of the trademark, reclaim the domain 
registration from ICANN, and then transfer that registration to some 
neutral custodian as part of the transition.

Miles Fidelman

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 4 Nov 2014 22:16:44 +0100

I agree with Miles.

Best,
Richard

> Sent: mardi, 4. novembre 2014 22:13
> Cc: [email-masked]

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Nov 2014 21:20:59 +0000

>move it elsewhere" seems a rather timid attitude and approach.

No, it's just engineering. We're a body of engineers. If we can solve a
problem by engineering rather than engaging in politics, it plays to our
strengths. When we try to assert some authority over governments and
corporations, then we are playing in a space where we have little traction
or competence and where we are likely to lose.

Please stop trying to steer us there.

Jon Peterson
Neustar, Inc.

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 04 Nov 2014 16:28:10 -0500

> Please stop trying to steer us there.

We are MORE than a body of engineers.  We are a body that promulgates 
standards that are central to global infrastructure, and we are part of 
a body of contractually defined relationships that define roles and 
responsibilities for how those standards are used and implemented.

The whole point of the NTIA transition process is to clarify, and 
re-align some of those roles and responsibilities when the NTIA contract 
goes away - which has very little to do with engineering, and a whole 
lot to do with "techno-politics."

Please stop trying to deny that, or steer us away from the reality of 
the roles and responsibilities associated with the role the IETF plays.

Miles Fidelman

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 4 Nov 2014 22:31:25 +0100

I agree with Miles. The IANA transition is not an engineering exercise. It
is a contractual exercise.

If the IETF is not the right body to take care of those sorts of issues,
then let's say so and ask somebody else to do the job.

Best,
Richard

> Sent: mardi, 4. novembre 2014 22:28
> To: [email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 4 Nov 2014 13:33:10 -0800

On Nov 4, 2014, at 12:48 PM, Eliot Lear <[email-masked]> wrote:

> really provide for other ways forward,

This isn’t true. I suggested an alternative way, which was to ask the IAOC to get the specified issues resolved to their liking without explicitly requiring the conclusion of a supplemental agreement, which is a very specific constraint on the format and outcome of the IAOC’s negotiations.

> and we should be able to count on
> time.  

This was also the spirit of my suggestion, which is that we should indicate in the draft what the issue is to be resolved, but we should trust the IAOC’s judgment about how to get it resolved, which is the whole point of having the IAOC in the first place.

> If we do not lay out the issue clearly enough, they also will not
> know what we are asking them to do.  

We can point out the issues to be resolved without constraining them to a specific way of resolving them, as my suggested text would do.

Alissa

> That is what the text does.
> 
> Eliot
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Nov 2014 21:40:44 +0000

>is a contractual exercise.

The question of what we safeguards we require in case of a dire
contingency is only a small component of the response we've been asked to
deliver, but it's the only part under discussion in this corner of the
thread. Arguing that seizing assets and powers (arguably ones we never
held before) is the proper way to address this contingency would indeed
make it a contractual exercise. But that isn't the only type of safeguard
under consideration.

>then let's say so and ask somebody else to do the job.

We are the right body to issue a response to the questions the ICG has
asked, but after that we'll go back to being engineers and doing what we
do to make the Internet better. The sooner we're rid of this nonsense, the
better.

Jon Peterson
Neustar, Inc.

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 04 Nov 2014 16:51:12 -0500

I'd kind of suggest that a traditional IETF working group is not a 
sufficient body to take care of these sorts of issues.

We've been asked to submit a proposal for "the protocol parameters 
community" - which is being viewed being equivalent to the IETF.    
But... IETF in general, and WGs in particular, focus on technical 
matters, not matters of governance, legality, or contracts.  This seems 
to have been set up as a WG, because that's the standard IETF way of 
doing things - but... it's kind of like the old story about looking for 
one's lost keys under a lampost, because that's where the light is.

When it comes to legal, contractual, and governance matters - the IETF 
is more than it's working groups, it includes the IAB, IESG, IAOC, etc 
(as components of the IETF); the ISOC (as "parent" or whatever of the 
ISOC); and arguably the "protocol parameters community" is more than 
just the IETF.  These perspectives are reflected, at best, informally, 
in the charter and discussions of the WG.

IMHO, this continues to seem inadequate as a means for reaching and 
reflecting a consensus proposal from "the protocol parameters 
community."  Particularly, when a good portion of those taking part in 
the conversation want to avoid all but engineering issues.

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 04 Nov 2014 16:55:09 -0500

Pretty much ALL of the questions the ICG has posed are organizational 
and contractual in nature - roles, responsibilities, who does what, to 
whom.  Who develops policy, and by what process.  Who implements 
policy.  Who coordinates with whom.  What will change if and when the 
NTIA CONTRACT goes away; and what needs to change for that to work.

Very little, if anything we've been asked to respond to is technical in 
nature.

If we think such matters are "nonsense," and/or outside our scope of 
expertise - then, by definition, we should not be the (only) ones 
addressing them.

Miles Fidelman

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 4 Nov 2014 22:07:32 +0000

>Very little, if anything we've been asked to respond to is technical in

... yes, and, we'll answer the organizational questions from our
perspective and be on our way. But those parts of the document are not
what has gotten us into this tight little thread. The controversial part
is what powers or rights we as an organization need in case of calamity.
Your assessment is that this a moral question that requires a political
confrontation. Mine is that this is a minor matter that is technical in
nature - it really isn't that exciting, or even that interesting.

>expertise - then, by definition, we should not be the (only) ones

The nonsense is the cloud of political turmoil being kicked up around
these transition questions, which only distracts us from deciding what
steps, if any, we need to take to safeguard ourselves.

And the ICG's scope of inquiry is much larger than the IETF, with good
reason. The transition raises many questions that have little, or nothing,
to do with us.

Jon Peterson
Neustar, Inc.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Nov 2014 11:44:59 +1300

> There may be more to the story of IANA.ORG than you are implying.

Like, for example, that it was originally registered by Jon at
ISI, three years before ICANN existed:

-------- Original Message --------
Subject: IANA & RFC-Editor Web Pages
Date: Thu, 5 Oct 1995 12:24:38 -0700
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
CC: [email-masked], [email-masked]

Hi.

The are now web pages for the IANA and the RFC Editor.

	http://www.iana.org/iana/

	http://www.isi.edu/rfc-editor/

Perhaps it would be useful to have links to these from the
IETF/IESG, IAB,
and ISOC pages.

--jon.

---

From: John Curran <[email-masked]>
Date: Tue, 4 Nov 2014 23:14:57 +0000

On Nov 4, 2014, at 7:52 PM, Brian E Carpenter <[email-masked]> wrote:
> switch to a different domain name for certain purposes.

That could easily be the case; if so, it would be good to see if the 
working group can reach consensus on that point.

> IMHO that is not worth serious concern, but it might be worth

I believe it is mentioning regardless of IETF's intention in this area, 
although also providing some guidance (regarding continuity as-is and/or 
any desired changes) would probably prove helpful to folks trying to assess 
the completeness of the proposed IANA stewardship transition plan.

/John

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 4 Nov 2014 19:17:31 -0500

On Tue, Nov 04, 2014 at 04:51:12PM -0500, Miles Fidelman wrote:

> When it comes to legal, contractual, and governance matters - the IETF is
> more than it's working groups, it includes the IAB, IESG, IAOC, etc (as
> components of the IETF); the ISOC (as "parent" or whatever of the ISOC); and
> arguably the "protocol parameters community" is more than just the IETF.
> These perspectives are reflected, at best, informally, in the charter and
> discussions of the WG.

It seems to me that the IETF has managed to set up all those
organizations except for ISOC.  So what about the IETF makes you think
that it is incapable of drawing conclusions about organizations and
institutional arrangements?

I note that the IAB's opinion is explicitly called out in the existing
draft; and speaking with my IAB hat on just for a moment, I can tell
you that the IAB is in fact paying attention to this document and that
it cannot be published with the claim that the IAB agrees with it
unless the IAB does in fact agree.

The IAOC, of course, is going to need to be able to implement such
advice as the WG delivers.  So we can expect that the diligent members
of the IAOC will also undertake relevant review.

It strikes me that there seem to be some who would like to claim that
more grown-up or professional or serious or what-have-you procedures
-- basically, "more like I would prefer" -- are needed for this
effort.  But the argument for that conclusion appears to be simply
repetition of the claim.  One needs rather a better argument than
abusive _ad hominem_ ("wishy washy" and so on) to be convincing.

I find it interesting that I've been in engineering discussions where,
when people didn't feel that they was getting the desired
result, they started raising questions about the legitimacy for
the group to work on the topic at all.  Perhaps engineering and
contractual-principles discussions are not so different after all.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jefsey <[email-masked]>
Date: Wed, 05 Nov 2014 01:24:32 +0100

>expertise - then, by definition, we should not be the (only) ones 

Two quotes of RFC 3935 - IETF Mission statement - might be of some 
help IRT this legal and multilateral engineering endeavour?

"Technical competence - the issues on which the IETF produces its 
documents are issues where the IETF has the competence needed to 
speak to them, and that the IETF is willing to listen to technically 
competent input from any source.  Technical competence also means 
that we expect IETF output to be designed to sound network 
engineering principles - this is also often referred to as 
"engineering quality"."

"Protocol ownership - when the IETF takes ownership of a protocol or 
function, it accepts the responsibility for all aspects of the 
protocol, even though some aspects may rarely or never be seen on the 
Internet.  Conversely, when the IETF is not responsible for a 
protocol or function, it does not attempt to exert control over it, 
even though it may at times touch or affect the Internet.'

jfc

---

From: Eliot Lear <[email-masked]>
Date: Tue, 04 Nov 2014 16:53:24 -0800

> This isn’t true. I suggested an alternative way, which was to ask the IAOC to get the specified issues resolved to their liking without explicitly requiring the conclusion of a supplemental agreeme…

Any agreement can be called a supplemental agreement, but if you are not
happy with the word "supplemental" I would be happy to see it gone, but
in any case, I believe you offered wording the other night that
addressed both of our concerns.  I think there is a mild issue with the
language that can be addressed editorially.

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 4 Nov 2014 20:02:58 -0500

Dear colleagues,

> Please send comments to the list.

I have read this draft.  I have some comments apart from other remarks
I've made in this thread.  I'll use the page numbers because the
section numbers are not granular enough here.  Most of these are
pretty trivial.

p 3:

    containing the parameter values and a pointer to
   documentation of the associated semantic intent.

This is slightly problematic, because there are registry entries for
things that explicitly do _not_ have semantic intent.  For instance,
the private-use ranges in many protocols are available in the
registry, but their purpose ie explicitly to have no semantics. I'd
suggest "and a pointer to associated documentation".  I don't feel
strongly about this comment; it just seems cleaner.

Also p 3:
 
   The IANA protocol parameters registries operator maintains the
   protocol parameters registries for the IETF in accordance with all
   relevant IETF policies, in accordance with the Memorandum of
   Understanding[RFC2860] and associated supplemental agreements that
   include service level agreements (SLAs) established between the IETF
   and ICANN[MOUSUP].

This is a nit, but "in accordance" there starts to show up a lot.  How
about, "for the IETF in conformance with all relevant…"?

p 6:

   there is sufficient interest, the Internet Engineering Steering Group
   may choose to create a working group or an Area Director may choose
   to sponsor the draft.

I think insert a sentence, "Alternatively, the proposal may be in an
area of work already chartered as an existing working group, and the
working group may choose to take up the proposal."  I think someone
(Suzanne?) already suggested something along these lines.

p 8:

   sent to the Internet Society Board of Trustees for confirmation.  In
   general, members serve for two years.  The IAB selects its own
   chair.

This makes it sound like most IAB members serve for only two years.
How about, "In general, members are appointed for terms of two years;
they may be reappointed.  The IAB selects…"

p 10:

   No major changes are required, however, the IETF community has
   expressed a desire for several points to be addressed by supplemental
   agreements to the IETF-ICANN MoU, prior to a transition to post-NTIA
   regime.  Over the years since the creation of ICANN, the IETF, ICANN,
   and IAB have together created a system of agreements, policies, and
   oversight mechanisms that covers what is needed.

This ¶ is hard for me to understand.  The propositions I read here
are, 1. No major changes; 2. Some additional points are needed in
supplemental agreements; 3. We have a system of agreements that covers
what's needed.  This seems incoherent.  (1) restricts the scope of (2)
but (3) seems contradictory to (2).

I agree with Alissa, moreover, that specifying exactly how the IAOC
has to implement the desire of the WG is going a little too far.  I'm
not even sure that IETF needs the supplemental agreement for the items
1 and 2 at the bottom of the page to be in effect.  In addition I
wonder whether (2) is simply redundant to (1).  I am aware that I'm
probably in the rough on this.  I also remain extremely dubious of the
value of the "jurisdiction" stuff, and am not in favour of it.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 04 Nov 2014 20:22:35 -0500

> institutional arrangements?

I'm not.  I'm observing several things:
- the outside world (or the plain observer) does not see the granularity 
- and things like "the IETF will ask the IAOC to conclude supplemental 
agreement" are just incredibly murkey reading
- the WG charter has excluded a bunch of topics that one would expect to 
see in a complete response to the ICG RFP - particularly legal and 
contractual stuff
- the WG charter seems to focus on a subset of the issues requested by 
the RFP
- other components of the IETF - like the IAOC, the IAB are not really 
involved in the discussion (e.g., nobody seems to want to have any 
lawyers involved in the discussion) - and I have yet to see any 
discussion of how those components/perspectives are going to be 
incorporated into the formal response to the ICG
> of the IAOC will also undertake relevant review.

But where are the members of the community being engaged in that 
discussion.  This all sounds more like "we'll wave our hands over things 
and adjust/bless them." That's not an open process.

> abusive _ad hominem_ ("wishy washy" and so on) to be convincing.

Well, how about the WG charter limiting the scope of discussions to a 
subset of the ICG RFP?
> contractual-principles discussions are not so different after all.

Well... I've been raising this concern from the beginning.

Cheers,

Miles

---

From: David Conrad <[email-masked]>
Date: Tue, 4 Nov 2014 18:47:14 -1000

Miles,

On Nov 4, 2014, at 11:13 AM, Miles Fidelman <[email-masked]> wrote:
> Well, it might be helpful to know that history.  At one point, SRI was IANA,

No. SRI was "The NIC". The IANA was the IANA (before that "the numbers czar"). These are different entities. In many cases, the IANA would often direct The NIC to do stuff.

You might want to read section 2 of https://www.icann.org/en/system/files/files/sac-067-en.pdf.

> now ICANN has registered it.  How did that come to be?

I'd suggest asking some of the folks who were involved in the creation of "NewCo" (which became ICANN).  I have suspicions as to what the original plan was and have heard hearsay about why things are the way they are, but I am not authoritative and do not have evidence so it is inappropriate for me to comment.

> Given that the IANA function was originally being performed at the behest of the USG,

I believe it more accurate to say that the IANA function was performed at the behest of the IETF community and that the folks who performed that function were funded indirectly by the USG. That is, my understanding is that the IANA was _NOT_ a line item in any budget, rather the support costs that paid for Jon's, Joyce's, et al. salary were pulled from the "Tera-node" Project among others.

> and still is, who actually has legitimate claim to the trademark, and how does that play against the domain registration policy?

It would seem the US PTO believe that ICANN has the claim to the trademark. I'll admit not knowing the intricacies of how trademarks impact domain registration policy.

> It strikes me that this is something that should be cleared up as part of this process.

I do not have a strong opinion.

> Arguably, the cleanest way of handling this specific detail would be for the USG (NTIA) to assert ownership of the trademark, reclaim the domain registration from ICANN, and then transfer that registration to some neutral custodian as part of the transition.

IANAL so I won't comment.

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Nov 2014 18:50:16 +1300

> see in a complete response to the ICG RFP - particularly legal and

We are not lawyers. We have legal counsel who have served us well when
legal documents were needed, but when we try to write down legal stuff
ourselves we end up writing stupidities. That's why, some years ago,
we delegated legal and contractual stuff to the IAOC, and IPR stuff
to the IETF Trust, both of which use legal counsel as needed.

I don't object to the draft saying in general terms that the IETF
will continue to delegate legal and contractual stuff in this way.
But beyond this, we have ample evidence from experience that, as
engineers, we should keep our fingers out of this fire.

   Brian

---

From: Jefsey <[email-masked]>
Date: Wed, 05 Nov 2014 09:19:12 +0100

At 02:22 05/11/2014, Miles Fidelman wrote:
>- other components of the IETF - like the IAOC, the IAB are not 
>really involved in the discussion

Is Chris Griffiths on the list?

>(e.g., nobody seems to want to have any lawyers involved in the discussion)

Sorry, I plead for this.

>- and I have yet to see any discussion of how those 
>components/perspectives are going to be incorporated into the formal 
>response to the ICG

The ICG is not part of the WG Charter.

jfc

---

From: JFC Morfin <[email-masked]>
Date: Wed, 05 Nov 2014 09:18:32 +0100

>engineers, we should keep our fingers out of this fire.

Brian,

this WG has forked into political/legal issues and forgotten the 
technical side. Probably because the technical side is a major 
architectural completion politicians try to avoid for 30 years. The 
true point is that politicians want an alibi from us. This WG is to 
tell them that it is possible to quit the political status-quo while 
retaining a technical status-quo.

ICANN only wants the IETF to bless their reading of the NTIA DNS key 
functions transition as a seamless IANA transfer of property. This 
will not work - everyone knows it but this is not politically correct 
to even consider it. IETF (this WG) will be blamed for having 
documented this was a no-problem, in not respecting its 
Charter.  ICANN will then "save the day" in reluctantly assuming 
control. Should ISOC diverge from the ICANN strategy .org might be 
redelegated on  July 1, 2019. Question is who actually ICANN is?

jfc

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 05 Nov 2014 07:46:53 -0500

> No. SRI was "The NIC". The IANA was the IANA (before that "the numbers czar"). These are different entities. In many cases, the IANA would often direct The NIC to do stuff.

My mistake.  Memory clouds with time.  Jon was at ISI.
> It would seem the US PTO believe that ICANN has the claim to the trademark. I'll admit not knowing the intricacies of how trademarks impact domain registration policy.

Which kind of leads to the question of how ICANN ended up with the 
trademark.

As to domain registration policy: ICANN administers (sets?) the UDRP 
(Uniform Domain Name Dispute Resolution Policy) as part of its 
agreements with registrars, which includes this:

*a. Applicable Disputes.* You are required to submit to a mandatory 
administrative proceeding in the event that a third party (a 
"complainant") asserts to the applicable Provider, in compliance with 
the Rules of Procedure, that

(i) your domain name is identical or confusingly similar to a trademark 
or service mark in which the complainant has rights; and

Miles

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 05 Nov 2014 08:05:14 -0500

> engineers, we should keep our fingers out of this fire.

My point exactly.  Given that this is a community process, the content 
of which is primarily organizational, legal, and contractual in nature;  
should not the IAOC, IETF Trust, and the lawyers be heavily involved in 
this discussion; not brought in after the fact?

Treating this proposal as an engineering issue, addressed in the way 
that we'd address engineering issues, IMHO, is broken.  There are a 
whole slew of issues that are central to this process that some wish to 
deny, others wish to ignore, others feel are out of scope, and that we 
are largely unequipped to address (yes, some of us work more in the 
policy and regulatory worlds, and some of us negotiate contracts at 
times - but we're all primarily amateurs -- at least I don't think we've 
had any lawyers in the discussion).

Again, IMHO, this will ultimately lead to an ineffective proposal to the 
ICG, and to poor results down the road (for some value of poor).

At the very least, should not the IAOC, IETF Trust, and the lawyers be 
directly informing this discussion by providing guidance, review, and 
comment to the larger group, as we move toward a final proposal?  Right 
now, we're debating things like the handling of iana.org, whether it's 
important to include reference in the proposal, and what kind of 
contractual language to use -- without benefit of direct input from 
those who are responsible for negotiating, managing, and enforcing the 
very issues that are at the heart of the proposal, and without advice of 
counsel as to wording (and clear, binding wording is as important in 
contractual matters as it is in a technical specification).

Miles Fidelman

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 5 Nov 2014 15:16:38 +0000

Miles's argument and logic seem unassailable to me. 

> My point exactly.  Given that this is a community process, the content of
> which is primarily organizational, legal, and contractual in nature; should not
> the IAOC, IETF Trust, and the lawyers be heavily involved in this discussion;
> not brought in after the fact?
> 
> Treating this proposal as an engineering issue, addressed in the way that
> we'd address engineering issues, IMHO, is broken.  There are a whole slew of
> issues that are central to this process that some wish to deny, others wish to
> ignore, others feel are out of scope, and that we are largely unequipped to
> address (yes, some of us work more in the policy and regulatory worlds, and
> some of us negotiate contracts at times - but we're all primarily amateurs --
> at least I don't think we've had any lawyers in the discussion).
> 
> Again, IMHO, this will ultimately lead to an ineffective proposal to the ICG,
> and to poor results down the road (for some value of poor).
> 
> At the very least, should not the IAOC, IETF Trust, and the lawyers be directly
> informing this discussion by providing guidance, review, and comment to the
> larger group, as we move toward a final proposal?  Right now, we're
> debating things like the handling of iana.org, whether it's important to
> include reference in the proposal, and what kind of contractual language to
> use -- without benefit of direct input from those who are responsible for
> negotiating, managing, and enforcing the very issues that are at the heart of
> the proposal, and without advice of counsel as to wording (and clear, binding
> wording is as important in contractual matters as it is in a technical
> specification).
> 
> 
> Miles Fidelman
> 
> 
> 
> 
> 
> 
> 
> 
> --

---

From: Jefsey <[email-masked]>
Date: Wed, 05 Nov 2014 16:19:22 +0100

In order to permit a normal work of this WG that has committed to 
consider proposals from other communities, and due to the I_D 
sumission cut-off period, we have formally created a small Libre IUWG 
at http://iuwg.net and published the draft we had prepared as a 
contribution of an RFC 6852 global community/NTIA stakeholder. This 
unexpected WG will formalize in the coming days.

No to slow down the compromise process we have only updated a few 
words in our draft to address the issue in the perspective a separate 
WG shares with the IETF IRT our own names, numbers and parameters 
referent registries for our users.

You will find the draft at the 
http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.00.pdf

I understand that you will want to consider during the Nov 10 meeting 
if you amalgamate our positions within a WG/IANAPLAN revised draft or 
if we will have to advance our positions separately.

Best
jfc

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 10:49:04 -0500

> Miles's argument and logic seem unassailable to me. 

Really?  Ok, let me assail them.

> > not brought in after the fact?

The IETF Trust has nothing to do with this, yet, because despite what
some people keep saying there are, as yet, no assets for the Trust to
control.  The plan is to ask that there be no copyright on the
contents of the registries -- public domain -- so the Trust doesn't
have anything to hold.  And by my reckoning, there is as yet no
consensus to ask for iana.org or the IANA trademark.

The IAOC _is_ participating here, since Russ (by virtue of his
position as IAB chair) is on the IAOC and has said some things.  I
haven't looked at the list membership to see whether there are others
on the IAOC who are paying attention to this discussion.

"The lawyers" is not a very big class (last I checked, Jorge is still
one person); and anyway, we normally do not involve the IETF Counsel
directly in the terms of discussion until we know what problem we
think we're solving.  I also know that some members of the IAB have in
fact asked for specific advice on specific topics, so it's not like
the work is proceeding without any guidance.  But we need to know what
we want before we ask for legal advice, I suggest, and it's not clear
to me that everyone is yet pulling in the same direction, even
roughly.

> > at least I don't think we've had any lawyers in the discussion).

Certainly there are issues that some people keep claiming are central
to the process; whether they are central _for the IETF_ seems not to
be quite so obvious.  I resent the suggestion that those of us who
disagree either "wish to deny" or "wish to ignore": it could be that
we just disagree with those who think they're central.  For my part, I
have in fact thought about these issues for some time, and there are
things that people keep saying are central that I believe to be
distractions.  The most obvious of these is, I think, the IANA
trademark and iana.org domain name, which I regard as nice to have but
by no means central.  There are also claims about oversight and
assertions of authority that I simply don't believe in: I think the
only reason the IETF's stuff is "the standard" is because people
believe that.  It's like fiat money.  Claiming that there's a
government behind it is what people do, but that's not what makes the
money worth anything.  Ask people in Argentina.

> > and to poor results down the road (for some value of poor).

I guess I don't know what an "effective" proposal to the ICG is.
Perhaps I could be enlightened.  If it's just another word for, "One
that asserts all the aforementioned authority," however, then I think
that's a persuasive definition of "effective".  

The only poor results that I've heard forecast so far have two types:
1. someone else gets iana.org and publishes a "competing" registry;
2. people (perhaps governments) try to assert some other locus of
control of protocols and standards.  Have I missed anything?

On (1), I think it would be bad but, as I have already argued (so
won't rehearse), there is nothing we could do about that if it
happened.  

On (2), we already have this problem -- indeed, have had since TCP/IP
was being conceived -- and the way that we continue to be successful
against such things is to produce standards that interoperate better,
that are easier to implement, and that are widely accepted and used.
There are certainly annoyances -- the fact that IETF standards are not
"official" means that in some countries they can't be referred to in
procurement documents.  We should doubtless undertake efforts to solve
that, but the only way that we'll be successful is co-operatively with
the relevant governments.  Governments who _don't_ want that will
always find some excuse, and we can't do anything about that except
produce something that is so much better than the alternative that
everyone wants to use it.

> > larger group, as we move toward a final proposal?  

See above.

> Right now, we're
> > debating things like the handling of iana.org

No, right now some people are militating for us to assert a unilateral
right to an asset of a corporation.  I don't need legal advice to
understand whether that is a reasonable position to take.  It _does_
seem to me that perhaps the current holder of those assets may have an
opinion on it, which is why it is worth asking about on this list.

> >, whether it's important to
> > include reference in the proposal

Sorry, I don't understand this.  Which reference?

> > , and what kind of contractual language to
> > use 

None.  Our charter says, "The WG will identify, but not create, such
required agreements."  Also,

  Fully documenting the interaction between the IETF and the operator
  of IETF protocol parameters registries may require detailed terms of
  agreements or other details of procedures that are normally delegated
  to and handled by the IAB or IAOC. The working group will not attempt
  to produce or discuss documentation for these details, but will
  request the IAB or IAOC to provide them separately.

This is precisely the point Alissa was making about the request to the
IAOC that is in the current I-D.

Assailingly yours,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 05 Nov 2014 07:55:18 -0800

Hi Andrew and thanks for your review.  Responses in line.

> strongly about this comment; it just seems cleaner.

I propose to accept this change, barring any objections.  I am, however,
growing concerned that someone from the outside not actually get a good
view as to what a protocol parameter really is with our current text.  I
don't want an RFP response to turn into a tutorial, but perhaps we need
one more clear sentence to really make the point.

> about, "for the IETF in conformance with all relevant…"?

I propose to accept this change, barring any substantial objection, as
it improves readibility.

> (Suzanne?) already suggested something along these lines.

I think from a flow standpoint we would want to invert that, but the
point is well taken.  What I propose is the following:

        ... Anyone may submit such a
        proposal.  If there is sufficient interest, a working
        group whose scope includes the proposed work may choose to
        adopt it, the Internet Engineering Steering Group may
        choose to create a working group, or an Area Director may
        choose to sponsor the draft.  In any case, anyone may
        comment on the proposal as it progresses.
> they may be reappointed.  The IAB selects…"

I propose to accept this change because it makes the text more clear.

> value of the "jurisdiction" stuff, and am not in favour of it.

This issue remains open, and I propose to address it separately.

Thanks again for your comments,

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 10:55:46 -0500

Dear colleagues,

> http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.00.pdf

I have skimmed quickly through but not read in depth that draft.  I do
not see, however, any way in which it impinges on the work this WG is
chartered to do.  That may well be because I don't understand it.  But
I don't see how it is in any way directly germaine to the question of
NTIA transition or IANA protocol parameters registries.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 11:04:59 -0500

> one more clear sentence to really make the point.

How about this, then:

OLD

   Many IETF protocols make use of commonly defined protocol parameters.
   These parameters are used by implementers, who are the IETF's primary
   users of the IETF standards and other documents.  To ensure
   consistent interpretation of these parameter values by independent
   implementations, and to promote universal interoperability, these
   IETF protocol specifications define and require globally available
   registries containing the parameter values and a pointer to
   documentation of the associated semantic intent.  The IETF uses the
   IANA protocol parameters registries to store this information in a
   public location.

NEW

    Many IETF protocols make use of commonly defined protocol
    parameters.  These parameters define various behaviours of the
    protocol depending on the values of the parameters.  They are used
    by implementers, who are the IETF's primary users of the IETF
    standards and other documents.  To ensure consistent
    interpretation of these parameter values by independent
    implementations, and to promote universal interoperability, these
    IETF protocol specifications define and require globally available
    registries containing the parameter values and a pointer to
    documentation that established the registry entry (which normally
    governs its interpretation).  The IETF uses the IANA protocol
    parameters registries to store this information in a public
    location.

It's a little windier, I admit.

>         comment on the proposal as it progresses.

WFM.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Richard Hill" <[email-masked]>
Date: Wed, 5 Nov 2014 17:06:38 +0100

Please see my comments below.

Thanks and best,
Richard

> Sent: mercredi, 5. novembre 2014 16:49
> To: [email-masked]
> control.

Correct.  The question that we are discussing is whether we should ask the
IETF Trust to control (1) the mark IANA and (2) the domain name IANA.ORG.
And maybe other intellectual property.

> The plan is to ask that there be no copyright on the

Correct.  We are discussing the matter.

> to me that everyone is yet pulling in the same direction, even

Indeed.  In my view, this group should formulate a clear requirement, after
which the appropriate legal counsel can figure out (1) whether it can be
fulfilled and (2) if so, how.

> be quite so obvious.

Let's say that we have differing points of view.

>I resent the suggestion that those of us who
> we just disagree with those who think they're central.

Yes.

>  For my part, I
> by no means central.

I believe that we all understand each other's positions, we just don't
agree.

>There are also claims about oversight and

I agree with that, but that's not, to me, the issue.  The issue is whether
we should take steps to ensure that a possible future transition goes
smoothly, by working out in advance what happens to certain things. For
example, I think we agree that the data should be in the public domain.

In addition, some of us think that something should be said abouot the mark
and the domain name.

> control of protocols and standards.  Have I missed anything?

Yes.  For me, the main problem is that, if for some reason IETF decides to
move the IANA function, ICANN, for perfectly legitimate reasons of its own,
may decide to retain the IANA mark and the IANA.ORG domain name.  Then IETF
has to use a different mark and domain name.  As you say, doable, but, in my
view, a hassle that can be avoided by taking steps now.

> right to an asset of a corporation.

As noted by others, it is not clear why ICANN took unilateral control of
those assets.  And, anyway, everything that happened up to now happened with
the blessing of NTIA, and NTIA has asked us to figure out how to proceed in
the future.

So a different arrangement of the intellectual property is something that
appears to me to be legitimate to envisage.

And, as noted above, there seems to be agreement that the actual data should
be in the public domain.  That is also an assertion regarding the assets of
a corporation.

>I don't need legal advice to

Again, I'm confused.  ICANN is the current holder of those assets.  NTIA has
asked ICANN to convene a process to figure out how to transition the IANA
Function. ICANN has charterd the ICG to do that, and the ICG has asked
groups (including this group) to do that.

So this group is ICANN, for the purposes of the transition.

The transition may involve the assets in question.  So, in effect, ICANN
will be presenting a proposal to NTIA regarding what it wants to do with the
assets in question.

Where's the problem?

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 5 Nov 2014 11:18:58 -0500

Colleagues, 

I want to thank Miles and Andrew for this exchange; it suggests a potentially useful insight on where we might be talking past each other.

Much of this conversation, and a number of other apparent disagreements inside the WG, seem to me to come from a disconnect between a) people who have experience of the IETF and its structures because they do work in the environment the IETF creates and b) people who don't, whose knowledge of the processes and activities described in draft-ietf-ianaplan are less immediate.

To many IETF participants with experience in getting work done within the organizational structures we're talking about, there are some fairly clear assumptions that can easily be made about the role of the WG and of the IETF and related groups. One is that the WG's job, per the charter, is not to tell the IAB and the IAOC exactly what to say, to the ICG or ICANN or anyone else; it's to establish consensus on the desired outcomes and basic tradeoffs, so the consensus can be implemented by contracts, other means of establishing shared understanding such as liaisons and MoUs, business processes of the IANA, procedural documents that may be RFCs, etc. Another is that the IAB and the IAOC can reasonably be trusted to do this because it's what they're asked and chosen by the community to do, by a nomcom chosen from the community and under criteria the community has every opportunity to influence. It's also generally assumed-- because we've seen it over the years-- that the IAB and the IAOC have every reasonable help in doing their jobs from lawyers and other professionals. Some of the confidence is from feeling we know the people and the processes that gave them their current responsibilities; some is because there are appeal and recall processes also defined in case we got it really wrong. 

And some of the confidence comes from understanding that a failure of this process, or the IETF/ICANN relationship, would be a massive, painful inconvenience, best avoided in any way reasonably possible-- but not an existential threat to the ability of the IETF to do its work.

It seems to me that many of the participants here (Andrew, Eliot, Leslie, Brian, etc.) have shared these underlying assumptions, so that even when they've disagreed on the specific outcomes we're looking for, they've agreed on the level of detail and the tradeoffs ("need to have" vs. "nice to have") that should be specified in this document and within this WG's charter. 

It also seems that other participants have wanted to have an entirely different conversation, on first principles such as the need for lawyers to negotiate contracts.

On Nov 4, 2014, at 8:22 PM, Miles Fidelman <[email-masked]> wrote:

> - the outside world (or the plain observer) does not see the granularity - and things like "the IETF will ask the IAOC to conclude supplemental agreement" are just incredibly murkey reading
> - the WG charter has excluded a bunch of topics that one would expect to see in a complete response to the ICG RFP - particularly legal and contractual stuff
> - the WG charter seems to focus on a subset of the issues requested by the RFP
> - other components of the IETF - like the IAOC, the IAB are not really involved in the discussion (e.g., nobody seems to want to have any lawyers involved in the discussion) - and I have yet to see any discussion of how those components/perspectives are going to be incorporated into the formal response to the ICG

As above, and I think Andrew said but perhaps not quite explicitly enough: the IAB and the IAOC are trusted to get the implementation details covered in a reasonable, workable way because it's the job they were appointed to, after consideration of their qualifications for it; because of past experience, including some difficult moments in other relationships of the IETF with IANA and RFC Editor operators; and because the community can kick them out if we really don't like what they're doing.

What's become clear in this exchange and others is that those assumptions are not making it into the document, and remain opaque for those not experienced with the processes and structures.

For example, I'm not worried about whether the IAOC will consult real lawyers when it comes to drafting contract language, and no, it's not because I think real lawyers aren't needed. It's because I know they are, if the appropriate vehicles for doing what we want turn out to include contracts, and that the IAOC doesn't need you or me to tell them so, they need us to tell them what we want them to accomplish with the help of those lawyers.

I think a lot of the experienced IETF participants here aren't worried about it either.

But we need to be concerned that you are.

> But where are the members of the community being engaged in that discussion.  This all sounds more like "we'll wave our hands over things and adjust/bless them." That's not an open process.

This *is* "where….the members of the community [are] being engaged in that discussion." This seems to be preferable to having everyone on this mailing list in the room negotiating contract language, even assuming further contract language is needed beyond what we have today. Forgive me if that sounds flippant, but I think there's a serious underlying question there too: at what point do you think it's appropriate for the community to say "OK, guys, here's the outcomes we want, the basics of how to get there, and some tradeoffs we regard as important, now *you* go do *your* job of implementing it" to the people it's appointed?

> Well, how about the WG charter limiting the scope of discussions to a subset of the ICG RFP?

The one that assumes the IAOC and the IAB will do their jobs, and that we'll be able to tell if they're not?

I'll agree that that could be better documented. The charter reads just fine to me, given the assumptions I'm comfortable making from experience, but that doesn't mean it's easily explained to others. I'm tentatively convinced that there should be more in the final deliverable from the IETF to the ICG on why the IETF consensus is suitable in scope and suitable as instructions to the IAOC (which is responsible for contractual relationships on behalf of the IETF, including the RFC Editor, the IANA, and the secretariat) and the IAB (which has overall responsibility for those functions on behalf of the IETF, and is expected to consult with the IETF on those responsibilities, as it has here).

But I think it would be a failure in a number of ways for this WG to spend its time on "legal and contractual stuff," or for the IAOC and the IAB to be bound by the results if we did.

best,
Suzanne

---

From: John Curran <[email-masked]>
Date: Wed, 5 Nov 2014 16:20:36 +0000

> we just disagree with those who think they're central.  

To be clear, I have not stated that the iana.org or IANA mark issue 
is central - only that it is a present interdependency, and that such 
independencies are specifically requested within the ICG RFP response.

> Perhaps I could be enlightened.  ...

The ICG RFP asks:

" · A description of any overlaps or interdependencies between your IANA requirements and the functions required by other customer communities.
If your community relies on any other IANA service or activity beyond the scope of the IANA functions contract, you may describe them here. In this case please also describe how the service or activity should be addressed by the transition plan."

To the extent that the IETF community presently relies upon the 
"iana.org" domain name and/or makes use of the IANA mark, I do 
believe that should be noted in the IETF's ICG RFP response.

One can note it along with a comment that says "To be worked out", 
or "lack of coordination would be bad", or even no suggestion at 
all with respect to the proposed transition plan; it's only the 
failure to mention it at all that would be a material omission 
on the part of the IETF.

/John

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 05 Nov 2014 12:03:21 -0500

Suzanne,

Thank you for the thoughtful comments, but.. I would take issue with you 
on a couple of items - see below...

Suzanne Woolf wrote:
> Colleagues,
>
> I want to thank Miles and Andrew for this exchange; it suggests a 
> potentially useful insight on where we might be talking past each other.
>
> Much of this conversation, and a number of other apparent 
> disagreements inside the WG, seem to me to come from a disconnect 
> between a) people who have experience of the IETF and its structures 
> because they do work in the environment the IETF creates and b) people 
> who don't, whose knowledge of the processes and activities described 
> in draft-ietf-ianaplan are less immediate.

I don't believe this is an accurate representation of the situation.

I think it's more that at least several of us are questioning how well 
standard IETF structures and procedures apply to the task at hand - 
i.e., crafting a consensus proposal that responds to the the ICG, and to 
the NTIA - and doing so through an open, transparent, consensus process. 
(As I believe NTIA and the ICG are asking for.)

>
> To many IETF participants with experience in getting work done within 
> the organizational structures we're talking about, there are some 
> fairly clear assumptions that can easily be made about the role of the 
> WG and of the IETF and related groups. One is that the WG's job, per 
> the charter, is not to tell the IAB and the IAOC exactly what to say, 
> to the ICG or ICANN or anyone else; it's to establish consensus on the 
> desired outcomes and basic tradeoffs, so the consensus can be 
> implemented by contracts, other means of establishing shared 
> understanding such as liaisons and MoUs, business processes of the 
> IANA, procedural documents that may be RFCs, etc. Another is that the 
> IAB and the IAOC can reasonably be trusted to do this because it's 
> what they're asked and chosen by the community to do, by a nomcom 
> chosen from the community and under criteria the community has every 
> opportunity to influence. It's also generally assumed-- because we've 
> seen it over the years-- that the IAB and the IAOC have every 
> reasonable help in doing their jobs from lawyers and other 
> professionals. Some of the confidence is from feeling we know the 
> people and the processes that gave them their current 
> responsibilities; some is because there are appeal and recall 
> processes also defined in case we got it really wrong.

It strikes me that, as others have also pointed out, that governance, 
legalities, and contracts are NOT typically working group matters.  
Which is a different matter entirely from whether they are central 
issues that must be addressed in a response to the ICG.

Rather, these matters are delegated to "organs" of the IETF that don't 
seem to generally operate through the same consensus process as IETF's 
primary standards making activities.

Which leaves a very big gap between the task at hand, the issues to be 
addressed, and a consensus process for arriving at a proposal to the 
ICG, and follow-on discussions and negotiations on behalf of the IETF as 
"our" proposal is merged with those of the other stakeholder communities.

Leaving such matters to the IAB and IOAC, after the WG develops a draft, 
does not seem an adequate approach, in that:
- as Richard points out - lawyers tend to do a better job with clear 
direction (personally, I'd make the same observation about contracting 
officers)
- GIGO: the working group is talking engineering, while this is 
primarily a legal & contractual matter - a draft written by engineers is 
not necessarily a good basis for a response that should (IMHO) be framed 
in contractual language
- "trusting the IAB and the IOAC" is neither open, transparent, nor by 
consensus (irregardless of whether we, in fact, trust them)

As I see it, either:

a. this working group has to overtly address issues, and recruit 
experience, that are not normally within IETF WG purview, or,

b. we need to have some OTHER, clearly defined, open, consensus process 
for addressing this set of issues; that includes strong representation 
from those with governance, regulatory, legal, and contractual matters 
in the Internet context (starting with the IAB, IAOC, IETF trust, and ISOC)

Otherwise, IMHO, IETF is not carrying the water in responding to the 
RFP; and more substantively, risks undesirable outcomes in a post-NTIA 
world.

Respectfully,

Miles Fidelman

>
> And some of the confidence comes from understanding that a failure of 
> this process, or the IETF/ICANN relationship, would be a massive, 
> painful inconvenience, best avoided in any way reasonably possible-- 
> but not an existential threat to the ability of the IETF to do its work.
>
> It seems to me that many of the participants here (Andrew, Eliot, 
> Leslie, Brian, etc.) have shared these underlying assumptions, so that 
> even when they've disagreed on the specific outcomes we're looking 
> for, they've agreed on the level of detail and the tradeoffs ("need to 
> have" vs. "nice to have") that should be specified in this document 
> and within this WG's charter.
>
> It also seems that other participants have wanted to have an entirely 
> different conversation, on first principles such as the need for 
> lawyers to negotiate contracts.
>
> On Nov 4, 2014, at 8:22 PM, Miles Fidelman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Andrew Sullivan wrote:
>> - the outside world (or the plain observer) does not see the 
>> granularity - and things like "the IETF will ask the IAOC to conclude 
>> supplemental agreement" are just incredibly murkey reading
>> - the WG charter has excluded a bunch of topics that one would expect 
>> to see in a complete response to the ICG RFP - particularly legal and 
>> contractual stuff
>> really involved in the discussion (e.g., nobody seems to want to have 
>> any lawyers involved in the discussion) - and I have yet to see any 
> As above, and I think Andrew said but perhaps not quite explicitly 
> enough: the IAB and the IAOC are trusted to get the implementation 
> details covered in a reasonable, workable way because it's the job 
> they were appointed to, after consideration of their qualifications 
> for it; because of past experience, including some difficult moments 
> in other relationships of the IETF with IANA and RFC Editor operators; 
> and because the community can kick them out if we really don't like 
> what they're doing.
>
> What's become clear in this exchange and others is that those 
> assumptions are not making it into the document, and remain opaque for 
> those not experienced with the processes and structures.
>
> For example, I'm not worried about whether the IAOC will consult real 
> lawyers when it comes to drafting contract language, and no, it's not 
> because I think real lawyers aren't needed. It's because I know they 
> are, if the appropriate vehicles for doing what we want turn out to 
> include contracts, and that the IAOC doesn't need you or me to tell 
> them so, they need us to tell them what we want them to accomplish 
> with the help of those lawyers.
>
>> discussion.  This all sounds more like "we'll wave our hands over 
>> things and adjust/bless them." That's not an open process.
>
> This *is* "where….the members of the community [are] being engaged in 
> that discussion." This seems to be preferable to having everyone on 
> this mailing list in the room negotiating contract language, even 
> assuming further contract language is needed beyond what we have 
> today. Forgive me if that sounds flippant, but I think there's a 
> serious underlying question there too: at what point do you think it's 
> appropriate for the community to say "OK, guys, here's the outcomes we 
> want, the basics of how to get there, and some tradeoffs we regard as 
> important, now *you* go do *your* job of implementing it" to the 
> people it's appointed?
>
> I'll agree that that could be better documented. The charter reads 
> just fine to me, given the assumptions I'm comfortable making from 
> experience, but that doesn't mean it's easily explained to others. I'm 
> tentatively convinced that there should be more in the final 
> deliverable from the IETF to the ICG on why the IETF consensus is 
> suitable in scope and suitable as instructions to the IAOC (which is 
> responsible for contractual relationships on behalf of the IETF, 
> including the RFC Editor, the IANA, and the secretariat) and the IAB 
> (which has overall responsibility for those functions on behalf of the 
> IETF, and is expected to consult with the IETF on those 
> responsibilities, as it has here).
>
> But I think it would be a failure in a number of ways for this WG to 
> spend its time on "legal and contractual stuff," or for the IAOC and 
> the IAB to be bound by the results if we did.
>
>
> best,
> Suzanne
>
>

---

From: Andrei Robachevsky <[email-masked]>
Date: Wed, 05 Nov 2014 18:06:22 +0100

Eliot Lear wrote on 05/11/14 01:53:
>> This isn’t true. I suggested an alternative way, which was to ask
>> the IAOC to get the specified issues resolved to their liking
>> without explicitly requiring the conclusion of a supplemental
>> agreement, which is a very specific constraint on the format and
>> outcome of the IAOC’s negotiations.
>> 
> Any agreement can be called a supplemental agreement, but if you are
> not happy with the word "supplemental" I would be happy to see it
> gone, but in any case, I believe you offered wording the other night
> that addressed both of our concerns.  I think there is a mild issue
> with the language that can be addressed editorially.

To me the key here is that as Alissa said, we shouldn't put specific
constrains on the format and outcome at this stage. I think the purpose
of this phase is identify the gaps and set the requirements correctly.

Coming back to trademarks, I think the requirement is to minimize
confusion wrt authoritative protocol parameter registries in a possible
future case when ICANN transfers its IANA function(s) operator to
another entity, and not that the IETF gets IANA.ORG.

I understand that the details of the arrangements to mitigate the
identified risk will be flashed out at the next stage, when a
consolidated proposal is produced and we have a better understanding of
the requirements of other operational communities.

Then, I think, we can discuss specific implementations that will satisfy
all operational communities.

Andrei

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 5 Nov 2014 17:46:10 +0000

>RFP; and more substantively, risks undesirable outcomes in a post-NTIA

We were asked to reply to the ICG's questions as the IETF, not the
something-other-than-the-IETF. Many of us wear other hats or participate
in other bodies in the community. But the response that is going to come
out of the IETF has to derive from the IETF's processes. Changing what the
IETF is or how it works to reply to this questionnaire would totally
defeat the purpose - only in that case would we be failing to carry the
water, I thnk. The ICG is asking plenty of other bodies with different
mandates what other perspectives are, which includes the kind of expertise
you cite here.

So who gets to say what the IETF is? Because the IETF has no concept of
membership, anyone can join a list and advocate that "we" should do, or
"we" should be, this or that, even if they've never written an RFC, served
as a working group chair, or (apropos the topic today) registered a
protocol parameter. Even people who work primarily in bodies that directly
compete with us, like say the ITU-T, can walk in and opine on what "we"
should do here at the IETF. "Our" input comes from our partner
organizations, and from people completely out of left field, and even from
disgruntled former members of our leadership. And all of this input comes
from "us," as "we" are self-selecting.

I think the IETF likes it this way, because sometimes the best ideas come
from unexpected sources. But to Suzanne's point, consensus here is shaped
by our shared understanding of our processes and to some degree our
people. It is the consensus of this group that will, and should, represent
the IETF's response to this questionnaire. If you feel input to the ICG
should come from other sources or contributors who don't self-select as
IETFers, then that input isn't the IETF's input. It isn't "us."

Jon Peterson
Neustar, Inc.

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 05 Nov 2014 12:50:16 -0500

> IETFers, then that input isn't the IETF's input. It isn't "us."

Yes, but the IETF is MORE than the WG and RFC processes.  The question 
is, how does the IETF address issues that go beyond technical ones?

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 13:02:38 -0500

On Wed, Nov 05, 2014 at 12:50:16PM -0500, Miles Fidelman wrote:
> Yes, but the IETF is MORE than the WG and RFC processes.  The question is,
> how does the IETF address issues that go beyond technical ones?

I'm sorry, but for the purposes of stating what "the IETF wants", the
IETF is not more than the consensus-calling process that we use for
everything else.  There is exactly one way for the IETF to say what
"it" wants, and that is to do a consensus call.

The various "other bodies" that you seem to keep pointing to are, yes,
irrelevant to that.  The IAOC has to do what it is instructed to do.
And the IAB functions independently -- it has its own mechanism by
which it determines what the IAB wants.

This is all, by the way, nicely and clearly outlined in several of the
documents referred to by the WG's I-D. 

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Wed, 5 Nov 2014 10:32:18 -0800

FWIW, my opinion is close to what Andrew, Brian, Jon, and others have expressed in this thread. That is, what ultimately matters is the world’s adoption of standards rather than specific domains. I’m fine with the “backwards compatibility” direction that Alissa and Eliot suggested for the text.

Thanks,

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Nov 2014 07:45:39 +1300

One small gloss on Jon's text:

On 06/11/2014 06:46, Peterson, Jon wrote:
...
> the IETF's response to this questionnaire. 

And, in the context of the IETF, "consensus" means "rough consensus".
Not everybody has to agree.
http://tools.ietf.org/html/rfc2418#section-3.3

   Brian

---

From: JFC Morfin <[email-masked]>
Date: Wed, 05 Nov 2014 20:06:47 +0100

>"it" wants, and that is to do a consensus call.

Dear Andrew,

I have no problem with you not understanding what your different
colleagues may say, and in expessing your our thinking as a reference
other may oppose, etc. This is a philosophical form of more emotive
debate (beliefs vs beliefs). I must confess I prefer a scientific form
of debate, where critics are meant to add to a common progress.
However, both approaches are blocked when the accepted consensus is
opposed like you do here.

I think it is worth to underline it when it clearly occurs such in
your position above, when compared with the RFC 3935 (IETF mission
statement) section 3 which is the base of most's reasoning in terms of
decision preparation by this WG

"3.  The Need for a Mission Statement

    The IETF has to make decisions.  And in some cases, people acting on
    behalf of the IETF have to make decisions without consulting the
    entire IETF first.

    There are many reasons for this, including the near-impossibility of
    getting an informed consensus opinion on a complex subject out of a
    community of several thousand people in a short time.

    Having a defined mission is one of the steps we can take in order to
    evaluate alternatives: Does this help or hinder the mission, or is it
    orthogonal to it? If there are limited resources, are there things
    that they could be invested in that help the mission better?

    (Another step is to choose leaders that we trust to exercise their
    good judgement and do the right thing.  But we're already trying to
    do that.)"

Which position should we accept as accept as a reference for this WG's work?
jfc

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Wed, 05 Nov 2014 15:43:30 -0500

Miles,

The IAOC needs to know what the IETF wants in order to build the 
administrative structures to provide it.  In other contexts, the IAOC 
has been pretty tightly circumscribed to not "invent" things for the IETF.

In that light, I believe the purpose of this working group is to develop 
consensus around the needs of the community to support the IETF's work 
and protocols, going forward.     As a developer (of standards, or 
software using standards), or deployer of networks, or other 
producer/consumer of technical protocol parameters, what are the 
requirements of the system post-NTIA transition?

That may not be protocol engineering, but it is a fairly technical task. 
  It is not defining the form of the final implementation to meet those 
requirements (lawyering, contracting, etc).   As a technical task, I 
believe it is possible for a working group format to achieve the outcome.

 > experience, that are not normally within IETF WG purview, or,

Per the above, I don't believe that is necessary.  Notably, in this 
group's charter:

[From http://datatracker.ietf.org/wg/ianaplan/charter/ ]
"Fully documenting the interaction between the IETF and the operator
of IETF protocol parameters registries may require detailed terms of
agreements or other details of procedures that are normally delegated
to and handled by the IAB or IAOC."

 > in the Internet context (starting with the IAB, IAOC, IETF trust, and 
ISOC)

That question is outside the scope of this WG.  If you feel it is 
necessary, I would suggest that you could take it up (in person, or 
remotely) at the Admin Plenary at IETF91, next week.

Leslie.

On 11/5/14 12:03 PM, Miles Fidelman wrote:
> legalities, and contracts are NOT typically working group matters. Which
> is a different matter entirely from whether they are central issues that
> must be addressed in a response to the ICG.
>

-- 

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

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 5 Nov 2014 22:07:15 +0000

Andrew:

> control.  The plan is to ask that there be no copyright on the contents
> of the registries -- public domain -- so the Trust doesn't have anything
> to hold.  

Will that plan work? Might be good to have some advice. A lawyer might have told you that in order to prevent your registry contents from being copyrighted (or their source identifier from being trademarked) you might have to copyright or trademark them yourself, and issue a general public license to keep them in the public domain. Any reason why we should not ask for this advice? 

> And by my reckoning, there is as yet no consensus to ask for
> iana.org or the IANA trademark.

There is certainly a preponderance of opinion that we should. Failing to ask for it certainly has no consensus. 

> The IAOC _is_ participating here, since Russ (by virtue of his position as
> IAB chair) is on the IAOC and has said some things.  I haven't looked at
> the list membership to see whether there are others on the IAOC who
> are paying attention to this discussion.

That's true enough, and a good point, so why is Miles's suggestion greeted with such panic?  What's stopping getting some additional opinions from the Trust or from the IETF counsel? 

> simply don't believe in: I think the only reason the IETF's stuff is "the
> standard" is because people believe that.  It's like fiat money.  Claiming
> that there's a government behind it is what people do, but that's not
> what makes the money worth anything.  Ask people in Argentina.

You're missing the point about confidence in standards. To continue with the financial analogy, you are in effect saying, "we don't mind if people issue counterfeit money, everyone knows where to get the real stuff."

 Well, maybe, but more likely, some people will be fooled and a lot of people will be confused. And since the costs or downsides of controlling the domain and the trademark are negligible, why take that risk? Have you ever described one bad thing that would happen if this proposal calls for moving the trademark or the domain? I don't think you have. So claiming that you don't think it will be necessary is a very weak argument.

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 5 Nov 2014 22:18:41 +0000

I agree with John. Indeed, I don't see how anyone could disagree. 

The IANA.org domain and the trademark, which could legally restrict usage of that term by anyone other than ICANN, is both an overlap (in that all 3 communities rely on it currently) and an interdependency (in that any individual community's decision to change their IANA functions operator would affect another if they were all linked in some way to the IANA name or domain).

> " · A description of any overlaps or interdependencies between your
> IANA requirements and the functions required by other customer
> communities.
> If your community relies on any other IANA service or activity beyond
> the scope of the IANA functions contract, you may describe them
> here. In this case please also describe how the service or activity
> should be addressed by the transition plan."
> 
> One can note it along with a comment that says "To be worked out", or
> "lack of coordination would be bad", or even no suggestion at all with
> respect to the proposed transition plan; it's only the failure to mention
> it at all that would be a material omission on the part of the IETF.
> 
> /John
>

---

From: 'Andrew Sullivan' <[email-masked]>
Date: Wed, 5 Nov 2014 18:44:44 -0500

> There is certainly a preponderance of opinion that we should. Failing to ask for it certainly has no consensus. 

"Preponderance of opinion" is not the way the IETF works.  We work by
rough consensus, and it is possible in rough consensus for even one
lone voice to derail the consensus, if the argument is strong.  See below.
 
> That's true enough, and a good point, so why is Miles's suggestion greeted with such panic?

I'm not panicking.  Miles is suggesting that there's something
_outside_ IETF processes -- the IAOC, some lawyers, the IAB, anything
-- that is appropriately brought to bear here.  I argue that, on the
contrary, there really _isn't_ anything outside the WG in IETF terms.
So Miles says, "Well, IETF processes are inappropriate for this,
because $some_authoritay_not_here."  I agree with him that there isn't
some external Internet Boss who can decide.  I think that's a feature,
not a bug.

>  You're missing the point about confidence in standards. To continue
> with the financial analogy, you are in effect saying, "we don't mind
> if people issue counterfeit money, everyone knows where to get the
> real stuff."

No, I'm saying that is indeed a serious risk, and we ought to worry
about it, but that meaningless shibboleths (viz. "the domain name
where I got this") are not a protection.  If we think that there is a
real problem with the legitimacy of data in the IETF registries, then
we should sign the data.  (And in fact, I think we _should_ sign the
data.  But that's not part of this transition, because it has nothing
to do with outside people.)

>  of people will be confused. And since the costs or downsides of
>  controlling the domain and the trademark are negligible, why take
>  that risk? Have you ever described one bad thing that would happen
>  if this proposal calls for moving the trademark or the domain? I
>  don't think you have.

No, I have, but you reject the premise.  I have said that it forces us
to negotiate with ICANN, potentially giving up something that we want
instead of this.  You reject the idea that we'll have to negotiate
over this, because NTIA will simply impose whatever we ask for.  In my
opinion, that is a dangerous fantasy.  ICANN is also the source of the
"names community" input to the ICG.  Just as we have the opportunity
to comment on and express our views about the other communities'
proposals where they don't fit with our understanding, the other
communities will have a chance to do the same for us.  I just find it
implausible that ICANN wouldn't care about this, but I believe that
there are people busily trying to find out.  If I am wrong, I'll
cheerfully withdraw my objection.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 05 Nov 2014 19:11:28 -0500

> some external Internet Boss who can decide.  I think that's a feature,

No.. I'm NOT saying some Internet Boss outside the IETF.  I'm saying 
that processes for addressing technical issues are inadequate for 
dealing with issues that go beyond technical issues (kind of sounds like 
a tautology).

The IETF process for dealing with contracts is to delegate things to the 
IAOC, rather than deliberate them the way protocol issues are 
deliberated.  The IAB and IAOC are part of the IETF, but are not 
normally part of the technical process.  I'm suggesting that the process 
needs to expand it's scope and participation beyond the technical, to 
include parts of IETF that are not normally part of protocol 
standardization.  Nothing more.

> cheerfully withdraw my objection.

Personally, I agree that raising the issue, and stating a position may 
force us to negotiate with ICANN (and with other players).

I'll ask the question: why is that a problem, or something to be 
avoided?  Most contracts are negotiated.  The MoU, presumably, was 
negotiated.  The NTIA contract that is being replaced was negotiated.

Rather, I'd suggest that we acknowledge that there's going to be some 
issues that folks disagree on, and that some negotiation is going to be 
involved in getting to a consensus proposal to NTIA. And I'll state the 
opinion that it's better to identify and understand ALL the issues, not 
just the technical ones; to have a clear idea of what the IETF community 
believes to be desirable outcomes, in clear language (in this case, 
clear contractual language, rather than technical language and 
references to other documents), and to have some idea of how 
negotiations might go (which further suggests a distinction between 
desired outcomes and ideal language vs. minimally acceptable outcomes 
and language). That kind of suggests that IETF's lawyers and 
negotiators, as well as those in the community with such experience, be 
part of the drafting of the IETF proposal to the ICG.

Again, as a matter of personal opinion, I am concerned about how quick 
we have been to water down language, at least in some areas, to near 
meaningless - in what appears to be a fear of confrontation, or 
offending ICANN, or some such.  That's not a good way to go into a 
situation where negotiations and compromises will have to be made.

To the specific issues at hand, that of the iana.org trademark and 
domain registration:

1.If there's a good reason to believe that the transition, and 
post-transition world would be better served by having the iana.org 
trademark and domain registration in hands other than those of the iana 
functions contractor - better to be specific about that, and then hash 
out details with the multiple stakeholder communities as part of the 
upstream ICG process.  If we think the IETF Trust would be a good 
custodian, let's state that, and then see how other communities feel 
about the issue, and if they have counterproposals.

2. Regarding other intellectual property issues - someone (Richard, 
Martin?) just raised the issue of whether the public domain is the right 
model for IETF/registry data.  It strikes me that there are legitimate 
concerns about whether releasing data into the public domain allows for 
too little control, and potentially too much mischief re. how that data 
is used, copied, etc.  There are reasons why most open source software 
is released under a copyright license, not simply published into the 
public domain - it could well be that a carefully crafted copyright 
license (along the lines of GPL, or a Creative Commons license) might be 
more appropriate.  This is one where input from lawyers would be very 
appropriate.

In short, nobody in their right minds (IMHO) prepares a proposal without 
input from subject matter experts in all the relevant areas - why are we?

Miles

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 6 Nov 2014 00:24:43 +0000

> Please send comments to the list.

Dear Colleagues,

I have two suggestions about .ARPA. Apologies for not bringing this up earlier and potentially overlooking previous discussion on list (there are some hints of similar thoughts on the list, but no concrete suggestions for inclusion).

1. Identifying the activity.

CONTEXT:
   >>> Which IANA service or activity (identified in Section I) is
   >>> affected.

   IETF Response: the protocol parameters registries.

OLD:
  IETF Response: the protocol parameters registries.

NEW:
  IETF Response: the protocol parameters registries including the .ARPA domain.
ALTERNATIVE:
  IETF Response: the protocol parameters registries and the .ARPA domain.

MOTIVATION:
Make explicit that the .ARPA domain is an integral part of the IETF side of the plan. The contracts mentions the protocol parameters separately from the .ARPA domain and this intends to avoid confusion upstream. I tend to think of .ARPA domain as being a protocol parameter registry with an alternative publication mechanism, hence the ‘including’ but ‘and’ may be more clear.

The same modification can be made other parts of the document. I leave that trade-off to the editors.

2. .ARPA as an interdependency.

I am less sure about this suggestion than the above.

Context:
  >>>
   >>> A description of any overlaps or interdependencies between your
   >>> communities

A new bullet point that communicates that we rely on the names side of the IANA house for delegation to the parameter operator and that the number communities rely on further delegation (in-addr.arpa and ip6.arpa) could be added?

In addition 

Context:
  To address concerns regarding appropriate contingencies to transition
   to another operator, the IAOC is asked to conclude a supplemental
   agreement that-

you may want to add:

3. requires the redelegation of the .ARPA domain to the subsequent operators.

—Olaf

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 5 Nov 2014 18:04:32 -0800

Yes, .ARPA was left out and needs to be put in.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 5 Nov 2014 21:14:39 -0500

On Wed, Nov 05, 2014 at 07:11:28PM -0500, Miles Fidelman wrote:
> No.. I'm NOT saying some Internet Boss outside the IETF.  I'm saying that
> processes for addressing technical issues are inadequate for dealing with
> issues that go beyond technical issues (kind of sounds like a tautology).

No, it sounds like an assertion about process -- that there's some
sort of quiddity in political issues that make them impenetrable to
rough consensus and running code.  You've presented not a single piece
of evidence for that assertion; neither has anyone else.  I'm weary of
pointing this out.

I'm not a complete moron, despite appearances.  I know that many
processes would require considering different kinds of interest.  But
we're only supposed to be reporting from the community interested in
protocol parameters.  I'm having a very hard time understanding who
exactly we're missing.

> IAOC, rather than deliberate them the way protocol issues are deliberated.

No.  The IETF process for this is to express its views, ensure that
the IAB understands those and ensure that IAB members are sufficiently
attuned to the wider interests, and to ensure that the IAOC has a good
understanding.  

> The IAB and IAOC are part of the IETF, but are not normally part of the
> technical process.

You keep saying that as though these are disjoint groups.  What do you
think Russ, or Eliot, or I do when we go inside the IAB tent?  Forget
everything we know?

> I'll ask the question: why is that a problem, or something to be avoided?
> Most contracts are negotiated.  The MoU, presumably, was negotiated.  The
> NTIA contract that is being replaced was negotiated.

I don't think that there's anything in our current arrangements we
want to lose.  That is what I heard in the IGOVUPDATE and IANAPLAN
BoFs, and I think that's what the charter says.  If you're going to
negotiate, you have to be prepared to give something up.  What is it
that you want to sacrifice for the trademark and domain name?  If
you'll say that, it would help.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: JFC Morfin <[email-masked]>
Date: Thu, 06 Nov 2014 03:17:59 +0100

Dear Leslie,

why not to accept that at this stage no one can 
say what is the scope of the WG, what will happen 
at the end of the day, who should be a 
participant, what are understood or accepted by 
them ... because there is no consensus, too many "beliefs" rather than facts.

And if there was a consensus, it should be 
negociated. Then (next week) a probable counter 
proposition by Russia+China supported by BRICS. 
etc. makes us sure that the status-quo will have 
to be updated. How many Russian, Chinese citizens in this WG?

Why not just to consider our Charter and mission 
statement for what they say and not for what 
ICANN or anyone else may say. In any coming 
***unknown*** political, multilateral, 
multistakeholder, and middleware situation, the 
internet will still have to work and possibly to 
work better. That is the IETF job. We should only 
be interested by that, and incidently to make 
sure ISOC, ICANN, RIRs, ITU, IANA, IUsers, etc. 
etc. have obtained from us the technical capacity 
to help us and our users so they design, use and 
manage the Internet in order that it works better..

My Draft just says that, in the way the charter, 
the NTIA, ICANN say it (look at the text, the 
largest part comes from them). My helpers were 
worried by the cut-off issue. Actually it helps: 
our Draft is a non-IETF one, so it is not bound 
by BCP_78. Nor by any other consensus that our's. 
It is CC BY SA, and if you look at our young site 
we had to set-up to publish the Draft, we can 
start considering there, the real issues of the real world.

As IUsers, we are no lawyers, no politicians, no 
gurus, just Libre developpers and/or 
involved/independent Internet users. And we 
expect only one thing from the IETF: the 
technical capacity to continue to run the digital 
part of our business and life the way we are used 
and  want to do it. i.e. in not being racketed 
anymore by the "ICANN industry", not to be 
subject to an "US jurisdiction", not to be 
"protected by the NSA", not to be worried about 
the Chinese back-doors, not to be involved in the 
Russian strategy and hackers, not to be harassed 
by civil society activists, not to have to be 
concerned by Indian and Brazilian, and etc. and etc. new propositions.

Just to live in digital peace with an "IG proof" 
technology allowing us to be digitally autonomous !.

Either you tell the IETF to focus on that, or we 
will understand you want us to do it by our own. 
No worry, but don't tell us afterward you dont 
like it as you kept telling about NATs.

jfc

At 21:43 05/11/2014, Leslie Daigle (TCE) wrote:

>Miles,
>
>The IAOC needs to know what the IETF wants in 
>order to build the administrative structures to 
>provide it.  In other contexts, the IAOC has 
>been pretty tightly circumscribed to not "invent" things for the IETF.
>
>In that light, I believe the purpose of this 
>working group is to develop consensus around the 
>needs of the community to support the IETF's 
>work and protocols, going forward.     As a 
>developer (of standards, or software using 
>standards), or deployer of networks, or other 
>producer/consumer of technical protocol 
>parameters, what are the requirements of the system post-NTIA transition?
>
>That may not be protocol engineering, but it is 
>a fairly technical task.  It is not defining the 
>form of the final implementation to meet those 
>requirements (lawyering, contracting, etc).   As 
>a technical task, I believe it is possible for a 
>working group format to achieve the outcome.
>
>To your specific points:
>Per the above, I don't believe that is 
>necessary.  Notably, in this group's charter:
>
>That question is outside the scope of this 
>WG.  If you feel it is necessary, I would 
>suggest that you could take it up (in person, or

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 6 Nov 2014 06:08:02 +0000

> "Preponderance of opinion" is not the way the IETF works.  We work by

I know that. Never said it was the way it works. I am simply pointing out to you that your view is far from commanding consensus. 

> I'm not panicking.  Miles is suggesting that there's something _outside_ IETF
> processes -- the IAOC, some lawyers, the IAB, anything
> -- that is appropriately brought to bear here.  I argue that, on the contrary,

I didn't take his message that way. I just thought he was saying it would make sense to involve people with governance, policy and legal expertise more directly in this working group.

> there really _isn't_ anything outside the WG in IETF terms.
> So Miles says, "Well, IETF processes are inappropriate for this, because
> $some_authoritay_not_here."  I agree with him that there isn't some
> external Internet Boss who can decide.  I think that's a feature, not a bug.

We must have read different messages from Miles. I didn't see any calls for an external internet boss there. Nor did I see a claim that IETF processes are inappropriate, because he knows as well as I do that this _is_ and _must be_ an IETF process according to the ICG procedure. I saw him say that we shouldn't misconceive THIS process as being fundamentally about engineering. And he's right. 

> No, I'm saying that is indeed a serious risk, and we ought to worry about it,
> but that meaningless shibboleths (viz. "the domain name where I got this")

Oh man. Do you know how much money has been spent by trademark litigants on those supposedly meaningless shibboleths called domain names that correspond to trademarks? It's probably in the billions. Now we can use two hypotheses to interpret that phenomenon: 
 1) the thousands of people spending this money have a realistic assessment of what it's worth to avoid various forms of confusion or misdirection that can be caused by semantic identifiers; or, 
 2) they are all fools and you know better. 
I'll let the rest of this group decide which hypothesis they think is correct.

> No, I have, but you reject the premise.  I have said that it forces us to
> negotiate with ICANN, potentially giving up something that we want instead
> of this.  You reject the idea that we'll have to negotiate over this, because
> NTIA will simply impose whatever we ask for.  In my opinion, that is a

I do think the NTIA is in a position to require ICANN to provide what the final proposal posits, if it wants the transition to happen. I also think the U.S. Congress, the EC and the rest of the world would not look favorably upon any attempt by ICANN to extort the IETF in some way, and that such disfavor could have severe consequences for ICANN as it moves into the second, "enhanced accountability" phase of the transition. 

Not only have you never provided any evidence that anything like that will happen, you have never explained why, if it does, the IETF can't simply say, 'no' to any unreasonable positions. If you want to be credible, you might start by identifying the 'something we want' that ICANN would be in a position to force you to give up if the transition plan included a requirement that they turn over the trademark and the domain. 

You are also factually incorrect about the source of the names community input. The source is not ICANN the corporation, but an independent and relatively open cross-community working group containing many critics of ICANN concerned about its accountability. Moreover, the names community seems to be entertaining the idea that IANA should be 'separable' from ICANN, too. No one there seems to have any fears that such a request will "force them to bargain with ICANN" and give up their first born son or some other 'something we want.' 

>  I just find it
> implausible that ICANN wouldn't care about this, but I believe that there are
> people busily trying to find out.  If I am wrong, I'll cheerfully withdraw my
> objection.

I think ICANN cares about this, but I think it cares more about making sure the transition happens and continuing to be the home of the IANA. I think most of the community, including ICANN, is coming to accept the position that if it wants to keep the IANA functions it has to be accountable, and that the most important form of maintaining accountability involves the ability to move the IANA functions provider to another entity. So I think it's quite plausible that ICANN would accept the changes demanded as long as there was no demand that it immediately give up the use of the domain and trademark, and it would then work to make sure that the IETF never moved the IANA functions out by providing good service. Fancy that.

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 6 Nov 2014 06:10:17 +0000

> Again, as a matter of personal opinion, I am concerned about how quick we
> have been to water down language, at least in some areas, to near
> meaningless - in what appears to be a fear of confrontation, or offending
> ICANN, or some such.  That's not a good way to go into a situation where
> negotiations and compromises will have to be made.

And these are the same people who scoff at the notion of a 'boss of the internet.' 
;-)

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 6 Nov 2014 07:47:20 +0000

On 11/5/14, 10:10 PM, "Milton L Mueller" <[email-masked]> wrote:

>>we
>>offending

Maybe the scoffing you hear is actually at the notion that our mission
here in the IETF is seriously threatened by uncertainty about the
ownership of some domain name or trademark. We don't need to control
anything like that to do our job. To me, most of the bluster and rhetoric
about this is simply counterfactual, imagining that the IETF does, or
should do, something other that it does.

This is just entirely backward. There is no need for us to negotiate or
compromise with any government or corporation to accomplish our goals.
There is nothing we need that we stand to gain by negotiating or
compromising - but plenty we could lose. Taking us down this path is
reckless and unnecessary.

Jon Peterson
Neustar, Inc.

---

From: John Curran <[email-masked]>
Date: Thu, 6 Nov 2014 08:51:31 +0000

> compromise with any government or corporation to accomplish our goals.

Jon - 
 
   I have no view on whether the IETF should assert any position with 
   respect to intended future use of the IANA marks or domain name (and 
   do understand how asserting a position, absent constructive engagement, 
   could be misunderstood by others in the stewardship transition planning
   process.)

   However, I cannot tell if you are also against any mention of the IETF's
   _present and existing use_ of the IANA marks and domain name in the ICG 
   RFP response...  could you opine specifically on this question?

Thanks!
/John

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 06 Nov 2014 07:32:04 -0500

> reckless and unnecessary.

Perhaps  silly observation, but I should think that someone associated 
with a registrar would well understand the importance of the contracts 
and other agreements that govern the registration of domains, control of 
information, resolution of conflicts (e.g., the UDRP) - and the need for 
a level of specificity and "actionability" in governance related documents.

Miles Fidelman

---

From: Jefsey <[email-masked]>
Date: Thu, 06 Nov 2014 14:08:17 +0100

At 13:32 06/11/2014, Miles Fidelman wrote:
>Perhaps  silly observation, but I should think that someone 
>associated with a registrar would well understand the importance of 
>the contracts and other agreements that govern the registration of 
>domains, control of information, resolution of conflicts (e.g., the 
>UDRP) - and the need for a level of specificity and "actionability" 
>in governance related documents.

Miles,

The matter is not so much how we understand the context, but the way 
we think it is interesting to manage it for each of us. People 
associated with registrars have not the same point of view as those 
associated with registries, and customers of registrars, or those 
wanting to best use the IETF technology and are not really interested 
in registrars and even registries.

The difficulty with this WG is that it associates the cultures of 
people with sometimes converging, sometimes opposing interests. The 
way it is conducted is to try to obtain an ill defined single 
status-quo solution with one single incumbent in a totally changing 
and expanding context does not help. This is an impossible task, as 
the more the context changes, the more newentrants join the game and 
the more there are feed-backs on incumbents. These should be facts: 
as engineers we should be able to modelize and run simulations. But 
we miss two third of the rules: the political and the legal ones.

As a result, this is only discussed by personal views and beliefs 
based on personal cultural feelings. This is emotional engineering.

We are engaged a global solution network process (as per Lynn 
St-Amour and Don Tapscott and their Google, State Department, Royal 
Bank of Canada, MasterCard, Qualcomm, etc. sponsors). Why not to ask 
their Accenture sponsor to contract with the IETF in order to write this draft?

IMHO everyone in this WG is used by every other one. Does not 
simplify the consensus building process.

jfc

---

From: JFC Morfin <[email-masked]>
Date: Thu, 06 Nov 2014 14:46:03 +0100

Dear Colleagues,

Since I have been unexpectedly led to create the 
<http://iuwg.net/>http://iuwg.net site, I intend to activate this 
unplanned WG for an Intelligent Internet Use and to utilize this 
Libre's Internet Use global community representation spark in order 
to competitively foster some technical governance innovations (as per 
RFC 6852).

As such, my priority does change:

- from expecting the IETF to protect the IUsers in taking the lead of 
the technical governance evolution through an update of the 
IETF/WG/IANAPLAN Charter
- to managing our own protection ourselves in cooperation with the 
IETF, ICANN, ITU, USG, BRICS, SCO, EU, NTIA/FCC, etc. strategies.

This is why my appeal to the IESG will focus on the way the IESG 
should provide adequate guidance to the IETF/WG/IANAPLAN Chairs. The 
starting point of this appeal is, therefore, the ongoing reading of 
the "status quo" strategy sponsored by the Chairs, in opposition to 
my own reading of the IETF position expressed in the Charter, of 
which the implications have to be considered better (hence the 
endless debate on issues like iana.org).

This is going to give me more time:

- to extend my draft (now 
<http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf>http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf. 
Taking advantage from Olaf Kolkman remark on BCP 59).
- evaluate the consequences of the Nov 10 IETF/WG/IANAPLAN meeting.
- evaluate the consequences of the Nov 10 Putin-Xi Jinping meeting.
- evaluate the consequences of the ITU PP 14.
- evaluate the first feedback of my draft concerning the network 
master and master model and plug-ins.

I hope that this may eventually lead to a convergence between Eliot's 
Draft and mine. I am aware that it will most probably call for 
IESG/IAB/ISOC involvement since I am not permitted to directly 
discuss it at the [email-masked] last call level.

jfc

---

From: 'Andrew Sullivan' <[email-masked]>
Date: Thu, 6 Nov 2014 09:43:34 -0500

> I know that. Never said it was the way it works. I am simply pointing out to you that your view is far from commanding consensus. 

Right.  "There's no consensus on the topic," is the way I usually
spell that.  Which is, IIRC, what I said in the first place.

> procedure. I saw him say that we shouldn't misconceive THIS process
> as being fundamentally about engineering. And he's right.

Obviously it's not abou engineering.  But the plain meaning of his
words is that we shouldn't use the same procedure we use for
engineering things for non-engineering things, and I disagree.

> Oh man. Do you know how much money has been spent by trademark litigants on those supposedly meaningless shibboleths called domain names that correspond to trademarks? 

I have a small bit of experience about that, yes.  And if you're a
trade mark litigant, you _have to_ spend that money, because your
lawyer told you that your trademark is being diluted, and that's a
problem.  And it could well be that, if you have a brand, people
magically type it into their URL bar and get to your home page, and so
someone else having control over that domain name is a problem.  (Of
course, nobody actually does this any more, and your "URL bar" hasn't
been exclusively for URLs in most browsers for about a billion years
in Internet time.  But never mind that.)  In any case, neither of
those is the problem we have.

The problem we supposedly have, but which proponents of declaring that
we have moral authority over IANA don't seem to want to analyse,
happens just in case there is a separation of the IANA functions and
it happens in an unfriendly manner.  Supposedly under those
circumstances, whoever then controls iana.org is going to set up a
competing protocol parameters registry, and sow confusion all over the
Internet by sending people to ports 35 and 344 instead of 53 and 443.
I claim that the risk of this is impossibly small, and that in the
case of such a dispute anyone who actually cares about protocol
parameters will learn pretty quickly how to get the IETF ones; or
else, that the IETF's legitimacy will be so poor by that point that it
will make no difference what we do because people will already be
using someone else's protocols.  (Given the amount of time we waste on
governance discussions, I'm betting on the latter long before any IANA
split.)  So yes, I believe that iana.org is a meaningless shibboleth.
I don't think that all domain names are, but for this particular
purpose it is one.

> I do think the NTIA is in a position to require ICANN to provide what the final proposal posits, if it wants the transition to happen. I also think the U.S. Congress, the EC and the rest of the wor…

Yet you apparently believe that the IETF can extort ICANN, which is
what is actually being proposed: they have property, and some are
proposing that they have to give it to us without compensation.

> Not only have you never provided any evidence that anything like that will happen, you have never explained why, if it does, the IETF can't simply say, 'no' to any unreasonable positions. If you wa…

You put the burden of proof on the wrong side.  I'm saying, "Do
nothing," you're saying, "Do this," and then you want me to prove that
your proposal is actually going to cost something.  

> I think ICANN cares about this, but I think it cares more about making sure the transition happens and continuing to be the home of the IANA. 

Right.  And as part of "continuing to be the home of the IANA",
surely, it will be better for it if it controls the trademark.  I
cannot see how that is even a little bit controversial.

> I think most of the community, including ICANN, is coming to accept the position that if it wants to keep the IANA functions it has to be accountable, and that the most important form of maintaining accountability involves the ability to move the IANA functions provider to another entity. 

But we already have in the I-D the term that they have to agree to
move the IANA trademark to some other entity in the event the
functions move.  I'm not opposed to that at all, since it appears to
be something they've already agreed to.  But what people seem to want
is something else: that the trademark and iana.org domain name move to
the IETF Trust _even if_ the functions aren't moving.  I don't see any
reason to ask for that, and I don't see why ICANN should agree to it.

Moreover, as someone pointed out upthread, the trademark might have
been obtained as part of a function of a contract with the USG.  If
so, and the usual rules apply, then it may actually be the property of
the USG.  In that case, there's another problem: trasnferring USG
assets around requires legislative action.  I don't think we want to
open that possibility.

Regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 06 Nov 2014 10:24:54 -0500

> engineering things for non-engineering things, and I disagree.

We might be in violent agreement here.  Others, however, have opined 
that these issues are not important, are outside the WG's scope, 
shouldn't be addressed here, should be left to others, and so forth.  
I've been simply stating my opinion that these issues need to be 
addressed as part of preparing the ICG response - either here, or in 
some clearly defined way.

> proposing that they have to give it to us without compensation.

Extort, or force, no.

Identify that control of the iana.org domain is an important 
consideration, and that everyone's life would be easier if control of 
the domain was tied to the accountability and delegation mechanisms 
associated with the authority to oversee, contract for, etc. the iana 
functions contractor - and that there are potential problems if the 
status quo is mainatined - yes.

Suggest that the ICANN ownership of IANA related trademarks and domain 
registrations might be less than appropriate or legitimate, and 
something to be addressed during the transition - maybe. Suggest that 
transition to someone other than the IANA contractor of the moment - 
seems like that's desirable.

Suggest, as a possible transition measure, that the IETF trust is an 
appropriate holder of the IANA and iana.org trademarks, and the iana.org 
domain registration - as one alternative, to be discussed with all the 
other stakeholders as proposals are merged.  Why not? It is certainly 
one reasonable place to locate ownership/control of the IANA 
intellectual property - let others propose alternatives.

> cannot see how that is even a little bit controversial.

Nor should it be controversial to point out that, by holding the 
trademark, it hinders that critical accountability measure - the right 
of other parties to designate some other contractor as the "home of 
IANA" (or, for that matter to assume registry responsibilities directly 
- something that hasn't really been talked about -- note that IEEE, for 
example, is both the standards body and the registry for quite a few 
protocol parameters in the 802.11 space).

> reason to ask for that, and I don't see why ICANN should agree to it.

The main reasons to ask for are:
- to strengthen the accountability measures associated with the option 
of changing IANA contractor
- avoid, proactively, any wrangling and disruptions that might happen 
down the line, if IETF (or others) were to move to transition the IANA 
contractor
- address the possibility that, down the road, there might be different 
IANA contractors for different functions

Asking that the IETF trust be the home of iana.org is a stretch - but 
offering it as one option, and opening the discussion seems reasonable.  
As in...

"The iana.org domain is used to disseminate information related to the 
IANA functions, including protocol parameters, ..... .  In order to 
enhance accountability, enable the possibility of changes in designation 
of IANA Functions Contractor(s), and smooth any transition(s) associated 
with a future change in IANA Functions Contractor(s), we suggest that 
the ownership of IANA related trademarks and other intellectual 
property, including specifically the iana.org domain and registration 
thereof, be transferred to an appropriate 3rd party, and that rules and 
procedures for management, licensing, delegation, etc. of these be put 
in place.  We further offer the IETF Trust as one option of an 
appropriate "home" for these assets."  (Again, I suggest that the 
lawyers be involved in discussion of the intent, implications, and 
wording of such language.)

As to why ICANN should agree to anything: Well, isn't ICANN's basic 
starting point that it simply wants to maintain all its roles, 
responsibilities, and functions - but without an NTIA contract? It's 
going to agree to a lot of things, that aren't ideal (from it's 
viewpoint) before a transition occurs.  Why is what ICANN likes or 
doesn't like even an issue for us?

> assets around requires legislative action.  I don't think we want to

Again, a reason to get the lawyers involved in this discussion.

Personally, I don't THINK this has to require legislation.  I've been 
through a lot of contract negotiations, with the USG, over intellectual 
property rights.  For DoD, at least, the baseline ownership of rights is 
set by law, and then by the DFARs - but a lot of it is negotiable, and 
contracting officers have a lot of room when it comes to patents and 
trademarks - as long as the government ends up with "government purpose 
rights" to anything it pays for. In some cases, even then there are 
limits (for example, under SBIR contracts, only the agency that funds 
the SBIR ends up with a license to use software developed with SBIR 
funding - at least that was the case the last time I was involved).

Miles Fidelman

---

From: Jefsey <[email-masked]>
Date: Thu, 06 Nov 2014 16:30:51 +0100

>proposing that they have to give it to us without compensation.

Andrew,

All this has actually been addressed by the NTIA (Karen Rose) and 
signed 14 years ago.
Please read my draft version 01. 
http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf.
This is probably where the confusion introduced by Fiona Alexander comes from.

This is BCP 52. The problem is not with ICANN but with the IETF.
- RFC 3172 section 3 should be reminded to participants, WG Chairs, 
RFC authors, ADs
- RFC 3172 Section 5 to the IAB (e.g. Russ Housley Liaison statement 
of 2014/09/15 - https://datatracker.ietf.org/liaison/1351).

Best
jfc

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 6 Nov 2014 16:55:06 +0100

Dear Andrew,

Please see responses and questions below.

Thanks and best,
Richard

> Sent: jeudi, 6. novembre 2014 03:15
> To: [email-masked]
> rough consensus and running code.

Not impenetrable, but inappopriate.  Political issues should be decided by
democratic processes, meaning either directly by the people or by freely
elected representatives of the people.  That's not just my opinion, it is
international law enshrined in the UN Declaration of Human Rights and the
International Covenant on Civil and Political Rights. And in numerous
national constitutions.

Democratic processes involve formal accountability, unlike rough consensus.
Note that I have no problems with rough conensus for certain issues, I just
don't think that it is appropriate for political issues.

In rough consensus, the chairs have considerable leeway to determine what
the consenus is, and there are limited appeals mechanisms.  In formal
systems, the consensus (or lack of it) is tested through formal votes.
Voting is obviously not possible in the IETF, because there are no members.
And, again, that's fine for some things, but not other things.

In my opinion, a variant of "rough consensus" also exists in the political
sphere, it is called "autocracy".  When people don't like the decisions made
by the rulers, they cannot vote, but they can, if it gets bad enough,
revolt.  And that's not just theory, it actually happens.

The equivalent in IETF, as you and others have pointed out, is that people
will not use the IETF standards.  That is, if the IETF leadership gets a
"rough consensus" call wrong, then the market will let them know.

But that's typically not possible, or at least not desirable, for political
issues, hence the general agreement that the preferred method to make
political decisions is democracy (as defined above).

>You've presented not a single piece

Does the above help?

>
> I'm not a complete moron, despite appearances.

You certainly do not appear to me to be a moron.  On the contrary, you
appear to me to be intelligent, well-informed, articulate, and determined.
Same as other people on this list.

>I know that many
> protocol parameters.

Yes, but, in line with the request from NTIA, that includes the "global
multi-stakeholder community", which is broader than the people who are
involved with protocol parameters on a daily basis.

>I'm having a very hard time understanding who
> exactly we're missing.

As I recall, the point was made that some legal advice might be in order.
For example, regarding whether "public domain" is the appropriate status for
the actual data.  I'm very comfortable with public domain for the data, but
I'm a bit of an extremist when it comes to intellectual property (I'm a
member of the Pirate Party), so I can understand why others might want some
expert advice on alternatives.

> deliberated.

I agree.  So I think that we are only disagreeing regarding the level of
specificity that is appropriate and desirable.  In my view, we should
specify clearly what we think should happen regarding the intellectual
property, which includes the actual data, the mark, the domain name, and
maybe other items (but I cannot think of any).

> negotiate, you have to be prepared to give something up.

I still get lost when people mention negotiating.  What are the parties to
the negotiation?

This process is an ICANN process.  The output will be sent, on behalf of
ICANN, to the NTIA.  ICANN surely is not going to negotiate with itself.  So
who are the parties to the negotiation?

> What is it

Why would anybody have to sacrifice anything?  Again, it is ICANN that would
propose to the NTIA that the intellectual property be handled in this and
this way.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 6 Nov 2014 15:54:31 +0000

>   RFP response...  could you opine specifically on this question?

I'm totally fine with detailing the IETF's present and existing use of the
IANA - we would be kind of missing the point of the questionnaire if we
didn't. And I think it would be great if that relationship continued along
past lines. I am only pushing back against the notion that this IETF
response to the ICG should take some ideological or "moral" stance about
the ownership of domains or trademarks. I believe the justifications
offered in support of this move both misunderstand and endanger the role
of the IETF.

Jon Peterson
Neustar, Inc.

---

From: John Curran <[email-masked]>
Date: Thu, 6 Nov 2014 16:10:15 +0000

On Nov 6, 2014, at 3:54 PM, Peterson, Jon <[email-masked]> wrote:
> didn't.

Agreed.

> And I think it would be great if that relationship continued along
> past lines.

I think it would be great if cooperation in the use of the domain name 
and marks (to serve multiple communities) was achieved even absent NTIA's 
present IANA stewardship; how do you proposed this should be achieved?

/John

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 6 Nov 2014 17:11:03 +0100

> From: Ianaplan [mailto:[email-masked]]On Behalf Of 'Andrew
> Sullivan'
> Sent: jeudi, 6. novembre 2014 15:44
> To: [email-masked]

SNIP

> engineering things for non-engineering things, and I disagree.

OK.  Let's agree to disagree because, as indicated in my previous message, I
don't think that the IETF procedure is necessarily the best procedure to use
for all issues.

SNIP

> competing protocol parameters registry,

That's not what I said.  What I said is that the new IANA functions
operators would not immediately and easily be able to use the mark and the
domain name IANA.ORG, and that that would create some confusion and
disruption.  We probably disagree regarding the significance of the possible
confusion and disruption.

>and sow confusion all over the
> parameters will learn pretty quickly how to get the IETF ones;

Yes.  The question is whether it is worth taking steps now to minimize the
possible disruption.  In my view, the steps required now are minor and
zero-risk, and thus worth taking.  Apparently you disagree.

SNIP

>
> Yet you apparently believe that the IETF can extort ICANN,

Again, I am lost.  ICANN has mandated the ICG to prepare a proposal, and the
ICG has mandated the IETF to prepare part of that proposal.  The final
proposal will be ICANN's proposal, so nobody is extorting anything from
anybody.

>which is

As others have pointed out, ICANN took it from others without compensation.
And there was nothing wrong with that: nobody complained, and the previous
owners did not request compensation.  Apparently it made sense in the
context of the creation of ICANN.

Similarly, we are here proposing that ICANN pass the property in question on
to some other entity, without compensation, because that is what makes sense
in the context of the transition.

SNIP

> And as part of "continuing to be the home of the IANA",

You seem to be thinking that ICANN is separate from this process.  As I've
tried to explain before, the purpose of this process is to prepare the
proposal that the ICG, on behalf of ICANN, will present to NTIA.

So what ICANN thinks about what is better for it will be what is in the
proposal.  That is, the proposal will reflect what ICANN thinks should be
done.

> be something they've already agreed to.

I have no objections to the current language in "02."

>But what people seem to want
> the IETF Trust _even if_ the functions aren't moving.

I was under the impression that some people would prefer to change the
current language in "02".  If that is the case, then I propose alternative
language.

>I don't see any

Again, the proposal that the ICG will present will be ICANN's proposal, so I
fail to see how ICANN could disagree with what it itself proposes.

> the USG.

Somebody posted to the list the trademark record.  The trademark belongs to
ICANN.

And I'm not aware of any contracts between the US government and ICANN that
relate to the trademark.

>In that case, there's another problem: trasnferring USG

Can you point us to any evidence that this might be required?  As noted
above, I have not seen any.

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 06 Nov 2014 11:19:22 -0500

> offered in support of this move both misunderstand and endanger the role

Speaking just or myself - I am purely interested in the practicalities 
of the matter regarding operational control of the iana.org domain, and 
editorial control of intellectual property associated with performing 
the IANA functions.

More specifically, I'm concerned with avoiding any confusion or 
operational disruption in the event of future conflicts among the 
parties involved in oversight, management, and/or performance of the 
IANA functions - particularly in the case where a transition of 
contractor might occur on less then friendly terms.

Under such situations, it seems at least possible, if not likely, that 
litigation might ensue and/or that parties might operate competing 
registries - causing operational confusion at a minimum, and possibly 
more serious disruptions to smooth operation of the net.

 From my perspective, it seems that placing ownership/legal control of 
IANA intellectual property, including registration of the iana.org 
domain, in the hands of a party other than the incumbent contractor, 
seems like the mechanism least subject to disruption in the event of a 
transition.  Whether that party is the IETF Trust, a joint entity 
created by the major stakeholding organizations, or something else, is 
less important - the IETF Trust has the advantage of being an existing 
entity, but that is solely a matter of convenience.

None of this has nothing to do with ideology or morality - other than, 
perhaps, a strong belief in outside accountability measures that have 
teeth, which, one could argue has both ideological and moral components.

Respectfully,

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 06 Nov 2014 11:25:17 -0500

> present IANA stewardship; how do you proposed this should be achieved?

Cooperation is great, until it fails.  Isn't the point of clear 
understandings (particularly in contracts) to avoid confusion that might 
lead to lack of cooperation, and to deal with situations where 
cooperation fails, in a smooth a way as possible?  Clarity in advance is 
generally a good way to avoid a lot of the pain when cooperation fails - 
the more wiggle room in a contract (or MoU, or protocol spec, or what 
have you) - the more room for folks working at cross purposes, and for 
drawn out litigation when things go drastically wrong.  (Granted that 
too much specificity can also be a straightjacket that impinges on 
day-to-day flexibility among cooperating parties - also something to be 
avoided.)

Miles Fidelmn

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 6 Nov 2014 16:37:36 +0000

Andrew, this is still a substantive debate, so I hope others arent' tiring of our interaction. See below:

> I claim that the risk of this is impossibly small, and that in the case of such a
> dispute anyone who actually cares about protocol parameters will learn
> pretty quickly how to get the IETF ones; or else, that the IETF's legitimacy will

I think it's naïve to think that the risk is impossibly small, especially when the cost of finding out via an 'experiment' forced on the IETF at a moment of crisis would be quite large. I think that point has been made before, so let's move on.

> Yet you apparently believe that the IETF can extort ICANN, which is what is
> actually being proposed: they have property, and some are proposing that
> they have to give it to us without compensation.

Whoa. It is completely invalid to call a final ICG proposal that was developed by the entire community, is endorsed consensually by all 3 operational communities, has survived one or more public comment periods, and is accepted by the NTIA  - as a kind of extortion, especially when ICANN itself was fully represented in the development of the proposal and had the ability to publicly comment on it. 

You need to get a grip on the reality of this process; it is highly public, highly political, the whole world is watching, etc., etc. The idea that ICANN could undermine a consensus ICG proposal by bargaining with IETF and ask for nasty things IETF did not want to give them just lacks basic plausibility. I think you'd better give up on that line of argumentation.
 
> You put the burden of proof on the wrong side.  I'm saying, "Do nothing,"
> you're saying, "Do this," and then you want me to prove that your proposal
> is actually going to cost something.

You're saying "do nothing to avert an obvious problem" in order to avoid an "unnamed and undescribed threat." I'm not buying that. I repeat: tell us what you think the threat is, or might be, or stop making that claim.

> Right.  And as part of "continuing to be the home of the IANA", surely, it will
> be better for it if it controls the trademark.  I cannot see how that is even a
> little bit controversial.

The controversy is not about whether that is ICANN's preference. The controversy is about the extent to which ICANN is able to unilaterally dictate the terms of the transition. Lots of things are going to happen in the next two years that do not conform to ICANN's first preference. ICANN itself knows and accepts that, and if you want proof just look at the difference between what ICANN first proposed for the ICG process (briefly, a steering committee appointed by the CEO and GAC chair and whose output needed to be endorsed by the board) and what we ended up with (a coordinating committee appointed directly by community entities whose output does not have to be endorsed by the board). How did that happen? Whose first-born daughter was sacrificed as a result?

> But we already have in the I-D the term that they have to agree to move the
> IANA trademark to some other entity in the event the functions move.  I'm

And that's good, I am glad we agree on that. 

> I'm not opposed to that at all, since it appears to be something they've already
> agreed to.

There is no documentation or proof of that agreement. The I-D is too weak, it does not specifically mention the domain or the trademark. That means that in the event of a disagreement or rupture, we are have needlessly created all the conditions for a costly legal wrangle. 

> been obtained as part of a function of a contract with the USG.  If so, and the
> usual rules apply, then it may actually be the property of the USG.  In that
> case, there's another problem: trasnferring USG assets around requires
> legislative action.  I don't think we want to open that possibility.

Please, stop the amateur lawyering. There is an official trademark registry and here it is. 
http://tmsearch.uspto.gov/bin/showfield?f=doc&state=4805:o861h2.2.7 

The owner of the IANA tm is ICANN. This is not a debatable fact. Raising the red herring of legislative action makes it appear as if you are pulling out all the stops to create FUD about a simple, feasible request. Can you tell us any more about why you don't want that to happen?

---

From: John Curran <[email-masked]>
Date: Thu, 6 Nov 2014 16:37:45 +0000

On Nov 6, 2014, at 4:25 PM, Miles Fidelman <[email-masked]> wrote:

> Cooperation is great, until it fails.  Isn't the point of clear understandings (particularly in contracts) to avoid confusion that might lead to lack of cooperation, and to deal with situations where cooperation fails, in a smooth a way as possible? ...

Yes, hence why I asked Jon how he proposes having "the relationship continue 
along past lines"...  It is not at all clear if that this would occur in any 
post-NTIA scenario, particularly if we look long-term (as stewards of this system)
and consider potential of future unaligned changes in IANA operators for the 
various communities.

I was hoping that Jon would have chance to answer the question that I asked, 
since we have not yet heard what he proposes here, and already have a strong 
understanding of what arrangements you propose to address this issue.

/John

Disclaimer: My views alone.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 06 Nov 2014 08:40:03 -0800

Hi John,

On 11/6/14, 8:10 AM, John Curran wrote:
> and marks (to serve multiple communities) was achieved even absent
> NTIA's present IANA stewardship; how do you proposed this should be
> achieved?

On the whole through shared goals and values which have served us so
well in the past.  However, we need to leave open the possibility that
something will go wrong for reasons that today we cannot fathom.  One
form of sharing is what we have today.  Are there other forms of
sharing?  Here I largely agree with Alissa: that is more a matter for
the IAOC to explore.  Our requirement is seeing that people get properly
directed to the registries that the IETF has told them to go to through
our documentation.  Off the top of my head I can think of several
structural arrangements to satisfy that requirement.  But I am quite
happy IAOC to "take it from here".

I will have a proposal for Monday on how to resolve this issue.  It is
very much along the lines that Alissa proposed and I agreed to.  I hope
it meets with this group's acceptance.

Eliot

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 06 Nov 2014 12:08:42 -0500

> happy IAOC to "take it from here".

And that brings us back to the procedural question that remains unanswered:

- Is the final IETF proposal, to the ICG, going to be the document 
generated by this WG, or,
- Is the WG draft going to be massaged by others (including the IAOC) 
before delivery to the ICG?

I may have missed it, in which case I apologize to all, but I still 
can't recall seeing a clear, definitive, statement of how we get from a 
WG final document to an "official" response delivered to the ICG.

Either way, it's not an open process for the IAOC to "take it from there."

Personally, I'd be a lot more comfortable to have the IAOC input 
reflected in this WG, either through direct discussion, or through 
review and comment on the various drafts.

> it meets with this group's acceptance.

Looking forward to it!

Miles Fidelman

---

From: Eliot Lear <[email-masked]>
Date: Thu, 06 Nov 2014 09:15:35 -0800

Hi Miles,

> before delivery to the ICG?

Our charter does not require us to conclude explicit agreements.  It
requires us to state our requirements, and then let the IAOC do its job
to meet those requirements.  I think the ICG response needs to indicate
what requirements need to be met, and perhaps even how they have been
met, if that happens in time.

In fact you laid out a perfect path that I had borrowed from in one of
the revisions:

1.  State what is required
2.  Express as a transition need that the requirement be satisfied.

How detailed we get in requirements is always a good question, but as
far as the NTIA is concerned, so long as they can see that the
requirement has indeed been addressed, and they can come back to us to
ask, then that should suffice.  As Jon Peterson and Cullen Jennings have
pointed out, some wiggle room is helpful, and dare I say productive. 
But what we must do here is state what we need, and there needs to be
sufficient clarity so that the IAOC can do its job.  I think that's
where Alissa's text comes in...

Eliot

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 6 Nov 2014 17:18:48 +0000

>On Nov 6, 2014, at 3:54 PM, Peterson, Jon <[email-masked]>
<snip>
>present IANA stewardship; how do you proposed this should be achieved?

What I meant by "the relationship continuing along past lines" is that we
continue to have the good people at the IANA manage our protocol
parameters as we have in the past (like, along the lines of RFC2860, which
doesn't call out the NTIA in any way I can recall). If for some reason
that becomes untenable, though, it isn't the end of the world - and it is
not a contingency that I believe requires us to seek powers and
responsibilities the IETF has not historically possessed or even coveted.

That doesn't speak to your multiple communities, but this ICG response is
the IETF's response. A winning overall transition strategy is, thank
goodness, a problem way above my pay grade. I am only in this thread to
advocate against the IETF demanding the reassignment of various corporate
assets, or trying to compel major world governments to do this or that. As
Eliot notes, the "requires the transfer" language in -02 is already being
amended by he and Alissa, and I have every expectation I'll be happy with
the result. If this remains controversial on the list, I will continue
trying to persuade others here that we don't need to annex property and
transform the IETF into a new "techno-political" body or what have you in
order to weather this transition.

Jon Peterson
Neustar, Inc.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Nov 2014 06:36:00 +1300

> Yes, .ARPA was left out and needs to be put in.

I'll be picky. .ARPA is one of the technical exceptions to the
policy issues and is therefore already included in the term "protocol
parameters registries." So if you want to mention it, it
should definitely be

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Nov 2014 06:56:32 +1300

> offered in support of this move both misunderstand and endanger the role

Exactly. Ever since Lewis Carroll dissected the difference between
words and meanings, logicians and computer scientists have understood
that names don't actually matter. So we would be foolish to make this
a 'sine qua non'. Factually, it would be inconvenient and costly
to change the domain name, and we can certainly point that out.

    Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 6 Nov 2014 13:05:12 -0500

On Thu, Nov 06, 2014 at 03:54:31PM +0000, Peterson, Jon wrote:
> IANA 

In my opinion, such detail is already there.  But if people have
specific words in mind intended to make that clearer, I'm certainly
not opposed to that in principle.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 06 Nov 2014 13:33:03 -0500

> not opposed to that in principle.

That's where I'd really like to see some legal opinion as to clarity of 
wording.  It strikes me that something at least as clear and specific as
ICANN's Uniform Dispute Resolution Procedure for domains -- as to under 
what circumstances, who does what to who as regards to IANA IP and the 
iana.org domain.

Or at least, a very clear statement of what we think is necessary in the 
final-final proposal that goes to NTIA.  (I believe I made a stab at 
such words a couple of messages back - but, as the saying goes, IANL).

Miles

---

From: Jefsey <[email-masked]>
Date: Thu, 06 Nov 2014 19:43:44 +0100

So, even geniuses can be erroneous.

".arpa" is a IANA function managed by the IAB and operated by the 
IANA operator under RFC 2960 Section 4.3. where all the IANA/IETF 
infrastructural names should be migrated.

Chairs committed that this WG would consider the other communities' 
proposals, including my Draft. I cannot do anything to force anyone 
to discuss it, but as it is an other community's proposal it will be 
forwarded independently to the ICG, to the NTIA and to the multiple 
political stakeholders. It would be sad it would be alone in 
promoting the existing IETF solution because an entire WG of leaders 
simply ignore the IETF standardization process modalities.

Anyway, the Libre Intelligent Internet Use global community of my 
local (IEN 48 meaning) surroundings, will use the experience gathered 
by Mike Robert at ICANN, including ICP-3 and the RFC 3172 agreement, 
as indicated in its 
http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf.

Best
jfc

---

From: John Curran <[email-masked]>
Date: Thu, 6 Nov 2014 22:04:03 +0000

> not opposed to that in principle.

Excellent.

One option would be to add a sentence after the list of bullets that
presently end the Section I "Description of Community’s Use of IANA 
Functions" draft RFP response text, i.e. further elaboration of the 
'overlaps or interdependencies between your IANA requirements and 
 the functions required by other customer communities'...

Example text -

'The IETF community presently accesses the protocol parameter registries 
 via references based on iana.org domain name, and makes use of the term
"IANA" in the protocol parameter registry processes [RFC5226].' 

/John

---

From: Richard Hill <[email-masked]>
Date: Thu, 06 Nov 2014 23:09:16 +0100

I'm ok in principle with what Eliot says below and I look forward to seeing the new text. 

Best Richard

On November 6, 2014 6:15:35 PM CET, Eliot Lear <[email-masked]> wrote:
>------------------------------------------------------------------------
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 06 Nov 2014 14:21:12 -0800

Andrew,

> negotiate, you have to be prepared to give something up.

How about our agreement on the plan, going forward?  This is a
reasonable request so long as we do not overreach.  We have a convincing
and classic business continuity argument.  I think Alissa's point is
also that we be careful to not overreach. And again, I am happy for the
IAOC to grapple with matter so long as we have clearly stated our
requireements.

Eliot

---

From: Milton L Mueller <[email-masked]>
Date: Fri, 7 Nov 2014 17:11:35 +0000

> From: Peterson, Jon [mailto:[email-masked]]

Logically, I cannot make any sense of your statement here.  

You are just assuming the truth of the exact claim that is under dispute: namely, that asking for transfer of the domain and trademark would lead to some kind of negotiation with ICANN in which unspecified 'bad things' would be demanded in return.

We still don't have any concrete evidence for this claim. We don't even have any idea what kind of 'bad things' are being talked about. 

QED
--MM

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 7 Nov 2014 18:51:46 +0000

Asking for a transfer sounds like a polite thing to do. Directing the IAOC
to "conclude a supplemental agreement" which "requires the transfer of any
associated marks and identifiers" - as the -02 text of the document reads
- sounds to me like an ultimatum which would antagonize other
stakeholders. But even that language is too weak for some on this list,
who apparently believe we should preemptively seize those assets ourselves
(in the name of the IETF Trust or ISOC) by appealing directly to the NTIA.
I'm sure that wouldn't step on anybody's toes, right. So forgive me if I
deem your characterization below to be a watered-down misconstrual of the
actual positions being advanced in the current text and on the list.

I think it is perfectly reasonable for us to express that the current
situation (i.e. RFC2860) works today and would likely work in the future.
I'm sure the ICG and NTIA would understand the implications of that for
the way forward. I don't know if we need to make any "ask" here, though,
because if we can't go forward with something roughly like RFC2860, then
we'll just do something else for our future work - it isn't that big a
deal. Making an "ask" awards power to the people we're asking. But I don't
think we need anyone's blessing to do our job.

Jon Peterson
Neustar, Inc.

On 11/7/14, 9:11 AM, "Milton L Mueller" <[email-masked]> wrote:

>You are just assuming the truth of the exact claim that is under dispute:
>namely, that asking for transfer of the domain and trademark would lead
>to some kind of negotiation with ICANN in which unspecified 'bad things'
>would be demanded in return.
>
>We still don't have any concrete evidence for this claim. We don't even
>have any idea what kind of 'bad things' are being talked about.
>
>QED
>--MM
>
>
>
>

---

From: Milton L Mueller <[email-masked]>
Date: Fri, 7 Nov 2014 20:26:36 +0000

> Asking for a transfer sounds like a polite thing to do. Directing the IAOC to
> "conclude a supplemental agreement" which "requires the transfer of any
> stakeholders.

OK. I see the difference in the attitude with which we approach this. I am beginning to think it is a purely attitudinal matter and not all that substantive. So I have more sympathy for your position now but I still think you are focusing on the wrong things.

A request to the IAOC to "conclude an agreement" that "requires the transfer" is not an "ultimatum" it is a proposal for a rather impersonal set of institutional changes that sets the stage for long-term accountability improvements in Internet governance. 

To put it more concretely, we are not talking to "nice people" sitting across the dinner table from us, asking them to pass the salt. We are trying to set the parameters for long term interactions among impersonal organizational entities and functions. 

So if I were you I would focus on whether it is a good idea - for the general good of the Internet and for the IETF - for to have control of the iana.org domain and the trademark in the hands of the IETF trust or whether it is better for the public and the IETF to have it in the hands of ICANN. That's all that matters. The purpose of this exercise is to rearrange the institutional design to accommodate the withdrawal of the NTIA. The purpose is not to be polite or nice, or to avoid offending anyone. The purpose is to get it right. 

If you sincerely believe that IETF should be permanently locked in to ICANN as IANA provider, should have no choice as to who performs those functions for it, and therefore the marks and domain should stay with ICANN, then fine. Please argue that position. I will engage with those arguments respectfully. But please let's not argue about etiquette!

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Nov 2014 10:50:58 -1000

Richard,

> As others have pointed out, ICANN took it from others without compensation.

Could you provide your evidence to back up this accusation of theft?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Nov 2014 10:55:23 -1000

Milton,

On Nov 6, 2014, at 6:37 AM, Milton L Mueller <[email-masked]> wrote:
> It is completely invalid to call a final ICG proposal that was developed by the entire community, is endorsed consensually by all 3 operational communities, has survived one or more public comment periods, and is accepted by the NTIA  - as a kind of extortion, especially when ICANN itself was fully represented in the development of the proposal and had the ability to publicly comment on it. 

I was told ICANN staff on the ICG are forbidden to speak unless in response to a question.  Was I told incorrectly?

Thanks,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Nov 2014 10:59:37 -1000

Miles,

On Nov 6, 2014, at 6:19 AM, Miles Fidelman <[email-masked]> wrote:
> More specifically, I'm concerned with avoiding any confusion or operational disruption in the event of future conflicts among the parties involved in oversight, management, and/or performance of the IANA functions - particularly in the case where a transition of contractor might occur on less then friendly terms.
> 
> Under such situations, it seems at least possible, if not likely, that litigation might ensue and/or that parties might operate competing registries - causing operational confusion at a minimum, and possibly more serious disruptions to smooth operation of the net.

We're talking about the protocol parameter registries, right?

I'm honestly curious: could you describe the "serious disruptions to smooth operation of the net" or "operational confusion" that would occur in the event of future conflicts relating to the IANA trademark and/or IANA.ORG domain?

Thanks,
-drc

---

From: Seun Ojedeji <[email-masked]>
Date: Fri, 7 Nov 2014 22:16:20 +0100

Have been following the discussions and it's been quite interesting; much
more interesting that it almost seem iana.org ownership is the deciding
factor in this process[1]. The extent of back and fourth deliberation on
the list, makes me wanna mention here that it will be good for IETF to
start handling/addressing issues not only as a protocol parameter community
but as the overall source of all the whole function.
For all it's worth, those who don't want to complicate the outcome of this
process have great hope in IETF playing a leadership role in all these. I
am beginning to wonder if this is the case.

Thanks.

Returning back to listening mode. ;)

Cheers!
1. Which IMO should just be a minimal component in this process especially
as ntia is not the owner of the domain in the first place.
sent from Google nexus 4
kindly excuse brevity and typos.
On 7 Nov 2014 21:26, "Milton L Mueller" <[email-masked]> wrote:

> OK. I see the difference in the attitude with which we approach this. I am
> beginning to think it is a purely attitudinal matter and not all that
> substantive. So I have more sympathy for your position now but I still
> think you are focusing on the wrong things.
>
> A request to the IAOC to "conclude an agreement" that "requires the
> transfer" is not an "ultimatum" it is a proposal for a rather impersonal
> set of institutional changes that sets the stage for long-term
> accountability improvements in Internet governance.
>
> To put it more concretely, we are not talking to "nice people" sitting
> across the dinner table from us, asking them to pass the salt. We are
> trying to set the parameters for long term interactions among impersonal
> organizational entities and functions.
>
> So if I were you I would focus on whether it is a good idea - for the
> general good of the Internet and for the IETF - for to have control of the
> iana.org domain and the trademark in the hands of the IETF trust or
> whether it is better for the public and the IETF to have it in the hands of
> ICANN. That's all that matters. The purpose of this exercise is to
> rearrange the institutional design to accommodate the withdrawal of the
> NTIA. The purpose is not to be polite or nice, or to avoid offending
> anyone. The purpose is to get it right.
>
> If you sincerely believe that IETF should be permanently locked in to
> ICANN as IANA provider, should have no choice as to who performs those
> functions for it, and therefore the marks and domain should stay with
> ICANN, then fine. Please argue that position. I will engage with those
> arguments respectfully. But please let's not argue about etiquette!
>

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 07 Nov 2014 16:34:02 -0500

> Could you provide your evidence to back up this accusation of theft?

Nobody said theft.  At one point I think I said "staked a claim." 
Different thing.

What's been questioned is the process by which ownership/control of the 
IANA trademark and iana.org domain ended up with ICANN - given that they 
were first used by ISI, and nominally at the behest of US Government.

My guess is that this was just done as a matter of operational 
expedience, that has taken us into the realm of "possession is nine 
tenths of the law."

The question on the table is one of where is the most effective place 
for such ownership and control to lie in a post-transition world.

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 07 Nov 2014 16:42:10 -0500

> I'm honestly curious: could you describe the "serious disruptions to smooth operation of the net" or "operational confusion" that would occur in the event of future conflicts relating to the IANA t…

Kind of depends on the degree to which various developers depend on the 
various registries published under iana.org, and perhaps on the degree 
to which anybody relies on automatic download of registry contents.

For example, the /etc/services file in Debian includes this statement:
#Updated from http://www.iana.org/assignments/port-numbers

I expect other operating systems do similar things.  A lot of systems 
could break, rather precipitously, if iana.org went offline, or the file 
were moved somewhere else, or the file were corrupted - particularly if 
it happened just before a major release cycle.

To me, that would be a "serious disruption" or at the very least 
"operational confusion"

Miles Fidelman

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 7 Nov 2014 22:00:27 +0000

On 11/7/14, 12:26 PM, "Milton L Mueller" <[email-masked]> wrote:

>general good of the Internet and for the IETF - for to have control of
>the iana.org domain and the trademark in the hands of the IETF trust or
>whether it is better for the public and the IETF to have it in the hands
>of ICANN. That's all that matters. The purpose of this exercise is to

I get that you believe ICANN shouldn't own iana.org and that someone else
should, but you're barking up the wrong tree when you nominate us for the
job. Ownership of the iana.org domain doesn't matter very much to the
IETF. We don't need to own it to use IANA, given that we don't own it and
we use IANA today. If for some reason we couldn't continue to use IANA the
way we do today (and I'm only talking about the protocol parameters here),
we as the IETF would just do something else for protocol parameters that
would serve our needs as an organization.

I am sympathetic to your dedication to an open Internet, and I understand
that your advice here is intended to further those beliefs we share. The
real gulf between us is that you are placing your faith in politics, and I
am placing mine in engineering. When you worry over contingencies, you
think the IETF needs to seek the protections of careful "institutional
design" to retain our powers. I give us better odds if we instead engineer
around potential failures, because the people who self-select to
participate in the IETF are experts in engineering, not politics.

We should answer the ICG and continue to work with existing partners in
the multistakeholder model, but what is paramount to us is the flexibility
to innovate as we see fit - that is the crux of an open Internet, and
where the true power of the IETF lies. I don't think owning iana.org would
protect us from anything I worry about, but insisting on it would alienate
our partners and, should we succeed, ultimately leave us with a bunch of
powers and responsibilities which are extraneous to our job.

>arguments respectfully. But please let's not argue about etiquette!

... again, this is absolutely backward. The protocol parameter registry
exists because we choose to populate it. If circumstances alter to a point
where we don't want to use it anymore, then it will have no value to
anyone, because we'll be populating something else. That's why I have
confidence that the stewardship of IANA will remain aligned with our
needs. The only way we will get "permanently locked in" to anything here
is to lobby for some ossified "institutional design" that awards IANA or
any other component of our model an undue permanence in our processes. I
do believe you are advocating in good faith here to prevent a bad outcome,
but the path you suggest leads us somewhere even worse.

Jon Peterson
Neustar, Inc.

---

From: Seun Ojedeji <[email-masked]>
Date: Fri, 7 Nov 2014 23:06:44 +0100

Miles, it think you are referencing that url as if the operating systems
services are syncing off the iana.org site.
If that domain changes today, it does not take anything other than a update
to reflect the new reference url does it?
What would be disastrous is if there happens to be 2 authoritative
parameter source with different entries; as an example http referenced as
port 80 and as another port on the other site.

How to avoid that is not just by locking up the name iana.org but by
locking up to a single source of authority.

Cheers!

sent from Google nexus 4
kindly excuse brevity and typos.
On 7 Nov 2014 22:42, "Miles Fidelman" <[email-masked]> wrote:

>>> operational disruption in the event of future conflicts among the parties
>>> involved in oversight, management, and/or performance of the IANA functions
>>> - particularly in the case where a transition of contractor might occur on
>>> less then friendly terms.
>>>
>>> registries - causing operational confusion at a minimum, and possibly more
>>> serious disruptions to smooth operation of the net.
>>>
>> I'm honestly curious: could you describe the "serious disruptions to
>> smooth operation of the net" or "operational confusion" that would occur in
>> the event of future conflicts relating to the IANA trademark and/or
>> IANA.ORG domain?
>>
>>
>>
> various registries published under iana.org, and perhaps on the degree to
> which anybody relies on automatic download of registry contents.
>
> were moved somewhere else, or the file were corrupted - particularly if it
> happened just before a major release cycle.
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 07 Nov 2014 14:08:45 -0800

Hi,

> would serve our needs as an organization.

If you believe that the IAOC is in fact to resolve our requirements into
solutions and if we conclude that there is a requirement for backward
compatibility, then arguing that IANA.ORG MUST NOT be transferred is as
invalid as arguing that it MUST.

Eliot

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 7 Nov 2014 22:19:47 +0000

Heh. I am not insisting that iana.org MUST NOT be transferred to the IETF
Trust. Honestly, I think it would be a hassle for us at the end of the
day, but if for some reason that is the best outcome for the Internet
community, there would be no grounds to prohibit it. I'm just saying that
for the purposes of this document, I don't want our ICG response to ask
for it, and certainly not to demand it.

Jon Peterson
Neustar, Inc.

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 07 Nov 2014 17:22:31 -0500

Seun,

Seun Ojedeji wrote:
>
> Miles, it think you are referencing that url as if the operating 
> systems services are syncing off the iana.org <http://iana.org> site.
>

I doubt that the o/s is syncing in real time.  I wouldn't be surprised 
though, if, at build/packaging time, the build system does a lookup 
against the iana.org site.  I wouldn't be surprised if other iana.org 
paramter registries are used in similar ways.

> If that domain changes today, it does not take anything other than a 
> update to reflect the new reference url does it?
>

If the URL changes, then auto-build systems will break - and people will 
end up having to figure out what happened, and fix it.  That's 
"disruptive" in my book.

> parameter source with different entries; as an example http referenced 
> as port 80 and as another port on the other site.
>

exactly!

> How to avoid that is not just by locking up the name iana.org 
> <http://iana.org> but by locking up to a single source of authority.
>

Currently, IETF is the source of policy and authority, iana.org, as run 
by ICANN is the single source of authoritative data. Seems to me that 
the simplest way to maintain a single source of authority is for the 
ownership of ietf.org to reside with IETF, to be delegated to whatever 
contractor is managing the data at any given time. Completely 
transparent to end-users of the registry.

Do you have an alternative, simpler solution to offer?

Cheers,

Miles

> On 7 Nov 2014 22:42, "Miles Fidelman" <[email-masked] 
>         On Nov 6, 2014, at 6:19 AM, Miles Fidelman
>         <[email-masked]
>             More specifically, I'm concerned with avoiding any
>             confusion or operational disruption in the event of future
>             conflicts among the parties involved in oversight,
>             management, and/or performance of the IANA functions -
>             particularly in the case where a transition of contractor
>             might occur on less then friendly terms.
>
>             Under such situations, it seems at least possible, if not
>             likely, that litigation might ensue and/or that parties
>             might operate competing registries - causing operational
>             confusion at a minimum, and possibly more serious
>             disruptions to smooth operation of the net.
>
>         I'm honestly curious: could you describe the "serious
>         disruptions to smooth operation of the net" or "operational
>         confusion" that would occur in the event of future conflicts
>         relating to the IANA trademark and/or IANA.ORG
>         <http://IANA.ORG> domain?
>
>
>
>     Kind of depends on the degree to which various developers depend
>     on the various registries published under iana.org
>     <http://iana.org>, and perhaps on the degree to which anybody
>     relies on automatic download of registry contents.
>
>     I expect other operating systems do similar things.  A lot of
>     systems could break, rather precipitously, if iana.org
>     <http://iana.org> went offline, or the file were moved somewhere
>     else, or the file were corrupted - particularly if it happened
>     just before a major release cycle.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Eric Burger <[email-masked]>
Date: Fri, 7 Nov 2014 17:24:17 -0500

Here is the rub. This whole discussion is about policy and law. Saying all we need is an engineering solution is missing the point. If that was the case, we can all go home now.

Eery to be in agreement with Milton and not Jon. Weird.

--
Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF LEMONADE for mobile email! See <http://www.standardstrack.com/ietf/lemonade/>

> On Nov 7, 2014, at 5:00 PM, Peterson, Jon <[email-masked]> wrote:
> 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 7 Nov 2014 22:39:32 +0000

On 11/7/14, 2:24 PM, "Eric Burger" <[email-masked]> wrote:

>Here is the rub. This whole discussion is about policy and law. Saying
>all we need is an engineering solution is missing the point. If that was
>the case, we can all go home now.

There is a whole discussion and then there's this particular rathole of a
rathole. Our deliverable is a working group consensus document in response
to the ICG: mostly that's a tutorial about how the IETF uses the IANA
function, which is partly about policy, not much about law, and partly
about engineering. In a very small part of that response, some text
reflects our attitude towards unfortunate contingencies, which I suggested
we could address with either politics or engineering, or various
admixtures of the two. I'm not aware I'm missing any point here...

>Eery to be in agreement with Milton and not Jon. Weird.

... but going home works for me.

Jon Peterson
Neustar, Inc.

---

From: John Curran <[email-masked]>
Date: Fri, 7 Nov 2014 14:45:38 -0800

Jon - 

  Would you object to the IETF's ICG response proposing (under Section III)
  that "there needs to be a mechanism providing for ongoing cooperation 
  in the use of the IANA domain name and marks, supporting usage by the 
  IETF as they are presently used for the protocol parameter registries."  ?

  That would appear to be quite a different statement than proposing that 
  something must be transferred, but still allows identification of the 
  potential issue.

Thoughts?
/John

Disclaimer: My views alone

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 7 Nov 2014 14:47:17 -0800

Hi David,

> I was told ICANN staff on the ICG are forbidden to speak unless in response to a question.  Was I told incorrectly?

I think you’re confusing several different roles here:

* There is an ICANN staff member (Elise) who is an appointed liaison to the ICG. She and the ICANN Board liaison (Kuo Wei) participate in all ICG deliberations other than consensus calls on substantive matters. https://www.icann.org/en/system/files/files/icg-guidelines-decision-making-17sep14-en.pdf

* The ICG is currently supported by an ICANN staff secretariat. Their roles are not specified anywhere specifically but they are quite proactive in terms of getting their secretarial duties done (e.g., posting things to the appropriate web sites). They don’t participate in substantive discussions, but then I don’t think anyone would expect them to.

* There is an ICANN staff member (Theresa Swinehart) who attends the ICG meetings and is subscribed to the ICG mailing list. In terms of the ICG’s own deliberations, perhaps this is what you were referring to, as Theresa is available to answer ICANN-specific questions or to coordinate things with other parts of the ICANN staff. But she does not proactively participate in the ICG’s own deliberations, in the same way that no other non-ICG members participate.

* As far as the operational community processes, the ICG is encouraging everyone to participate as much as they want. This is reflected in the ICG charter <https://www.icann.org/en/system/files/files/charter-icg-27aug14-en.pdf> and in the RFP itself <https://www.icann.org/en/system/files/files/rfp-iana-stewardship-08sep14-en.pdf>. That participation includes ICANN staff, and I’m sure you’ve seen how active the staff have been in the CWG-IANA concerning naming resources. The ICG is working on a specific statement to encourage participation from ICANN staff and board members in the community processes if they are so inclined <http://mm.icann.org/pipermail/internal-cg/2014-October/002162.html>, but this statement was motivated more by concerns regarding the board than the staff, and the generic statements made in the charter and RFP of course extend to anyone who wants to participate.

Best,
Alissa

---

From: Eliot Lear <[email-masked]>
Date: Fri, 07 Nov 2014 14:51:45 -0800

Hi John,

On 11/6/14, 2:04 PM, John Curran wrote:
> The IETF community presently accesses the protocol parameter registries 
> "IANA" in the protocol parameter registry processes [RFC5226].

I personally think this is good text and propose to include it, barring
strong objection.

Eliot

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 7 Nov 2014 23:07:10 +0000

Probably language along these lines is viable, sure. This sounds much in
the same spirit as the Alissa/Eliot text regarding "backwards
compatibility." My ear does twitch a little at the "ongoing cooperation in
the use of the IANA domain name and marks," in so far as I'm not sure that
I'd call the administration of the IANA domain name today "cooperative,"
though certainly our use of the IANA function is. Similarly, there must be
a legal dimension (Eric Burger, you listening, man?) to our use of "IANA
Considerations" in RFCs that has some bearing on IANA as a trademark, but
I'd hesitate to stake an IETF consensus position on that.

Jon Peterson
Neustar, Inc.

---

From: Milton L Mueller <[email-masked]>
Date: Fri, 7 Nov 2014 23:24:34 +0000

The board liaison and the IANA rep are on the ICG for informational purposes, which means they are not supposed to be voting on whatever we vote on, nor are they supposed to be advocating their or the board's opinion. 

But they can seek recognition to talk any time they want. 

> I was told ICANN staff on the ICG are forbidden to speak unless in
> response to a question.  Was I told incorrectly?
>

---

From: Milton L Mueller <[email-masked]>
Date: Fri, 7 Nov 2014 23:28:36 +0000

This is getting to be an unproductive line of discussion. 
No one "stole" the property and the proposals to move it to someone else are also not "expropriation," both were (or would be) part of collectively mediated institutional changes

---

From: David Conrad <[email-masked]>
Date: Fri, 7 Nov 2014 13:37:30 -1000

Milton,

> The board liaison and the IANA rep are on the ICG for informational purposes, which means they are not supposed to be voting on whatever we vote on, nor are they supposed to be advocating their or…

I sense a bit of a disconnect in translating the role you describe above into:

"ICANN itself was fully represented in the development of the proposal and had the ability to publicly comment on it."

(other than in the "All animals are equal, but some animals are more equal than others" sense of course)

Regards,
-drc

---

From: 'Andrew Sullivan' <[email-masked]>
Date: Fri, 7 Nov 2014 18:56:22 -0500

> Whoa. It is completely invalid to call a final ICG proposal that was developed by the entire community, is endorsed consensually by all 3 operational communities, has survived one or more public co…

Look, you're the one who claimed there was extortion in the first
place: that ICANN would be "extorting" the IETF if it asked us to give
something up if we wanted something of theirs.  Where I come from,
that's not called "extortion"; it's called "selling" or "making a
bargain".  

> You need to get a grip on the reality of this process; it is highly
>  public, highly political, the whole world is watching, etc.,
>  etc. The idea that ICANN could undermine a consensus ICG proposal
>  by bargaining with IETF and ask for nasty things IETF did not want
>  to give them just lacks basic plausibility. I think you'd better
>  give up on that line of argumentation.

They're not going to be _nasty_ things; they're going to be things we
don't want to give up.  For instance, they might ask for tighter
conditions on how we might change the relationship.  Surely, that's
what you or I would ask for under similar circumstances?
 
> You're saying "do nothing to avert an obvious problem" 

No, I'm not.  I keep saying that I don't think this is an obvious
problem, and I don't think that our having control over the mark or
name is an obvious solution to that non-obvious problem.  I'll try
once more, then give up.

The draft already contains a request of the continuation of the
existing state of affairs, which is that the incumbent operator agrees
to transfer the marks and domain names to some subsequent operator.
But our problem is the one where either the IETF or ICANN decides to
separate the protocol parameters from everything else, and where that
separation happens in a way that there is a big dispute such that a
redirect from the iana.org site to some new site isn't just put in
place as a matter of course.  In other words, things have broken down,
there is mistrust and ill feeling, and so on.

Under such circumstances, there is no nice state of affairs.  We don't
know now whom we should trust then, and there's no more reason to
prefer the IETF Trust than to prefer the existing IANA operator.  The
names community and the numbering communities both have legitimate
claims on iana.org too.  Indeed, if I put on my names-community hat,
the names community has at least as good a claim, because the root
zone is published there and the topmost-level whois data is there, and
there are way more people in the world who have little information
about what an IANA is who need the root zone from time to time than
there are implementers of protoocols who need the latest IANA protocol
parameters.

Moreover, were there some legal agreement, in a disputatious case the
dispute would be settled in legal terms way too late for the IETF.  So
we'd have to make a forced transition anyway.

I've already outlined a way to get around this problem for the IETF,
if we really think it's a problem; it's a path that we can take
entirely on our own without making a single request of ICANN, NTIA, or
anyone else.

Regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Jefsey <[email-masked]>
Date: Sat, 08 Nov 2014 00:58:17 +0100

Seun, Richard, Miles, John,
This WG calls for a few "iana.cool" brains. If you do not want to 
read my draft (1) please at least read the IAB/ICANN/NTIA RFC 3172 
(BCP 52) https://tools.ietf.org/rfc/rfc3172.txt. In particular Section 5.
Cheers.
jfc

(1) http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf
      IMHO this is the one which will prevail as it is not NTIA, nor 
SCO, nor EU, nor ICANN, nor ITU, nor NETmundial, etc. oriented. Just 
interested in intelligent internet use capability.

At 23:06 07/11/2014, Seun Ojedeji wrote:
>systems services are syncing off the <http://iana.org>iana.org site.
>parameter source with different entries; as an example http 
>referenced as port 80 and as another port on the other site.
>
>How to avoid that is not just by locking up the name 
><http://iana.org>iana.org but by locking up to a single source of authority.
>
>Cheers!
>
>sent from Google nexus 4
>On 7 Nov 2014 22:42, "Miles Fidelman" 
><<mailto:[email-masked]>[email-masked]> wrote:
>David Conrad wrote:
>Miles,
>
><<mailto:[email-masked]>[email-masked]> wrote:
>Under such situations, it seems at least possible, if not likely, 
>that litigation might ensue and/or that parties might operate 
>competing registries - causing operational confusion at a minimum, 
>and possibly more serious disruptions to smooth operation of the net.
>
>smooth operation of the net" or "operational confusion" that would 
>occur in the event of future conflicts relating to the IANA 
>trademark and/or <http://IANA.ORG>IANA.ORG domain?
>
>
>
>Kind of depends on the degree to which various developers depend on 
>the various registries published under <http://iana.org>iana.org, 
>and perhaps on the degree to which anybody relies on automatic 
>download of registry contents.
>
>#Updated from 
><http://www.iana.org/assignments/port-numbers>http://www.iana.org/assignments/port-numbers
>
>I expect other operating systems do similar things.Â  A lot of 
>systems could break, rather precipitously, if 
><http://iana.org>iana.org went offline, or the file were moved 
>somewhere else, or the file were corrupted - particularly if it 
>In practice, there is.Â  Â .... Yogi Berra
>
><mailto:[email-masked]>[email-masked]

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 07 Nov 2014 19:24:39 -0500

Jefsey,

Sorry to be blunt, but it's been a long day....

Actually, I HAVE read your draft.  The thing is, it is not, in any way, 
shape, manner, or form, a response to the ICG RFP.  As someone who 
spends most of may day job, writing proposals, my basic reaction is to 
ignore a document that is unresponsive to the RFP.

Beyond that, as a matter of general "style" - and a problem I continue 
to have with the WG draft - is that documents that rely heavily on cross 
references to other documents are incredibly difficult to follow.

Miles Fidelman

Jefsey wrote:
> This WG calls for a few "iana.cool" brains. If you do not want to read 
> my draft (1) please at least read the IAB/ICANN/NTIA RFC 3172 (BCP 52) 
> https://tools.ietf.org/rfc/rfc3172.txt 
> <https://tools.ietf.org/rfc/rfc3172.txt>. In particular Section 5.
> Cheers.
> jfc
>
> (1) 
> http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf
>>             confusion or operational disruption in the event of
>>             future conflicts among the parties involved in oversight,
>>     <http://www.iana.org/assignments/port-numbers>
>>
>>     <https://www.ietf.org/mailman/listinfo/ianaplan>
>>
>> <https://www.ietf.org/mailman/listinfo/ianaplan>

---

From: Brian Trammell <[email-masked]>
Date: Sat, 8 Nov 2014 02:34:13 +0100

Greetings, all,

On 07 Nov 2014, at 23:22, Miles Fidelman <[email-masked]> wrote:

> Seun,
> 
> Seun Ojedeji wrote:
>> 
>> Miles, it think you are referencing that url as if the operating systems services are syncing off the iana.org <http://iana.org> site.
>> 
> 
> I doubt that the o/s is syncing in real time.  I wouldn't be surprised though, if, at build/packaging time, the build system does a lookup against the iana.org site.  I wouldn't be surprised if other iana.org paramter registries are used in similar ways.
> 
>> If that domain changes today, it does not take anything other than a update to reflect the new reference url does it?
>> 
> 
> If the URL changes, then auto-build systems will break - and people will end up having to figure out what happened, and fix it.  That's "disruptive" in my book.

Unless the auto-build system is linked to an auto-test system which also automates all the reports from alpha and beta testers, I'm presuming at least *one* of the humans with their hands on the tiller in the whole process is going to read theregister.co.uk or similar, and I'm going to further presume that the geek press will have at least one everything-is-ruined story. So this is one of those things that would get caught relatively early in the release cycle.

(I would also presume that any build system that automated would also be sufficiently advanced to read theregister.co.uk itself, but I digress nearly as far as the rest of this thread has.)

There may be other things which rely on certain content being at iana.org in a semi-automated fashion. I can't think of any that would reasonably be parts of processes where that URL would be hard-coded. So some extra work. But not a great deal of extra work.

>> What would be disastrous is if there happens to be 2 authoritative parameter source with different entries; as an example http referenced as port 80 and as another port on the other site.
>> 
> 
> exactly!

While there has indeed been disruption caused by the assignment of protocol parameters by parameter sources acting on their own authority, an activity referred to not particularly affectionately as "squatting", I'm having a hard time understanding the proposed method of initiation for this registry-scale mutual-squatting situation, or the disruption it is supposed to cause.

Let us assume the worst case: ICANN goes rogue and simply tries to inflict the maximum damage it can on the Internet by running an evil protocol parameters registry. It is important to note in this case that the most used protocol parameters are essentially immune even to completely malicious disruption merely by the massive inertia of the running code that makes up the Internet. Sticking 1337 in the port-number value field for "http" and "www" at will have no effect at all on the fact that all the world's webservers and browsers believe the web runs on port 80. Possession of the iana.org name confers no magic powers.

Of course, the more obscure registries have less inertia, but I suspect there is a vanishingly small set of registries where malicious reassignment would cause significant disruption to operations but the change would not be caught by people familiar with the contents first (or, if a codepoint changes and there is nobody there to care, is that really a problem?)

If an actively malicious ICANN can't break the Internet, I fail to see how an uncooperative but rational post-transition ICANN could.

Where we do get two parameter sources that perceive themselves as authoritative (i.e., one IANA, one a piece of running code that uses unassigned or otherwise-assigned codepoints for its own purposes), what generally happens is a protocol designer, equipment vendor, and/or software developer picks a codepoint, either because they don't want to bother with IANA or disagree with a decision the IETF (or IETF designated expert) made as the source of IANA policy. But this seems unrelated to this discussion, and I presume it will continue to be an irritation regardless of what happens in the transition.

>> How to avoid that is not just by locking up the name iana.org <http://iana.org> but by locking up to a single source of authority.
>> 
> 
> Currently, IETF is the source of policy and authority, iana.org, as run by ICANN is the single source of authoritative data.

IANA is the single source of authoritative data. ICANN, as the operator of the IANA function, presently serves that content from iana.org. The A in SOA does not confer actual authority, and the interia of the name itself presents a potential inconvenience but not a disaster should we be denied its use in the future.

> Seems to me that the simplest way to maintain a single source of authority is for the ownership of ietf.org to reside with IETF, to be delegated to whatever contractor is managing the data at any given time. Completely transparent to end-users of the registry.

> Do you have an alternative, simpler solution to offer?

The simplest solution in this case is "we have no actual problem at this time." I can agree that having the IETF "own" iana.org might be convenient in the case that we want to ensure we can minimize future work involved in a possible transition away from ICANN as IANA operator. I'm not sure the numbers or the names communities would agree that IETF is the natural owner of the domain, though. And I certainly do not think that asking ICANN to transfer the domain name as part of the ICG process is worth the effort, given that we do not have an actual problem at this time.

For the record, I'm okay with noting we have a dependency on the iana.org domain name in the ICG response, and John's text quoted by Eliot is good. But as far as I'm concerned that handles the issue for the scope of the ICG response.

Cheers,

Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Nov 2014 16:38:41 +1300

On 08/11/2014 11:22, Miles Fidelman wrote:
...
> by ICANN is the single source of authoritative data. 

Yes, and that's exactly why, back in 2000, we agreed the following text
with ICANN:
  "4.4. The IANA shall make available to the public, on-line and free of
   charge, information about each current assignment,..."
The fact that this is reached by a URL including "iana.org" is a
technical detail. The important part is the commitment to publish
the assignments. I fail to understand why we are wasting so many
words on the technical detail. I'm tempted to spam filter all future
email on this list containing the string "iana.org".

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Nov 2014 16:48:07 +1300

> No one "stole" the property and the proposals to move it to someone else are also not "expropriation," both were (or would be) part of collectively mediated institutional changes

Indeed, to the best of my knowledge ISI transferred the domain name to
ICANN quite voluntarily as a matter of common sense, when IANA operations
were transferred from ISI to ICANN. The IAB at the time was completely
aware of this and saw no reason to raise an eyebrow, since operating
the IANA server was the visible part of IANA operations, so *obviously*
ICANN became the technical and admin contact for the domain name.

   Brian (IAB Chair at the time)

> .

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 8 Nov 2014 09:42:28 +0100

> From: Ianaplan [mailto:[email-masked]]On Behalf Of David
> Conrad
> Sent: vendredi, 7. novembre 2014 21:51
> To: [email-masked]
> Cc: [email-masked]

What I said in my original message, which you quote only partially above,
was:

"As others have pointed out, ICANN took it from others without compensation.
And there was nothing wrong with that: nobody complained, and the previous
owners did not request compensation.  Apparently it made sense in the
context of the creation of ICANN."

Like most human beings, I make mistakes, and when I do I have no problems
admitting them and apologizing.  I see now that it would have been more
precise to say "ICANN obtained it from others without monetary
compensation".  I apologize for the imprecision.

Be that as it may, what I wrote cannot possibly be interpreted as an
accusation of theft, becuase the term "compensation" is clearly referring to
monetary compensation or some material equivalent.  As the last sentence of
my statement implies, and as has been made clear subsequently, there
actually was a quid pro quo, albeit not monetary: ICANN provided services to
the IETF.

Further, unauthorized use of intellectual property is not theft, despite
what you may read when you start watching a DVD.  It is an entirely
different offence.

---

From: Seun Ojedeji <[email-masked]>
Date: Sat, 8 Nov 2014 11:13:48 +0100

I responded to this mail but it seem my response did not get through. I
will try this again below:

@Miles i think you may be referring to iana.org as if operating systems
services sync information off it in reatime which is not necessarily the
case. I would expect that a change in the domain name will only require a
normal OS update to reflect the appropriate new url...No?

What i would term disruptive is when there exist 2 sources of authoritative
information and when the information on the each source is not the same.
For example it would not be helpful if a source reflects http being port 80
and another reflects it as another port. So i would think being
authoritative goes beyond a mere ownership of iana.org but extend to the
content itself.

Cheers!

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

The key to understanding is humility - my view !

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 08 Nov 2014 08:35:50 -0500

I agree.  Though the issue is really whether people use conflicting 
sources of information - whether they are authoritative or not.

Which breaks down into two separate issues:
- what constitutes an "authoritative source," and,
- what do users perceive to be an authoritative source

My major take is that clear control and delegation of iana.org is a way 
of avoiding the potential for conflicting sources of information - by 
taking pains to make sure that iana.org is, and remains to be the 
well-publicized "official" and hence "authoritative" source of 
information, and that the data in it is managed by the party(ies) 
responsible for maintaining he authoritative data.

That's the current situation.  Let's craft a transition that makes an 
effort to keep it the situation in the event of a transition of iana.org 
contractor.

(note: I agree with those who seem to think we're spending way too much 
time on what seems to be a simple matter.  I honestly don't understand 
why this should be such an issue.)

Miles

Seun Ojedeji wrote:
> I responded to this mail but it seem my response did not get through. 
> I will try this again below:
>
> @Miles i think you may be referring to iana.org <http://iana.org> as 
> if operating systems services sync information off it in reatime which 
> is not necessarily the case. I would expect that a change in the 
> domain name will only require a normal OS update to reflect the 
> appropriate new url...No?
>
> What i would term disruptive is when there exist 2 sources of 
> authoritative information and when the information on the each source 
> is not the same. For example it would not be helpful if a source 
> reflects http being port 80 and another reflects it as another port. 
> So i would think being authoritative goes beyond a mere ownership of 
> iana.org <http://iana.org> but extend to the content itself.
>
> Cheers!
>
>
> On Fri, Nov 7, 2014 at 10:42 PM, Miles Fidelman 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     David Conrad wrote:
>
>         Miles,
>
>     /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: Suzanne Woolf <[email-masked]>
Date: Sat, 8 Nov 2014 09:59:09 -0500

On Nov 7, 2014, at 4:16 PM, Seun Ojedeji <[email-masked]> wrote:
> Have been following the discussions and it's been quite interesting; much more interesting that it almost seem iana.org ownership is the deciding factor in this process[1].
> 
Have you read the draft? 

It seems to me that if you review both the mailing list and the draft, the work that's necessary for the IETF to reach consensus on what should go into the RFP response is mostly done.

It should perhaps also seem that most of the experienced IETF participants here don't regard anything about the iana.org domain name as "the deciding factor" in much of anything. Most of the pressure to make more of a point of what should happen to it in the event of a dispute is coming from people who are obviously deeply concerned about the future of the Internet, but whose primary experience of the IANA functions is not in the protocol parameters area or in how the IETF and its user communities interact with the IANA operator.
> The extent of back and fourth deliberation on the list, makes me wanna mention here that it will be good for IETF to start handling/addressing issues not only as a protocol parameter community but as the overall source of all the whole function. 
> For all it's worth, those who don't want to complicate the outcome of this process have great hope in IETF playing a leadership role in all these.
> 
I'm curious what you mean by this comment. Who thinks the IETF should be functioning here "not only as a protocol parameter community," what do they want instead, and how are they planning to make their requests or desires known?

As "the overall source of all the whole function," the IETF long ago delegated administration of certain protocol parameters to organizations deemed better able to address the related public policy concerns than the IETF is, or wants to be.  Are you suggesting revisiting that?
> I am beginning to wonder if this is the case.
> 
It looks to me as if the IETF is playing its part in a multi-stakeholder process, in which each of the operational communities directly affected by the IANA functions is expected to propose a transition plan for its area of concern. As far as I'd understood, and the ICG members here can certainly elaborate but the extensive public record is pretty clear, the ICG is then responsible for addressing gaps or conflicts between operational community plans. Its primary mechanism for resolving those conflicts is by engaging the affected operational communities to do so.

Certainly if later trouble can be avoided by communities collaborating now, we ought to try to make that happen. What do you think is missing?

thanks,
Suzanne

> 1. Which IMO should just be a minimal component in this process especially as ntia is not the owner of the domain in the first place.
> sent from Google nexus 4

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Nov 2014 07:37:04 -0800

> - sounds to me like an ultimatum which would antagonize other

[BA] Since "IANA .org" affects all the communities, this needs to be handled cooperatively. There is a reason why "IANA.org" ownership was not transferred to the IETF Trust when it was created, and so transition planning cannot be something the IAOC handles all by itself. However, the IAOC can work with other communities to come up with a solution. 

> situation (i.e. RFC2860) works today and would likely work in the future.

[BA] RFC 2860 was important not only as a framework that remains useful today but also as an operational model. There is little reason to reopen it.

>> have any idea what kind of 'bad things' are being talked about.

[BA] I do not worry about asking for ICANN to agree to maintain transition arrangements it previously agreed to in the plan filed with NTIA. However, one can argue that the Domain and trademark relate to all functions and so all communities should have a say in the transition plan.

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 8 Nov 2014 10:51:53 -0500

On Sat, Nov 08, 2014 at 07:37:04AM -0800, Bernard Aboba wrote:
> 
> [BA] Since "IANA .org" affects all the communities, this needs to be handled cooperatively.

Wait, no.  I deny this premise for the purposes of this discussion.

We _already_ have in the draft a term that says "iana.org goes with
the operator."  This is, AIUI, a request for a term that is already in
effect.

What we are talking about is a case where different registries go
their separate ways, and they do so un-co-operatively.  In that case,
_by definition_, iana.org won't affect all communities (or anyway,
can't affect them all in the same way).  

By definition, it can't be handled co-operatively in this case,
because we're already into non-co-operation as part of the scenario
we're trying to cope with.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 8 Nov 2014 16:42:26 +0000

Sure, but the steps we take today to safeguard ourselves from possible
contingencies could be unilateral demands that alienate our peers or they
could approach this in the spirit of past cooperation. I'm worried that if
we strike the wrong posture, we could end up inspiring the very split
we're hoping to guard against. So I think it's fair to say that I'd want
our current ICG response process to think cooperatively, rather than
antagonisticly, say.

Jon Peterson
Neustar, Inc.

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 08 Nov 2014 12:11:05 -0500

Fair enough.

What I'm wondering is why anybody sees it as unilateral and alienating 
to say:

1. iana.org is used by the current process (along with various other 
intellectual property)
2. in the event of a transition, things might go smoother if it were 
"owned"/registered by party other than the contractor (particularly the 
incumbent contractor)
3. one possible place for it to reside is ietf.org - but that's just an 
offer for discussion purposes when the other stakeholder proposals come 
together to be merged

I expect there are folks in other communities who are similarly 
concerned about this issue (say, for example, vis-a-vis distribution of 
the authoritative list of root nameservers) - and that their proposals 
might also bring this issue to the table; and they might have other 
suggestions for how to manage ownership of iana.org and its contents.  
Would we see it as unilateral and alienating for another community to 
raise the issue and propose a model for resolving it?

Miles Fidelman

---

From: Seun Ojedeji <[email-masked]>
Date: Sat, 8 Nov 2014 18:12:32 +0100

I have not gone through the document but I have a similar thought about
Jefsey's writeup. I feared it would attempt to address a lot beyond scope;
reading it and reconfirming my fears would be a great deal for me. ;)

Cheers!
sent from Google nexus 4
kindly excuse brevity and typos.
On 8 Nov 2014 01:24, "Miles Fidelman" <[email-masked]> wrote:

> shape, manner, or form, a response to the ICG RFP.  As someone who spends
> most of may day job, writing proposals, my basic reaction is to ignore a
> document that is unresponsive to the RFP.
>
> Beyond that, as a matter of general "style" - and a problem I continue to
> have with the WG draft - is that documents that rely heavily on cross
>> This WG calls for a few "iana.cool" brains. If you do not want to read my
>> draft (1) please at least read the IAB/ICANN/NTIA RFC 3172 (BCP 52)
>> https://tools.ietf.org/rfc/rfc3172.txt <https://tools.ietf.org/rfc/
>> rfc3172.txt>. In particular Section 5.
>> Cheers.
>> jfc
>>
>>      IMHO this is the one which will prevail as it is not NTIA, nor SCO,
>> nor EU, nor ICANN, nor ITU, nor NETmundial, etc. oriented. Just interested
>> in intelligent internet use capability.
>>
>>
>>> services are syncing off the iana.org <http://iana.org> site.
>>> How to avoid that is not just by locking up the name iana.org <
>>> http://iana.org> but by locking up to a single source of authority.
>>>
>>> Cheers!
>>>
>>> sent from Google nexus 4
>>>     --     In theory, there is no difference between theory and practice.
>>> https://www.ietf.org/mailman/listinfo/ianaplan <
>>> https://www.ietf.org/mailman/listinfo/ianaplan>
>>>
>>
>
> --

---

From: Seun Ojedeji <[email-masked]>
Date: Sat, 8 Nov 2014 19:04:08 +0100

On Sat, Nov 8, 2014 at 3:59 PM, Suzanne Woolf <[email-masked]>
wrote:

> factor in this process[1].
>
> Have you read the draft?
>
> It seems to me that if you review both the mailing list and the draft, the
> work that's necessary for the IETF to reach consensus on what should go
> into the RFP response is mostly done.
>

Yes i have and as you may have noticed i referred to "discussion" and not
the "actual draft" which was my reason for wondering on why iana.org is
getting discussed in such a detail. However by interpreting your response i
presume its saying "....discussions can continue in an unstable manner but
the actual proposal is stable....". which is fine!

>
> It should perhaps also seem that most of the experienced IETF participants
> here don't regard anything about the iana.org domain name as "the
> deciding factor" in much of anything. Most of the pressure to make more of
> a point of what should happen to it in the event of a dispute is coming
> from people who are obviously deeply concerned about the future of the
> Internet, but whose primary experience of the IANA functions is not in the
> protocol parameters area or in how the IETF and its user communities
> interact with the IANA operator.
>

Well yes i observed that. However, i would also note that the young shall
grow, i for one am learning in all these ;)

> The extent of back and fourth deliberation on the list, makes me wanna
> mention here that it will be good for IETF to start handling/addressing
> issues not only as a protocol parameter community but as the overall source
> of all the whole function.
> process have great hope in IETF playing a leadership role in all these.
>
> I'm curious what you mean by this comment. Who thinks the IETF should be
> functioning here "not only as a protocol parameter community," what do they
> want instead, and how are they planning to make their requests or desires
> known?
>
>
Well there have been some throwing of question of authority on this mailing
list (and other lists as well) and from indication i sense IETF (at least
the experienced folks) does not want to own-up to the fact that it can
provide the minimal oversight to get things going administratively. IETF
has done this on the policy realm in the past and it has worked well, even
for names it worked because the names PDP has one of the highly inclusive
multistakeholder platform. Here is another call to do this in the
administrative side things.

As "the overall source of all the whole function," the IETF long ago
> delegated administration of certain protocol parameters to organizations
> deemed better able to address the related public policy concerns than the
> IETF is, or wants to be.  Are you suggesting revisiting that?
>

And here is my point, what was mainly separated and assigned is the
respective PDP and not necessarily the ability to move IANA (ofcourse there
was no need for that then). However we are now indirectly separating the
functions on paper in a manner going in the direction of policy. This IMHO
does not help this process; its going to be helpful if the function still
gets handled by a single operator. The current issue at hand is not a
policy issue, but an issue that i think requires the source(being IETF) to
indicate its willingness to take charge (minimal charge of being able to
move IANA to another operator)

> It looks to me as if the IETF is playing its part in a multi-stakeholder
> process, in which each of the operational communities directly affected by
> the IANA functions is expected to propose a transition plan for its area of
> concern. As far as I'd understood, and the ICG members here can certainly
> elaborate but the extensive public record is pretty clear, the ICG is then
> responsible for addressing gaps or conflicts between operational community
> plans. Its primary mechanism for resolving those conflicts is by engaging
> the affected operational communities to do so.
>

Yeah and that splitting of the discussion IMO was one of the reasons why we
may end up having a issue when its time for a single proposal. I don't know
why we so much believe ICG will do some magic in putting the document
together especially if what was proposed already reflect an absolute
disconnect.[1]

>
> Certainly if later trouble can be avoided by communities collaborating
> now, we ought to try to make that happen. What do you think is missing?
>
> I would expect each of the 3 operational communities to be in sync
(perhaps through the chairs) and be available to directly answer question
on their present roles and future roles consideration in other to better
inform the proposal preparations. We generally need to address the
disconnect among the 3 operational communities because going forward, IANA
functions is still preferred to be handled centrally. This transition
process is something that we(at least I) don't want to repeat and if care
is not taken we may look back and realise we have wasted so much resources
without achieving an absolute goal

Thanks

Cheers!
1. According to the ICG process, it says it will go back to the community
if such happens. It will be interesting if we had to repeat that process

>> OK. I see the difference in the attitude with which we approach this. I
>> am beginning to think it is a purely attitudinal matter and not all that

---

From: Milton L Mueller <[email-masked]>
Date: Sat, 8 Nov 2014 18:04:32 +0000

Brian, 
I also think we are wasting a lot of words on this. If this is a technical detail, why are certain people so afraid of changing it? Why the panicky resistance to making what you yourself are characterizing as a minor issue?

If, as Jon suggests, ICANN will be deeply offended if IETF asks to keep that technical detail consistent, perhaps it is more than a detail? 

You can't have it both ways. If the whole issue is trivial, it is trivial to ask for the change and there's no reason not to. If on the other hand the request for the domain and mark is disruptive and destabilizing, then the issue is more than some trivial technical detail. 

> Yes, and that's exactly why, back in 2000, we agreed the following text with
> ICANN:
> The fact that this is reached by a URL including "iana.org" is a technical detail.
> The important part is the commitment to publish the assignments. I fail to
> understand why we are wasting so many words on the technical detail. I'm
> tempted to spam filter all future email on this list containing the string
> "iana.org".

---

From: John Curran <[email-masked]>
Date: Sat, 8 Nov 2014 11:01:52 -0800

On Nov 8, 2014, at 7:51 AM, Andrew Sullivan <[email-masked]> wrote:
> their separate ways, and they do so un-co-operatively.

Andrew - 

I concur with the former part of the statement (we are talking about the
case where different registries go their separate ways), but not the latter 
(they do so uncooperatively)

I can think of several potential reasons why one of the communities might 
want a different IANA operator than the others, and believe that such could 
happen under circumstances of cooperation, _particularly_ if appropriate 
attention is paid to the issue up front.

Suppose, for example, that the IETF finds it desirable to move to an IANA 
operator in a different legal jurisdiction at some point in the future. 
Such a choice should not get entangled in numerous unknowns around use 
of the IANA mark or domain name; i.e. it should be understood in advance 
whether the IETF (or its subcontractor) will have the ability to make 
use of these so that the discussion regarding any such change can be 
well-informed.

> In that case, _by definition_, iana.org won't affect all communities
> (or anyway, can't affect them all in the same way).  
> 
> By definition, it can't be handled co-operatively in this case, because
> we're already into non-co-operation as part of the scenario we're trying
> to cope with.

Incorrect, as you correlate the need for a change with lack of cooperation -
the need for a change may be driven entirely by changes in the IETF's own
situation or requirements, not imply any lack of cooperation among other
parties.  Such cooperation exists today, and I personally believe should
be discussed and formalized, as there is the risk that failure to directly 
address such regarding the use of the mark and domain name could result in
arrangements that make any future changes contemplated by the IETF rather
problematic.

Given that the ICG RFP explicits requests identification of independencies, 
it would be remiss for the IETF to omit discussion of their use of the mark 
and domain unless it is the IETF community's view that their use is simply 
happenstance and their ongoing use (or lack thereof) is completely incidental 
to the proper functioning of the IETF's protocol parameter registries.  I have 
heard several folks express that view (yourself, Brian, Jon), do you believe 
there is rough consensus within the WG (and greater IETF) on that position?  

I would be fine with no discussion of arrangements for the use of the mark 
or domain name if a statement to this effect (their use is incidental to the 
proper functioning of the IETF's protocol parameter registries and hence no 
arrangements are needed) were instead placed in the document.

/John

---

From: JFC Morfin <[email-masked]>
Date: Sat, 08 Nov 2014 21:28:25 +0100

At 01:24 08/11/2014, Miles Fidelman wrote:
>The thing is, it is not, in any way, shape, manner, or form, a 
>response to the ICG RFP.

Absolutely correct.
Please tell me where ICG RFP is mentionned in this WG's Charter.
Richard made the point that this WG is to think as if it was ICANN. 
This is what I oppose. This WG is not ICANN (proof: it has no embedded lawyer).
http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.02.pdf 
is pertinent.

>>IAB/ICANN/NTIA RFC 3172 (BCP 52) 

This is the response called both by the WG Charter and the ICG:

(1) we have an existing solution and the Charter wants status quo. We 
only have to internally generalize this solution to the multi-SDo 
multi-repository multi-stakeholder context acknowledged by IEEE, IAB, 
IETF, ISOC, W3C, NTIA, ITU (RFC 6852; March 14, 2014 statement; Busan)

(2) since we do not want to change that general solution we can only 
answer "no" to every demand for any specific change.

(3) our charter is therefore to consider the global changes that 
might require a change in the agreed existing general solution: no 
ICG request is formulated appropriately.

(4) possibly, in order to spur the IETF slowliness in internally 
implementing that solution, we might suggest the IESG/IAB to:

      - create a WG/ARPA to publish an RFC 3172bis in order to update 
the BCP 52
      - and organize a NonWG/ARPA mailing list to manage .arpa as per 
this BCP 52.

Best
jfc

---

From: JFC Morfin <[email-masked]>
Date: Sat, 08 Nov 2014 21:14:04 +0100

At 18:12 08/11/2014, Seun Ojedeji wrote:
>I have not gone through the document but I have a similar thought 
>about Jefsey's writeup. I feared it would attempt to address a lot 
>beyond scope; reading it and reconfirming my fears would be a great 
>deal for me. ;)

?
There are two topics.

1. the respect of the Charter, as per the reading of the Chairs.

2. the support of the internet users' technical needs as a result of 
the NTIA announcement, NETmundial meetings, ICANN strategy, resulting 
IGF, ITU and SCO ongoing debates and the MYCANN Plug-ins consequent 
projects and expected announcements.

As a member of this WG, and the Non-WG IUCG@IETF facilitator, my plan 
was to do two things after having carefully followed and participated 
to the WG debate:

1. to introduce an I_D as a community proposals the Chairs have 
committed to consider as per the Charter.
2. to introduce an appeal to the IESG for this WG to really consider 
what the IETF is to do in order to adjust to the transition.

The cut-off period has not permitted my Draft to be introduced as an 
I_D in due time. I, therefore, had to create a crash IUWG site where 
I published and continue to maintain the draft with a forming Libre 
small group of IUsers. The mails of Andrew, Miles, and you are clear 
enough; in spite of the Chair's commitment, and the NTIA demand for a 
multistakeholder approach, the intent does not seem to discuss it as 
a Libre IUser community contribution.

As a result,

1. my Draft 
http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.02.pdf 
no longer only focuse on what the IETF should do but what the IUWG 
will do to allow IUsers to match the US transition in an unstable 
situation of contested dominance - during a multistakeholder, 
multitechnology, multilinguistic, multirepository, and multilateral 
evolution of the World Digital Ecosystem. This includes the 
introduction of a separate IETF Draft on Monday responding to the 
WG/IANAPLAN Charter: how the IETF can protect the status quo and 
adequately respond to RFPs such as the one received from the IGC.

2. the young IUWG is forming and, therefore, still uncertain about my 
appeal, due to the lack of a joint appeal process in the RFC 6852 
context (the reason for my NTIA interrupted appeal to ISOC). It might 
be built as an appeal copied as a joint RFP to the other SDOs and 
affected WGs and coalitions.

jfc

>On 8 Nov 2014 01:24, "Miles Fidelman" 
>Actually, I HAVE read your draft.Â  The thing is, it is not, in any 
>way, shape, manner, or form, a response to the ICG RFP.Â  As someone 
>who spends most of may day job, writing proposals, my basic reaction 
>is to ignore a document that is unresponsive to the RFP.
>Beyond that, as a matter of general "style" - and a problem I 
>continue to have with the WG draft - is that documents that rely 
>heavily on cross references to other documents are incredibly 
>difficult to follow.
>Miles Fidelman
>Jefsey wrote:
>(BCP 52) 
><https://tools.ietf.org/rfc/rfc3172.txt>https://tools.ietf.org/rfc/rfc3172.txt 
><http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf>http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.01.pdf 
>
>Â  Â  Â IMHO this is the one which will prevail as it is not NTIA, 
>nor SCO, nor EU, nor ICANN, nor ITU, nor NETmundial, etc. oriented. 
>Just interested in intelligent internet use capability.
>systems services are syncing off the <http://iana.org>iana.org 
><http://iana.org> site.
><http://iana.org>iana.org <http://iana.org> but by locking up to a 
>single source of authority.
>Cheers!
>sent from Google nexus 4
><<mailto:[email-masked]>[email-masked] 
>Â  Â  David Conrad wrote:
>Â  Â  Â  Â  Miles,
>Â  Â  Â  Â  On Nov 6, 2014, at 6:19 AM, Miles Fidelman
>Â  Â  Â  Â  <<mailto:[email-masked]>[email-masked]
>Â  Â  Â  Â  <mailto:[email-masked]>> wrote:
>Â  Â  Â  Â  Â  Â  More specifically, I'm concerned with avoiding any
>Â  Â  Â  Â  Â  Â  confusion or operational disruption in the event of
>Â  Â  Â  Â  Â  Â  future conflicts among the parties involved in oversight,
>Â  Â  Â  Â  Â  Â  management, and/or performance of the IANA functions -
>Â  Â  Â  Â  Â  Â  particularly in the case where a transition of contractor
>Â  Â  Â  Â  Â  Â  might occur on less then friendly terms.
>Â  Â  Â  Â  Â  Â  Under such situations, it seems at least possible, if not
>Â  Â  Â  Â  Â  Â  likely, that litigation might ensue and/or that parties
>Â  Â  Â  Â  Â  Â  might operate competing registries - causing operational
>Â  Â  Â  Â  Â  Â  confusion at a minimum, and possibly more serious
>Â  Â  Â  Â  Â  Â  disruptions to smooth operation of the net.
>Â  Â  Â  Â  We're talking about the protocol parameter registries, right?
>Â  Â  Â  Â  I'm honestly curious: could you describe the "serious
>Â  Â  Â  Â  disruptions to smooth operation of the net" or "operational
>Â  Â  Â  Â  confusion" that would occur in the event of future conflicts
>Â  Â  Â  Â  relating to the IANA trademark and/or <http://IANA.ORG>IANA.ORG
>Â  Â  Â  Â  <http://IANA.ORG> domain?
>
>Â  Â  Kind of depends on the degree to which various developers depend
>Â  Â  on the various registries published under <http://iana.org>iana.org
>Â  Â  <http://iana.org>, and perhaps on the degree to which anybody
>Â  Â  relies on automatic download of registry contents.
>Â  Â  For example, the /etc/services file in Debian includes this
>Â  Â  statement:
>Â  Â  #Updated from 
>Â  Â  <http://www.iana.org/assignments/port-numbers>
>Â  Â  I expect other operating systems do similar things.Ã‚Â  A lot of
>Â  Â  systems could break, rather precipitously, if <http://iana.org>iana.org
>Â  Â  <http://iana.org> went offline, or the file were moved somewhere
>Â  Â  else, or the file were corrupted - particularly if it happened
>Â  Â  just before a major release cycle.
>Â  Â  To me, that would be a "serious disruption" or at the very least
>Â  Â  "operational confusion"
>Â  Â  Miles Fidelman
>Â  Â  --Â  Â  Â In theory, there is no difference between theory and 
>practice.
>Â  Â  In practice, there is.Ã‚Â  Ã‚ .... Yogi Berra
>Â  Â  _______________________________________________
>Â  Â  Ianaplan mailing list
>Â  Â  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>Â  Â 
><https://www.ietf.org/mailman/listinfo/ianaplan>https://www.ietf.org/mailman/listinfo/ianaplan 
>
>Â  Â  <https://www.ietf.org/mailman/listinfo/ianaplan>
><<https://www.ietf.org/mailman/listinfo/ianaplan>https://www.ietf.org/mailman/listinfo/ianaplan>
>
>
>
>--

---

From: Andrei Robachevsky <[email-masked]>
Date: Sat, 08 Nov 2014 22:19:29 +0100

Olaf Kolkman wrote on 06/11/14 01:24:
[...]
>   IETF Response: the protocol parameters registries including the .ARPA domain.

Yes, .arpa needs to be mentioned. And perhaps it is better to mention it
in the answer to the question "What registries are involved in providing
the service or activity".

I already suggested a more elaborate definition of what protocol
parameter registries entail (see
http://www.ietf.org/mail-archive/web/ianaplan/current/msg00772.html) and
.ARPA will be there a welcome addition.

Specifically:

"The protocol parameters registries are the product of IETF work. These
also include the top-level registry for the entire IP address space and
some of its sub-registries, AS number space, a number of special use
registries with regard to domain names and the .ARPA domain. For more
detail please refer to the documentation in the "overlaps or
interdependencies" section."

My question here, when we say .ARPA domain, do we mean the whole
sub-tree? Do we need to mention that here explicitly?

My suggestion would be that at the same time we leave the heading the
the main activity as simply "protocol parameters registries", which is
consistent with the high-level division of IANA functions.

Andrei

---

From: manning bill <[email-masked]>
Date: Sat, 8 Nov 2014 16:36:12 -0800

Jon, if I may, I’d like to recast this fine debate into more crisp terms.

We (the great unwashed) have trusted Postel  (the IANA) and his successors & assigns (SRI, NS, GA, IETF, RIRs, ICANN) to act in such a way as to 
continue the trust built up over the decades. Now some subset of these parties has openly questioned what is the “correct” response if the current
holder of the IANA functions (or a subset of the IANA functions), acts in a manner that is detrimental to the long term health of the Internet.
 
Removal of or rehoming some of the trappings of power (who controls IANA.*) seems like a niche question at best.

For me, the more fundamental problem is:  a) how to tell when an operator of one of these functions has lost it,  and  b) how to neutralize the impact 
of a rouge operator.

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Nov 2014 15:05:36 -1000

> Removal of or rehoming some of the trappings of power (who controls IANA.*) seems like a niche question at best.

[BA] I would agree that our goal should be to ensure that this is a non-issue.

However, I do NOT agree that the issue can be ignored. Trademarks in particular can be very powerful things, and it is quite common for trademark owners to challenge uses that even vaguely resemble the trademark, even in uses that might appear peripheral. 

The responsible thing here is to avoid amateur lawyering and get advice from counsel.

---

From: JFC Morfin <[email-masked]>
Date: Sun, 09 Nov 2014 01:31:25 +0100

>sub-tree? Do we need to mention that here explicitly?

Why do you want to change anything? All this is 
already agreed and signed by ARPA, NTIA, ICANN and IAB.

This is RFC 52.

.arpa is the IETF names, numbers, protocols and parameters zone.

The NTIA considers its management by the IAB in 
cooperation with the IANA operator (subject to 
the RFC 2860 Section 4.3 IETF ultimate decision) as a IANA function.

At 01:36 09/11/2014, manning bill wrote:
>For me, the more fundamental problem is:  a) how 
>to tell when an operator of one of these 
>functions has lost it,  and  b) how to 
>neutralize the impact of a rogue operator.

The ICANN accountability issue is addressed by 
BCP 52 (and most of the ICANN accountability 
issue, since the "raison d'être" of ICANN are the 
IANA operations. ICANN is accountable to the IETF 
and therefore subject to the RFC 2026 section 
4.2.3 appeal procedure with ISOC as ultimate referent).

My suggestions:
- is that the IAB complies with its RFC 3271, Section 5, obligations.
- was that the IETF completes the IEN 48 Internet 
project in extending the .arpa zone to the 
d.ocumentation of every digital network 
technology names, numbers, protocols and 
parameters. Because it would be simpler for all.

However, since this does not look that simple to 
this WG, thiis evening IUWG meeting has agreed that:
- I will introduce an I_D to that end at the end of the cut-off period
- updated the IUWG Draft to document how the IUWG 
will proceed to document a global networked 
solution seamlessly addressing the general issue 
of which the IGC is a particular case. 
http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.02.pdf

This way the IUse situation will not be blocked 
anymore by the absurd "iana.org" issue.

jfc

>the main activity as simply "protocol  registries", which is

---

From: manning bill <[email-masked]>
Date: Sat, 8 Nov 2014 20:27:01 -0800

so you are more worried about the name and not the function?

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Nov 2014 19:23:40 -1000

The owner of trademark can use it to assert ownership not only of a directly corresponding domain name, but also of similar names. 

However that does not necessarily imply that it is desirable for the IETF Trust to own the IANA trademark. Trademarks (particularly ones involving registrations in multiple countries) can be quite expensive to register and protect. So unless the Trust has examined the costs involved and finds them manageable, it might make more sense to focus on the conditions for transfer to a successor contractor.

> On Nov 8, 2014, at 6:27 PM, manning bill <[email-masked]> wrote:
>

---

From: Andrei Robachevsky <[email-masked]>
Date: Sun, 09 Nov 2014 08:04:38 +0100

JFC Morfin wrote on 09/11/14 01:31:
> Why do you want to change anything? All this is already agreed and
> signed by ARPA, NTIA, ICANN and IAB.

We are not saying anything new in this section, neither do we change
things. It is just documenting what "protocol parameters registries"
mean. A reference to BCP52 would be appropriate, IMO (it is in the draft
already, but in a slightly different context).

Andrei

---

From: manning bill <[email-masked]>
Date: Sat, 8 Nov 2014 23:06:32 -0800

exactly.  protecting the NAME/BRAND.    I would have thought this effort would have focused on the use of multiple, cooperating parties to 
perform a specific suite of functions, and not have fallen into the rathole of branding and trademark.  

“The entities responsible for the list of tasks identified in NTIA contract# (and follow-ons),  therein referred to as “The IANA””
"The listed tasks are;  a) severable, and b) may be performed by entities not referred to by any of the exiting marks:  (IANA, ICANN, NTIA, RIR, ARIN.RIPE,LACNIC,APNIC,AFRINIC, NRO, ASO, 
GNSO, ccNSO, GAC, IETF, ISOC, IAB, (fill in the rest of the blanks).”
“If the tasks are severed, there will need to be agreed on criteria to ensure the parties are performing their functions for the global benefit of the users of the Internet and not to the benefit of the tasked parties.”
“In the event of non-compliance, there will need to be agreed on criteria for re-assignment of the affected task(s) to qualified parties”

Or are those statements fundamentally wrong?

If these types of questions are deemed inappropriate or untimely - I am sorry.  

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: John Curran <[email-masked]>
Date: Sat, 8 Nov 2014 21:45:48 -1000

> However that does not necessarily imply that it is desirable for the IETF Trust to own the IANA trademark. Trademarks (particularly ones involving registrations in multiple countries) can be quite…

It is not at all clear whether the IETF has any need to own the
IANA mark or domain; if the IETF determines that its use of the 
mark and domain are important to the protocol parameter function, 
then it only needs to ensure that it has the ability to use them -
that does not require ownership, only an appropriate agreement
providing for such use with the owner... (while there may be some
merit in being that owner, that is more than strictly necessary.)

/John

---

From: Seun Ojedeji <[email-masked]>
Date: Sun, 9 Nov 2014 09:19:36 +0100

Here comes the buzzer I was trying to mention and this gives more reason
why determining iana.org ownership alone may not be appropriate because
that name affects all the 3 operational communities one way or the other.

Cheers!

sent from Google nexus 4
kindly excuse brevity and typos.
On 9 Nov 2014 08:46, "John Curran" <[email-masked]> wrote:

> > The owner of trademark can use it to assert ownership not only of a
> directly corresponding domain name, but also of similar names.
> >
> > However that does not necessarily imply that it is desirable for the
> IETF Trust to own the IANA trademark. Trademarks (particularly ones
> involving registrations in multiple countries) can be quite expensive to
> register and protect. So unless the Trust has examined the costs involved
> and finds them manageable, it might make more sense to focus on the
> conditions for transfer to a successor contractor.
>

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 09 Nov 2014 08:19:55 -0500

> merit in being that owner, that is more than strictly necessary.)

The primary reason for addressing the issue is to avoid or reduce the 
potential for costly trademark litigation down the road.  If all remains 
cooperative, as may predict, then there's no issue at all. On the other 
hand, if an edge case arises - an attempt to change IANA contractors 
under less-than-cooperative situations - there is the potential for 
nasty litigation, as well as technical game playing.

As a general rule, organizations don't "go into business" with the 
expectation of unfriendly relations.  Contracts are written to create 
clarity as to roles, and responsibilities, and to attempt to detail, in 
advance, how edge cases are to be handled.  In the eventuality of things 
going wrong, the clearer the contract, the less likely things are to end 
up in costly litigation.

RFC2860 (or more accurately the MoU and supplemental agreements) contain 
pretty clearly written language (IMHO).  To the extent that we are 
recommending or proposing changes/additions to existing contractual 
arrangements, as part of our proposal response - it behooves us to be as 
clear.

To the earlier comment that we're spending way to much time on this:  
Each clause in a contract deserves as much attention as each paragraph 
in a technical spec.  That's the nature of the beast.

Miles Fidelman

---

From: John Curran <[email-masked]>
Date: Sun, 9 Nov 2014 05:34:37 -1000

On Nov 9, 2014, at 3:19 AM, Miles Fidelman <[email-masked]> wrote:
> The primary reason for addressing the issue is to avoid or reduce the potential for costly trademark litigation down the road.  If all remains cooperative, as may predict, then there's no issue at all. On the other hand, if an edge case arises - an attempt to change IANA contractors under less-than-cooperative situations - there is the potential for nasty litigation, as well as technical game playing.

Miles - 
 
  I was probably unclear in my points above - my first point is simply that
  if the use of the mark and domain name are deemed incidental to the proper 
  functioning of the IETF's protocol parameter registries, then the potential
  for costly trademark litigation is rather low, as the IETF can always switch 
  to use of some other name if continued use of the IANA name & mark is not 
  possible.

  If use of the IANA mark/name is important to proper functioning of the IETF's 
  protocol parameter registries, then some arrangement should be made so that 
  it is available for this purpose.  My second point was simply that arranging 
  for use of the mark/name does not mean obtaining ownership; it likely can be 
  accomplished with proper licensing regardless of the owner, and discussion 
  (in the case of use of the name/mark being relevant) should be focused on 
  ensuring the IETF has appropriate arrangements, which does not automatically
  mean requiring ownership of the marks and name.

> As a general rule, organizations don't "go into business" with the expectation of unfriendly relations. Contracts are written to create clarity as to roles, and responsibilities, and to attempt to detail, in advance, how edge cases are to be handled.  In the eventuality of things going wrong, the clearer the contract, the less likely things are to end up in costly litigation.

  Correct, but that refers to the desire for clear arrangements (which I was
  not arguing) - my point was simply that, should the IETF deem that it has
  a need in the use of the mark & name, it is not clear that ownership is the
  only option available.
  
/John

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 09 Nov 2014 11:25:00 -0500

>    mean requiring ownership of the marks and name.

Agreed.  They are two, separate issues.

Personally, speaking simply as the occasional  consumer of information 
from iana.org, it strikes me that clarity of where information resides 
IS important to the IANA function.  From a slightly wider point of view, 
given that we are talking about the "IANA transition" - it seems that 
the name/mark is inherently associated with the function, and it would 
be a significant change if we were, at some point, to have to change 
that.  ("Continuity of naming" if you will.)

>    a need in the use of the mark & name, it is not clear that ownership is the

Agreed, again - there are multiple ways this could be done.  My personal 
opinion is that having ownership in the hands of the incumbent 
contractor opens the door for potential difficulties in the future 
(having personally been through the hassles of dealing with domain name 
registration conflicts, following the re-organization of several 
different non-profits).

At the very least, I'd like to see something in our proposal that says 
that this is an issue that has to be addressed clearly as part of final 
transition arrangements.  I'd personally like to see the IETF lawyers 
weigh in and suggest a proposed approach to put forward to the ICG (when 
flagging a problem, it's always nice to be able to offer a solution).

Miles

---

From: Seun Ojedeji <[email-masked]>
Date: Sun, 9 Nov 2014 17:39:07 +0100

sent from Google nexus 4
that this is an issue that has to be addressed clearly as part of final
transition arrangements.  I'd personally like to see the IETF lawyers weigh
in and suggest a proposed approach to put forward to the ICG (when flagging
a problem, it's always nice to be able to offer a solution).
I did like to add a +1 to this. However I wonder the basis by which IETF
will be making such recommendation[1] especially considering the role it's
playing in this process(being a protocol parameter only community).

Cheers
1. However by the word "recommendation" implies that the ICG could perhaps
decide to mute. Making it a component of the proposal would have been
desirable.

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 9 Nov 2014 20:31:32 +0000

>  to use of some other name if continued use of the IANA name & mark is

That is my view of the situation. I can understand why people seek clarity
from lawyers, and indeed I can't claim I perfectly understand the legal
circumstances under which we currently use the IANA "mark" in our RFCs (if
it relies on anything beyond the RFC2860 agreement, say). But I see no
realistic contingency in which the IETF would enter into costly trademark
litigation to defend our right to populate a protocol parameter registry.
We would just populate a different registry. So I see no need to take
preemptive steps to secure the mark for ourselves. And then...

>  mean requiring ownership of the marks and name.

Explaining our past and present use of the IANA to the ICG, and then
empowering the IAOC to negotiate something that preserves "backward
compatibility" in the event of a transition (as I gather Eliot's language
soon will), should get us a certain way down this path. A license alone
can't cover some contingencies: in some sorts of transitions, licenses
might end up in flux. But if the IAOC believes securing some further
license would help preserve "backward compatibility" here, that'd be fine
with me. Still, if worst comes to worst, we're going to have other
remedies at our disposal than the courts.

Jon Peterson
Neustar, Inc.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Nov 2014 10:59:26 -1000

> remedies at our disposal than the courts.

[BA] A good portion of the complexity here is we are talking about a domain name and trademark that is relevant to multiple communities. If instead the IETF were to obtain a domain name only relevant to protocol parameters that could not be confused with the IANA trademark, then much of the complexity vanishes - we only need arrange for iana.org to point to that new domain and the IETF Trust would only need to be concerned with domain names and marks which would relate to IETF and IETF alone.  If the new mark would only need to be registered in a few countries the registration could be cost effective - and if the name were generic enough that it could not be trademarked easily then we might be able to avoid much or all of the registration cost.

---

From: John Curran <[email-masked]>
Date: Sun, 9 Nov 2014 11:51:10 -1000

On Nov 9, 2014, at 10:59 AM, Bernard Aboba <[email-masked]> wrote:
> 
> [BA] A good portion of the complexity here is we are talking about a domain name and trademark that is relevant to multiple communities.

Quite correct - the IANA mark and domain appears relevant to the IETF community,
due to the thousand or so protocol parameter registries published at that site and 
use of the name in many processes; to the Internet number community due to the 
publication of delegated number registries per RFC7020 and RFC7249; and to the 
DNS community due to their use with respect to administration of one particular 
protocol registry, i.e. the DNS root zone.

Personally, I would think it absurd for the IETF to abandon use of the term IANA
simply to avoid discussing arrangements for sharing its use, but then again, in 
the end it is the IETF community's call to make, as interpreted by the leadership.

/John

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 9 Nov 2014 22:12:15 +0000

>the end it is the IETF community's call to make, as interpreted by the

That would be absurd, yes. I have every expectation that we'll weather
this transition with little change to our operational relationship to
IANA. All of this rathole of a rathole has been about what steps we need
to take to safeguard against unlikely contingencies.

Well, at least, that's what I've been speaking to. Other people clearly
feel that we need to strike a posture of advocacy in order to effect
broader changes in Internet governance, and they want to use these
unlikely contingencies as a justification for us to take those steps.
While surely this is well intentioned, I've argued it's probably not the
IETF's job to lobby for those changes.

Jon Peterson
Neustar, Inc.

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 09 Nov 2014 20:01:13 -0500

Seun Ojedeji wrote:
> On 9 Nov 2014 17:25, "Miles Fidelman" <[email-masked] 
> >> On Nov 9, 2014, at 3:19 AM, Miles Fidelman 
> > At the very least, I'd like to see something in our proposal that 
> says that this is an issue that has to be addressed clearly as part of 
> final transition arrangements.  I'd personally like to see the IETF 
> lawyers weigh in and suggest a proposed approach to put forward to the 
> ICG (when flagging a problem, it's always nice to be able to offer a 
> solution).
> >
> I did like to add a +1 to this. However I wonder the basis by which 
> IETF will be making such recommendation[1] especially considering the 
> role it's playing in this process(being a protocol parameter only 
> community).
>

The basis being that IETF is one of the "users" of the IANA.org mark and 
domain - essentially the same basis as the other communities.

> Cheers
> 1. However by the word "recommendation" implies that the ICG could 
> perhaps decide to mute. Making it a component of the proposal would 
> have been desirable.
>

There's no reason a recommendation can't be part of the proposal. In 
essence, I see three things being stated, in the relevant parts of the 
document:

1.  that IETF uses the IANA mark and domain, and how

2.  that there are potential issues that could come up during the 
current and/or future transitions - specifically
--- making provisions for clear and smooth transition of 
ownership/control/licensing/delegation of the mark and name
--- anticipating the possibility that, at some future point, there may 
be different contractors performing different parts of the IANA 
function, which would require somewhat more complicated 
ownership/control/delegation/day-to-day management of the domain

3.  that, the final, combined, consensus proposal that the ICG delivers 
to NTIA, should include specific mechanisms, supplemental agreements, 
what-have-you that address the issues identified above, to be put in 
place as part of the transition process, and then go on to say:
- IETF has identified several options, including:
--- concluding supplemental agreements that provide for the transition 
of ownership/control/registration/etc. in the event of a change in IANA 
functions contractor(s)
--- placing ownership/control/etc. of the marks and domain in the hands 
of an entity other than the IANA functions contractor, such as,
------ the IETF Trust
------ an escrow account with a fiduciary institution, controlled 
jointly by the IETF, and the other stakeholder communities that rely on 
the IANA functions contractor
------ a joint entity created by, and controlled jointly by the IETF and 
the other.....
- and optionally, include a statement that, the IETF's lawyers and IAOC 
recommend option <x> as the one they see as most likely to support 
smooth transitions in IANA functions contractor(s)

Identify the issue.
Identify several solutions that we've identified.
Identify the one our lawyers recommend.
Then leave it to the ICG to manage reconciliation with anything the 
other communities come up with, as part of the next step in the process 
of getting to a proposal.

Anyway, that's how I'd approach it.

Miles Fidelman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Nov 2014 01:50:57 +0000

I have to say this thread seems fairly ridiculous to me. There's
maybe some remote possibility of potential issues for someone
with IANA as a trademark, but as stated by others, that's just
not interesting for the protocol parameters - in the face of any
such thorny legal issue, we'd just move to some other nomenclature
(e.g. the BLAHBLAH considerations section, or whatever) and we
would have no problems at all doing so.

However, I do think Andrew earlier made a good point that those
most exercised by this possibility are perhaps (or perhaps vastly)
overestimating its probability due to a disconnect between their
experience and the reality of IETF protocol parameters, so in the
spirit of trying to help close that gap, here's another bit of
information about how things work hat I don't recall having been
posted here (apologies if it has) ...

> nasty litigation, as well as technical game playing.

I don't see much game playing here of interest. The fact is that
implementers do not start by reading the IANA registries. We had
a long discussion on that between the IESG and some authors of a
Diameter RFC a few years ago where the author concerned (Glen Zorn)
convinced me at least that updating RFC text is basically far more
of interest than updating IANA registries.

Many people write code that uses libraries and don't even see RFCs.
Fewer by far have to start from an RFC to write their code. The
number of people who actually consult the IANA protocol parameter
registries is a yet again much smaller set. (Given that the protocol
parameter registry entries alone are not sufficient to implement in
almost all cases and that RFCs that specify protocols almost always
contain enough that one doesn't have to go looking at an IANA
registry to implement.)

The set of people who start anything from consulting an IANA registry
is probably almost infinitesimally small, and I would say is
basically IESG members, designated experts and IANA staffers, none
of whom are going to be in the least confused by any trademark
crapology.

So a lot of the concern expressed about potential downsides here is
just misplaced as the real source of protocol parameters used by
developers is the RFC series and not IANA anything.

S.

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 10 Nov 2014 02:41:48 +0000

> Removal of or rehoming some of the trappings of power (who controls
> IANA.*) seems like a niche question at best.
> 
> For me, the more fundamental problem is:  a) how to tell when an operator
> of one of these functions has lost it,  and  b) how to neutralize the impact of
> a rouge operator.

:-) I assume you mean rogue. (Hope pointing out this typo doesn't make you red-faced.)

Well of course, the issue of when to abandon a particular operator is more fundamental, and the ability to switch is critical to the ability to neutralize a rogue operator. 

But I am perfectly content to let the IETF make that decision as they see fit at some point in the future. All we can do now is ensure that if or when they do have to make such a decision, the path will be as smooth as possible for them to make a switch. That is, by handling the domain and TM correctly, we can lower switching costs.

---

From: manning bill <[email-masked]>
Date: Sun, 9 Nov 2014 20:43:07 -0800

thank you for your understanding of  a) my dyslexia and b) autocorrect 

i am  glad that the fundamental questions are answered and there is now time and interest to work on the minor details.
Have we started to grapple with the issues of IANA.ORG in alternate encodings/scripts yet?

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 10 Nov 2014 16:34:52 +0900

> protocol registry, i.e. the DNS root zone.

This actually points to a solution for at least part of the problem of 
what to do in the odd case that these communities would delegate their 
registries to different operators:

One community (or its registry operator) operates iana.org, and 
redirects the relevant pages for the registries of the other operators 
to the actual pages. As an example, if the protocol parameters registry 
kept iana.org, it would delegate (almost?) everything below 
http://www.iana.org/domains to the DNS community, and so on.

Such a delegation can be made as an internal redirect (the actual 
data/pages come from elsewhere, but are served by iana.org) or as an 
external redirect (if somebody goes to e.g. http://www.iana.org/domains, 
then s/he's redirected to the site of the other operator).

This shows that having different organizations take care of the 
different registries and still sharing iana.org is possible. This of 
course requires that they agree to do that.

But my guess is that agreeing to share iana.org is much easier that to 
agree e.g. about reserved labels (such as .local) in the root zone. The 
later is crucial for the functioning of the Internet, and if that can be 
agreed on, then an agreement on the former should also be possible.

So I very much think that the question of "But what if the registry 
operator function is split up?" cannot be used as an argument for not 
talking about the trademark and domain name transfer.

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 10 Nov 2014 16:49:28 +0900

On 2014/11/10 05:59, Bernard Aboba wrote:
>> soon will), should get us a certain way down this path.

I agree. But I'm not sure about the words "backwards compatibility", I 
think it's a technical term that some of the audience of our document 
may not understand, and by itself it's unclear exactly what it refers to.

>> A license alone
> [BA] A good portion of the complexity here is we are talking about a domain name and trademark that is relevant to multiple communities. If instead the IETF were to obtain a domain name only relevant to protocol parameters that could not be confused with the IANA trademark, then much of the complexity vanishes - we only need arrange for iana.org to point to that new domain and the IETF Trust would only need to be concerned with domain names and marks which would relate to IETF and IETF alone.  If the new 
 ma
>   rk would only need to be registered in a few countries the registration could be cost effective - and if the name were generic enough that it could not be trademarked easily then we might be able to avoid much or all of the registration cost.

This implies that ICANN currently has registered the trademark IANA is a 
large number of countries. My guess is that one part of the reason is 
that they have the money and the staff to do that, and the other part of 
the reason is that they try hard to be all-inclusive geographically and 
politically.

I'm not a lawyer, but my guess is that the number of trademark 
registrations to be able to defend the domain name should be much lower 
than that.

Regards,   Martin.

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 10 Nov 2014 15:08:11 +0000

> [BA] A good portion of the complexity here is we are talking about a
> domain name and trademark that is relevant to multiple communities.

That sounded reasonable at first, but when I think about the names community, or at least the ongoing process of RZF management and modifications, I see little reason why they would care about the IANA domain or trademark per se. 
I could see why the numbers community cares about the .arpa domain, but not so much the IANA domain. 
Perhaps the IETF _is_ the best place for those resources to live. 

[MD] 
> Quite correct - the IANA mark and domain appears relevant to the
[snip] 
> Internet number community due to the publication of delegated
> number registries per RFC7020 and RFC7249; and to the DNS community due
> to their use with respect to administration of one particular protocol
> registry, i.e. the DNS root zone.
> 
> what to do in the odd case that these communities would delegate
> their registries to different operators:
> 
> redirects the relevant pages for the registries of the other operators to
> the actual pages. As an example, if the protocol parameters registry
> external redirect (if somebody goes to e.g.
> http://www.iana.org/domains, then s/he's redirected to the site of
> the other operator).
> 
> different registries and still sharing iana.org is possible. This of course
> requires that they agree to do that.
> 

Interesting approach. Sounds feasible to me.

---

From: David Conrad <[email-masked]>
Date: Mon, 10 Nov 2014 07:04:30 -1000

On Nov 10, 2014, at 5:08 AM, Milton L Mueller <[email-masked]> wrote:
>> A good portion of the complexity here is we are talking about a

A quick scan shows:

whois.iana.org
rzm.iana.org
http://www.iana.org/domains
http://www.iana.org/dnssec
http://data.iana.org/root-anchors/
http://data.iana.org/ksk-ceremony/

> I could see why the numbers community cares about the .arpa domain, but not so much the IANA domain. 

According to the terms of RFC 3172, .ARPA is managed jointly by the IAB and ICANN:

                     "The Internet Architecture Board (IAB) has the
   responsibility, in cooperation with the Internet Corporation for
   Assigned Names and Numbers (ICANN), to manage the "arpa" domain."

Regards,
-drc

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 10 Nov 2014 11:07:39 -0800

> For me, the more fundamental problem is:  a) how to tell when an operator of one of these functions has lost it,  and  b) how to neutralize the impact

I agree that one particular name-to-resources mapping is not a 
fundamental question. There are important names within the namespace, 
but transition is not intractable, in my opinion.

I suggest that the illumination of a ns constellation by CNNIC in 
2001/2002 and the publication of a non-identical zone file in (IIRC) 
2004 is evidence of "when an operator of one of those functions has lost 
it", though I expect there will be disagreement as to which operator 
"lost it". I suggest that the subsequent continuous publication of a 
non-identical zone file is also evidence of "how to neutralize the 
impact of a rogue operator", though again I expect there will be 
disagreement as to which operator's action, or lack of action, will be 
seen as rogue.

See also the effect of precluding, by intent or lack of oversight, use 
of the GOST suite to sign zones.

My point being that we can treat failure as a hypothetical future, or we 
can take a look at some available technical consequences of recent 
policies, and extrapolate for equivalent or greater failures.

Eric

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 10 Nov 2014 19:11:58 +0000

>talking about the trademark and domain name transfer.

Well, there's a big difference between "talking about the trademark and
domain name transfer" and directly requesting the reassignment of
corporate property preemptively for our peace of mind. We currently have
some text in our draft ICG response intended to protect us in the
eventuality of a transition, and we will continue to in the future. So I
don't think anyone is arguing against "talking," it's more about the
nature of the discussion. Ideally, we will grant the IAOC the latitude
they need to cover our backs, rather than being overly prescriptive in the
ICG response.

And sure, after the hypothetical division of the IANA function into
multiple operators, I could imagine engineering practices that might, at
least for a transitional period, rely on DNS or web redirects to dispatch
requests from iana.org to the new operators. That would be one of several
directions worth exploring. Fortunately, access to the IANA registries, as
Stephen Farrell recently noted, does not have the same operational
requirements as accessing the root of the DNS - not by a very long shot.

But what does that mean for the purposes of this discussion? If the
registries split up acrimoniously, we have no shortage of options for
engineering a protocol parameter registry transition, including just
forking it. Tricky to do that with a mission-critical resource like the
root of the DNS, definitely, but much less tricky when we're talking about
a registry that is infrequently consulted, and almost always consulted by
developers and protocol designers. This makes the IETF's requirements for
a transition a bit easier to solve for. Our job on this mailing list is to
solve for those requirements.

Jon Peterson
Neustar, Inc.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Nov 2014 09:19:16 -1000

FWIW, I agree with Stephen’s mail on this topic.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 10 Nov 2014 09:26:30 -1000

While I agree that only a subset of developers ever go to IANA, they are
roughly the same set of developers who use RFCs.  We would not be having
this discussion if we wanted to protect against misrepresentation of the
RFC series.  As someone who is a designated expert for port numbers, I
will also say that we don't want to make it any more difficult than it
already is for people to make applications for our protocol parameters,
nor do we want to break any processes (automated or human) that retrieve
the protocol parameters so that they are included in the right places in
various distributions.

Eliot

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 10 Nov 2014 14:37:20 -0500

Hi Eliot,

> the protocol parameters so that they are included in the right places in

I think that is a desirable state of affairs.  I think there is an
open question, however, about how valuable that is as compared to
other desiderata.  I think that may be part of what the discussion
recently has turned on.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 10 Nov 2014 19:40:09 +0000

And well, we know there are certain protocol parameter registrations that
don't come form our I-Ds and RFCs. If it were the case that literally all
of IANA's protocol parameter registry entries originated in IETF
specifications, a new set of potential remedies would become available to
us. Alas, no.

But I do think Stephen is right that the community that interacts with
IANA is a small and technically sophisticated one, and that this means
that we don't have to worry too much about holding their hands in the
event of a transition. The situation of the root zone, say, is very
different. The potential for damaging "breakage" in the protocol parameter
registry is quite small.

Jon Peterson
Neustar, Inc.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Nov 2014 19:44:05 +0000

On 10/11/14 19:40, Peterson, Jon wrote:
> 
> ... the community that interacts with

Right - that gets to the point better than I did.

S.

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 10 Nov 2014 20:11:02 +0000

> corporate property preemptively for our peace of mind. We currently have

By "talking about the trademark and domain name transfer" Martin clearly meant that we should talk about it here in order to _decide_ what to do about it as part of the transition. Let's avoid playing rhetorical games.

You refer to "the reassignment of corporate property" as if it were an intrinsically threatening thing. But it isn't. ICANN was given the domain and the trademark by the USG as part of a similar - but in some ways, far less legitimate and consensual process - 16 years ago. We are being asked to provide the USG with an institutional re-design that keeps IANA accountable in the absence of the NTIA oversight. If reassigning those assets is a necessary part of the plan, we have every right to ask for it; indeed, we have an obligation to do so.  

> Ideally, we will grant the IAOC the latitude they need to cover our backs,
> rather than being overly prescriptive in the ICG response.

Agreed, but there is nothing "overly prescriptive" about mentioning the trademark and domain as important factors to be dealt with in the transition.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Nov 2014 10:21:44 -1000

All,

I wanted to post something on this thread that isn’t merely a reaction to the previous e-mail.

This has been a long thread, and I’m not sure we’ve always succeeded in having a clear discussion, let alone avoid repetition of the same arguments. I wanted to share my thoughts on this at a more principle level, however.

I think we are in a process where we can and must design the future in the best possible way. Including dealing with possible contingencies. And the design process is very public, everyone’s actions being visible to the global community. I do not think we should do anything else than what best works for us. We do not need to be afraid of proposing to do the right thing.

But there is of course the question of what that right thing is. In my mind, the primary criteria is that it works for the IETF. That we can do our work, and can continue to do our work in the future. Not less, but also not more.

We also have to recognise that we live in a global Internet and within an ecosystem of other parties dealing with other issues. Whatever we do needs to be co-operative such that the needs of all parties employing the domain name can be accommodated.

Per the charter of the WG, we are expected to specify the transition plan. We do not have to (and indeed should not) specify procedural or contractual details. However, the group needs to deliver clear instruction on what it expects to happen, so that specialists and perhaps other parties can do what is necessary.

(And I think what is currently proposed at http://www.ietf.org/proceedings/91/slides/slides-91-ianaplan-1.pdf fits the above and I have no problem with it.)

Jari