Subject: [Ianaplan] Trial balloon: suggested text

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Tue, 18 Nov 2014 12:43:32 -0500

Out of band, there's been a suggestion of text for a possible "middle
ground" between -02 and -03.

While, as one of the chairs of this WG, I am pretty comfortable that the 
-03 version of the document reflects the WGLC comments, and that we have 
(rough!) consensus to move forward, I'd like to hear whether proponents 
of -02 text think this suggestion is better than -03 (and, from -03 
proponents, whether this is unacceptable).

[Elsewhere, Andrei Robachevsky suggested the following change:]

[OLD] draft-ietf-ianaplan-icg-response-03:

> IANA protocol parameters registry updates will continue to function
> day-to-day, as they have been doing for the last decade or more.  The
> IETF community is quite satisfied with the current arrangement with
> ICANN.  RFC 2860 remains in force and has served the IETF community
> very well.  RFC 6220 has laid out an appropriate service description
> and requirements.
>
> The protocol parameters registries are in the public domain.  It is
> the preference of the IETF community that all relevant parties
> acknowledge that fact as part of the transition.
>
> It is possible in the future that the operation of the protocol
> parameters registries may be transitioned from ICANN to subsequent
> operator(s).  It is the preference of the IETF community that, as
> part of the NTIA transition, ICANN acknowledge that it will carry out
> the obligations established under C.7.3 and I.61 of the current IANA
> functions contract between ICANN and the NTIA [NTIA-Contract] to
> achieve a smooth transition to subsequent operator(s), should the
> need arise. Furthermore, in the event of a transition it is the
> expectation of the IETF community that ICANN, the IETF, and
> subsequent operator(s) will work together to minimize disruption in
> the use the protocol parameters registries or other resources
> currently located at iana.org.

NEW:

IANA protocol parameters registry updates will continue to function
day-to-day, as they have been doing for the last decade or more.  The
IETF community is quite satisfied with the current arrangement with
ICANN.  RFC 2860 remains in force and has served the IETF community very
well.  RFC 6220 has laid out an appropriate service description and
requirements.

However in the absence of the NTIA contract a few new arrangements have
to be put in place that will ensure that:

1) The protocol parameters registries are in the public domain.

2) In case of future need to transition the operation of the protocol
parameters registries from ICANN to subsequent operator(s), this
transition will be smooth and have minimum disruption in the use the
protocol parameters registries or other resources currently located at
iana.org. This arrangement should be comparable to current obligations
established under C.7.3 and I.61 of the current IANA functions contract
between ICANN and the NTIA [NTIA-Contract].

3) For any future change in the cost of providing these services
(currently at zero cost), these costs are fair and reasonable,
negotiated, and ample time is given for the transition to the new cost
and fee structure.

Leslie.

-- 

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 18 Nov 2014 13:22:17 -0500

> While, as one of the chairs of this WG, I am pretty comfortable that the -03 version of the document reflects the WGLC comments, and that we have (rough!) consensus to move forward, I'd like to hear whether proponents of -02 text think this suggestion is better than -03 (and, from -03 proponents, whether this is unacceptable).
> 
> 

I do nto understand the need for the third point.  The current MoU requires 6 months notice, and the requirement for ample notice does not seem to belong here.  Further, the cost of a different provider (as well as any transition costs) are a topic for IASA.

Russ

---

From: Ray Pelletier <[email-masked]>
Date: Tue, 18 Nov 2014 08:24:39 -1000

Leslie

I like the detail and tone of the new language.

Inline

> negotiated, and ample time is given for the transition to the new cost

these costs are negotiated, fair and reasonable, and sufficient time is
provided for the new cost to be included within the following fiscal year budget.

Ray

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

---

From: Milton L Mueller <[email-masked]>
Date: Tue, 18 Nov 2014 18:36:58 +0000

This looks pretty good to me. The sentence starting with "However in the absence of the NTIA contract..." is essential to what wins me over: at least we are recognizing reality, linking it to the NTIA change and proposing a plan. Would there need to be any specification of who would put these arrangements in place? 

A few minor comments inline

> -----Original Message-----
> 
> NEW:
> 
> IANA protocol parameters registry updates will continue to function day-to-
> day, as they have been doing for the last decade or more.  The IETF
> community is quite satisfied with the current arrangement with ICANN.  RFC

Can we just say "satisfied"?

> 2860 remains in force and has served the IETF community very well.  RFC
> 6220 has laid out an appropriate service description and requirements.
> 
> parameters registries from ICANN to subsequent operator(s), this transition

Nit: "the" transition rather than "this" transition

> will be smooth and have minimum disruption in the use the protocol

Nit: "in the use _of_ 

> parameters registries or other resources currently located at iana.org. This
> arrangement should be comparable to current obligations established under
> C.7.3 and I.61 of the current IANA functions contract between ICANN and the
> NTIA [NTIA-Contract].
> 
> 3) For any future change in the cost of providing these services (currently at
> zero cost), these costs are fair and reasonable, negotiated, and ample time is
> given for the transition to the new cost and fee structure.

In response to a previous commenter, I understand this wording to address the adjustment to a new fee structure, not the 6 month notice for the termination of the prior agreement. 

Ray's suggested amendment works for me.

---

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

I think this illustrates the difficulties of seeking a "compromise"
position on whether or not this working group will engage with the legal
issues. 

If, in a post-transition environment, a new IANA protocol parameter
registries operator wanted to "negotiate" for some price increase per the
third bullet, um, I don't think the proposed text reflects the needs or
recourses of the IETF under the circumstances. I think this is more
language that seems to suggest that the IETF is somehow beholden to the
IANA operator (as it did in -02), and that we would even entertain
discussion about a "new cost and fee structure" for something that, per
the first bullet, we believe to be in the public domain and which we could
replace with an alternative (free) service without undue difficulty. I
don't want the document we publish here in ianaplan to say that we intend
to "negotiate" under those circumstances. So, in that regard, this doesn't
work for me, no.

I am elsewhere concerned about some of the passive voice in there
(language like "have to be put in place"). Text like "this transition will
be smooth" is to my mind much weaker and less enforceable the -03 text
stating our expectations of who will work together to minimize disruption
in a transition. The text in -03 asking all relevant parties to agree that
the protocol parameter registries are in the public domain seems valuable
and I don't know why we'd drop it. We could wordsmith around some of that,
sure, but I'd rather just stick with the -03 text for now.

Jon Peterson
Neustar, Inc.

On 11/18/14, 10:22 AM, "Russ Housley" <[email-masked]> wrote:

>> While, as one of the chairs of this WG, I am pretty comfortable that
>>the -03 version of the document reflects the WGLC comments, and that we
>>have (rough!) consensus to move forward, I'd like to hear whether
>>proponents of -02 text think this suggestion is better than -03 (and,
>>from -03 proponents, whether this is unacceptable).
>> 
>> 
>I do nto understand the need for the third point.  The current MoU
>requires 6 months notice, and the requirement for ample notice does not
>seem to belong here.  Further, the cost of a different provider (as well
>as any transition costs) are a topic for IASA.
>
>Russ
>

---

From: Geoff Huston <[email-masked]>
Date: Wed, 19 Nov 2014 05:47:46 +1100

> On 19 Nov 2014, at 4:43 am, Leslie Daigle (TCE) <[email-masked]> wrote:
> 
> 

It's hard to understand the context of 3) given that 2) contemplates a change from
ICANN to some other contractor and 3) contemplates (I think) a change in
the arrangements with ICANN that would be proposed by ICANN (i.e. a change in the
fees charged by ICANN).

As it stands this third bullet is either extraneous or does not go far enough. What
it appears to be saying is that the IETF wishes to protect itself from
unilateral changes to the arrangements initiated by the current contracted IANA 
functions operator, and is declaring that the IETF has the ability to negotiate
any changes to the current arrangements, and such negotiations include the 
possibility of selecting a different contractor or contractors. I struggle to
understand why this should just be about cost.

Or, of course, we could stick to the original text. Personally I'm in favour of
NOT changing the document, if the proposed text in 3) is that alternative.

regards,

    Geoff

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Nov 2014 19:47:57 +0100

Hi John,

> to "negotiate" under those circumstances. So, in that regard, this doesn't

I think you misunderstand the point.  It costs money to run the IANA
service.  The NTIA contract constrains ICANN from charging.  Once that
contract is there, then there is no such constraint.  ICANN could
announce that the next day they will charge a fee.  I'm not saying they
would, but they could.

> sure, but I'd rather just stick with the -03 text for now.

And here again, I think you misunderstand.  The passive language states
the results we want from the IAOC.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Nov 2014 19:49:19 +0100

Sorry- editorial goof:

> announce that the next day they will charge a fee. I'm not saying they

That should of course read "Once that contract is NOT there"...

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 18 Nov 2014 19:15:09 +0000

>announce that the next day they will charge a fee.  I'm not saying they

It costs money to run IANA as it exists today, and some amount of that
goes to running the protocol parameter registries as they exist today. If
after the NTIA steps aside ICANN suddenly declared they were going to
extract a fee from the IETF for running the protocol parameter registries,
we would have several alternatives beyond the one enumerated in bullet
three, so I'd doubt we'd gracefully "transition to the new cost fee and
structure." Similarly, if after a change in IANA operator(s), someone
comes to the IETF and demands money to run the protocol parameter
registries as they exist today, I don't think their expectation should be
that the IETF would like to "negotiate."

I am very wary of text that suggests that the IETF would contract for a
protocol parameter registry service like our existing one in the event of
a hostile change: and a hostile change is the contingency that we are
carefully crafting this fancy language for. Yes, we like RFC2860, and we
have every expectation we'll continue along those lines. But our recourse,
the IETF's recourse, in the event that arrangement is no longer possible
is not going to hinge on contract language about fair and reasonable terms
in the face of proposed fee increases. I think it is more likely that we
would instead seek an alternative technical solution. This language
conveys the impression that we would not. That's why I don't like it.

>the results we want from the IAOC.

Whatever the intention behind it, language like "a few new arrangements
have to be put in place that will ensure that" is too vague to be viable.
I find the -03 statements that "it is the preference of the IETF community
that X acknowledge Y..." to be clearer.

Jon Peterson
Neustar, Inc.

---

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

On 19/11/2014 07:22, Russ Housley wrote:
<snip>

> I do nto understand the need for the third point.  The current MoU requires 6 months notice, and the requirement for ample notice does not seem to belong here.  Further, the cost of a different pro…

I agree. Our current agreement with ICANN specifies that there
is no charge to register or view protocol parameter values and
we state elsewhere that we wish that agreement to continue. We
don't want it to be replaced by "fair and reasonable" costs. If
a new provider attempted to impose costs, we'd probably blow the
explosive bolts and look elsewhere, but in any case this text is
redundant.

(Points 1 and 2 are fine IMHO.)

    Brian

---

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Nov 2014 13:55:41 -0800

So, the short and sweet is:  I prefer the -03 language to the proposed
language below, and I think the chairs should go with the existing rough
consensus on it.

The somewhat longer version is that the aims of the -03 language cited (at
least as I understand them) are to highlight that we think things are
working reasonably now, reconfirm the nature of the data at issue, and
ensure that ICANN agrees to work with the IETF in the event of a future
transition.

The new language introduces a different question and, honestly, it doesn't
do it very well.  It doesn't clearly distinguish between the cost to
provide the service and the cost to access the service.  Reading that bare
language, it is not even  clear whether the issue is keeping costs paid by
the IANA operator fair and reasonable or whether it is keeping the costs to
access the service fair.  Assuming the second, it doesn't acknowledge that
changing the costs to access the service would cause a re-examination of
the need for a successor, even though it is a likely outcome.  It's a
muddle, but clarifying it probably isn't all that useful.  If we find
ourselves needing to work through alternative funding models for making
this data available to all, the particulars of the circumstances will be an
important factor in determining how to go forward.  Let's not bind our
hands on this; let's stick to crafting language for *this* transition.

regards,

Ted

On Tue, Nov 18, 2014 at 9:43 AM, Leslie Daigle (TCE) <
[email-masked]> wrote:

> (rough!) consensus to move forward, I'd like to hear whether proponents of
> -02 text think this suggestion is better than -03 (and, from -03

---

From: Eliot Lear <[email-masked]>
Date: Tue, 18 Nov 2014 22:58:24 +0100

> (Points 1 and 2 are fine IMHO.)

Although I personally have no problem with 3, I could support moving
forward with just 1 and 2.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Nov 2014 13:59:32 -0800

> conveys the impression that we would not. That's why I don't like it.

I agree with Jon here. It's not at all clear that we would continue with the
current general IANA interaction model if we were forced to directly
pay for the services. I would prefer the -03 text.

-Ekr

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 19 Nov 2014 01:49:42 +0000

I think people are over-focusing on the cost issue to avoid dealing with the real difference in the "trial balloon" - the differences that really matter. Let me try to highlight the differences more clearly. 

> [NEW]
> to be put in place that will ensure that: (etc.)

OK, what's the difference here? The OLD says IETF has a "preference" that all parties acknowledge that the registries are in the public domain. What if all relevant parties do _not_ make this acknowledgement? Nothing is specified. Nothing happens. This is not a transition plan. This is a description of your current mental state. I cannot understand how anyone can think stating a preference that could be ignored by any relevant party is a transition plan, or provides adequate protection to IETF's interests.

The NEW version states more directly that "new arrangements have to be put in place to ensure that..."
The NEW version is better. It's an actual transition plan, which IETF has every right to make and every reason to expect that the broader community, the NTIA and ICANN will go along with. 

> >[OLD}
> > It is the preference of the IETF community that, as part
> > of the NTIA transition, ICANN acknowledge that it will carry out the
> > obligations established under C.7.3 and I.61 of the current IANA
> > achieve a smooth transition to subsequent operator(s), should the need
> > arise. 

Again, you are stating a preference, but you are not ensuring that your preference is followed or even acknowledged by anyone. The new version makes this stronger.

> > Furthermore, in the event of a transition it is the expectation
> > of the IETF community that ICANN, the IETF, and subsequent operator(s)
> > will work together to minimize disruption in the use the protocol
> > parameters registries or other resources currently located at
> > iana.org.

So the claim is that ICANN will magically respect and abide by vague expressions of "preferences" and "expectations." It's nice to have expectations. It is my expectation that my son not spend 8 hours on Xbox. But unless I take measures to prevent him from doing so, that expectation is unlikely to be met.  

> given for the transition to the new cost and fee structure.

On the cost issue, let me see if I understand the position of the people who object to this. They are saying that if we don't say anything about this in the RFP, no changes in the cost will ever happen. Or they are saying that if we don't put the word "negotiation" in the text, then we will never have to negotiate with an IANA who wants to charge. Both are obviously false.

So if both of those possibilities are out, I guess the least absurd thing they are saying or implying is that if any undesirable changes are threatened or proposed - the so-called hostile scenario - that things will be so bad that making any plans will be pointless and so the IETF should just improvise if and when it happens. That, too strikes me as really bad logic, but also as completely irresponsible. I think future contingencies will be easier to handle if they are identified and your objectives are made clear. Of course you cannot identify all possible contingencies but you can specify the major ones that would affect IETF. 

--MM

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 19 Nov 2014 02:05:42 +0000

Jon:

> It costs money to run IANA as it exists today, and some amount of that goes
> to running the protocol parameter registries as they exist today. If after the
> NTIA steps aside ICANN suddenly declared they were going to extract a fee
> from the IETF for running the protocol parameter registries, we would have
> several alternatives beyond the one enumerated in bullet three

Sure, but the existence of other alternatives does not in the least bit detract from the benefit that might be obtained by requiring ICANN to maintain fair and reasonable rates and to provide an adjustment period phasing in a new, negotiated cost structure. If IETF decides that it does not like the fee structure, it can make alternate arrangements. But it is possible that the alternate arrangements would not be as easily implemented as you think. The burden of proof is on you to demonstrate any harm that is done by protecting against the fee contingency in that way.

>Similarly, if
> after a change in IANA operator(s), someone comes to the IETF and demands
> money to run the protocol parameter registries as they exist today, I don't
> think their expectation should be that the IETF would like to "negotiate."

I believe this is a misreading of the text. To me it is evident that the text refers to the current IANA provider (ICANN) suddenly deciding to charge fees. It creates no expectations regarding what a new provider would do. And it would be easy to clarify that if we want to.

> protocol parameter registry service like our existing one in the event of a
> hostile change: and a hostile change is the contingency that we are carefully
> crafting this fancy language for. Yes, we like RFC2860, and we have every
> expectation we'll continue along those lines. But our recourse, the IETF's
> recourse, in the event that arrangement is no longer possible is not going to
> hinge on contract language about fair and reasonable terms in the face of
> proposed fee increases. I think it is more likely that we would instead seek an
> alternative technical solution. This language conveys the impression that we
> would not. That's why I don't like it.

A false conclusion again. The language does not contain any implication or impression that IETF will or will not seek an alternative technical solution. It merely says that if ICANN cannot suddenly spring a charging structure on IETF. What is wrong with that? 

> I find the -03 statements that "it is the preference of the IETF community that
> X acknowledge Y..." to be clearer.

No. A direct statement that new arrangements have to be put in place is not "vague." A statement that the IETF has a "preference" that ICANN "acknowledge" something is vague. It is an expression of sentiment that has no effect. 

I am really having trouble making sense of your perspective. It really seems like you're grasping at straws.

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 18 Nov 2014 21:38:51 -0500

In general, this strikes me as a step in the right direction.  Some 
comments added in-line...

>> 1) The protocol parameters registries are in the public domain.

I REALLY think this merits more thought about the intent of the 
statement, and run by the lawyers, for two reasons:

1. public domain does not exist in all jurisdictions, and its meaning 
also changes from jurisdiction to jurisdiction

2. release to the public domain risks distribution of corrupted, 
non-authoritative data - perhaps better for IETF to hold copyright, and 
release under an appropriate creative commons license -- allowing for at 
least some means of exerting control of the authoritativeness, and 
accuracy of the registry contents

>> given for the transition to the new cost and fee structure.
I tend to agree with the statements that this is an invitation to start 
charging.  Better to amend the MoU to incorporate a clear requirement 
that the services remain free.  (I've lost track, is this one of those 
things the NTIA contract says has to remain free? If yes, why not 
propose amending the MoU to include what the NTIA contract says?)

Miles Fidelman

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

---

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

On 19/11/2014 14:49, Milton L Mueller wrote:
...
>> 3) For any future change in the cost of providing these
>> services (currently at zero cost), these costs are fair and
>> reasonable, negotiated, and ample time is given for the
>> transition to the new cost and fee structure.
> 
> On the cost issue, let me see if I understand the position of
> the people who object to this. They are saying that if we
> don't say anything about this in the RFP, no changes in the
> cost will ever happen. Or they are saying that if we don't
> put the word "negotiation" in the text, then we will never
> have to negotiate with an IANA who wants to charge. Both are
> obviously false.
> 
> So if both of those possibilities are out, I guess the least
> absurd thing they are saying or implying is that if any
> undesirable changes are threatened or proposed - the
> so-called hostile scenario - that things will be so bad that
> making any plans will be pointless and so the IETF should
> just improvise if and when it happens. 

No, no improvisation is implied. We'd simply arrange to create a
new IETF Protocol Parameter registry and registrar under our own
steam, probably by competitive bid, but that would be for the
IAOC to decide. We already have the text of the statement of
work and the service level agreement we'd need.

Truly, that's been the contingency plan since 1998, but the IANA
service has been such that we've never considered invoking it.

That seems much preferable to committing today to negotiate
prices with a monopolist. *That* would be irresponsible.

   Brian

> That, too strikes me
> as really bad logic, but also as completely irresponsible. I
> think future contingencies will be easier to handle if they
> are identified and your objectives are made clear. Of course
> you cannot identify all possible contingencies but you can
> specify the major ones that would affect IETF.
> 
> --MM
> 
> _______________________________________________ Ianaplan
> mailing list [email-masked]

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 19 Nov 2014 03:47:34 +0000

A bit of the ol' inline below.

On 11/18/14, 6:05 PM, "Milton L Mueller" <[email-masked]> wrote:

>>goes
>Sure, but the existence of other alternatives does not in the least bit
>detract from the benefit that might be obtained by requiring ICANN to
>maintain fair and reasonable rates and to provide an adjustment period
>phasing in a new, negotiated cost structure. If IETF decides that it does
>not like the fee structure, it can make alternate arrangements.

Well, I fear we'll be talking past one another again here, but try, try
again.

I suspect most of our disputes really derive from the difference in
philosophy illustrated by this point above. Since we're entertaining the
"hostile" cases here, let me try to put this in the starkest, most
confrontational terms. I believe that any value that exists in the
protocol parameter registries exists because we (the IETF) choose it as a
place to store values. If an operator of the protocol parameter registry
insisted on an arrangement that was not acceptable to us, we would simply
store parameters elsewhere, thereby eliminating any value in the old
protocol parameter registry. They would lose everything, we would lose
nothing. The notion of a hostile party inheriting IANA and imposing an
unacceptable fee structure on us for handling data of this nature is
therefore, well, preposterous, just self-defeating, and would be a
colossal political blunder. All it would do is put the old protocol
parameter registry out of business, in a rather humiliating and public
manner.

Ted wisely distinguished the value of the parameters themselves from the
value of a provider ingesting IANA registrations and then making the
parameters available to the Internet. But for the purposes of this
question, that distinction doesn't much change my assessment. I'm grateful
to the folks at IANA who have made sense out of some of my bungled
protocol work over the years, and I don't mean to belittle that. But the
value in their work is totally predicated on the fact that our
specifications create and populate those registries. We are not in a
position of dependence on this registry, where we need to "protect" our
rights to it, and any language that seems to cast things that way is
problematic to me.

>But it is possible that the alternate arrangements would not be as easily
>implemented as you think.

I'm sure when I said "we would lose nothing" above, someone read that and
thought, "but transitioning away from RFC2860 surely costs something." I
can imagine a chartered accountant descending on this argument to weigh
protocol parameter registry fee structure scales against the supposed
costs of transition, which includes amending every RFC ever published
anywhere that it might reside on the Internet, which is surely in the
zillions. But (as has previously been discussed on this list) the
community that actually uses the protocol parameter registries is small,
savvy, and adaptable. I think the IETF would say "we're doing something
else now," Slashdot would dutifully repeat it, people out there would heed
us or not as they saw fit, and then we'd all go back to work without
losing a jot of relevance.

Thus I feel comfortable, as an engineering assessment, that alternate
arrangements could easily be implemented. I'd venture that other IETF
participants familiar with the registries on the list have expressed a
similar comfort level.

>The burden of proof is on you to demonstrate any harm that is done by
>protecting against the fee contingency in that way.

The harm being done? Starkly and confrontationally, I think bullet 3 reads
like an invitation for a protocol parameter registry operator to
completely misconstrue their relationship to the IETF and to impose fees
on us as soon as the NTIA steps aside, as we are apparently amenable to
negotiation towards a new fee structure in that eventuality. Especially
because, you know, transition costs would surely be in the zillions if we
have to move to a new system, so we in the IETF must be in a tough spot.
But I don't think we should be amenable to that negotiation, and nor is
this an eventuality worth calling out in the ICG response. Why would we
even raise this?

It also implies that we would seek a relationship like the one we have
with IANA today in the event of unlikely contingencies disrupting the
administration of the protocol parameters registry. I suspect that if we
had to break with RFC2860, we would probably use something that looks
considerably different from past relationships and systems. The technical
world has changed since IANA was conceived - changed a lot. Lots of things
that were then expensive to distribute and maintain with resilience on the
Internet are now, well, effectively free. And we do IANA a disservice
today by not giving them registration data in more structured forms. And
so on.

Again, what we got now (RFC2860) ain't broke, and thus I don't propose to
fix it. But if it got broke, I don't want any text here to bind us to the
vestiges of that model. Philosophically, and technically, it just wouldn't
be a tragedy to do something else. I think the -03 text expresses our
desire to continue with RFC2860 while not exaggerating the necessity for
that arrangement to prevail. That's the line I hope we can walk.

Jon Peterson
Neustar, Inc.

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 18 Nov 2014 23:16:40 -0500

> prices with a monopolist. *That* would be irresponsible.

I've periodically wondered about this.  IEEE does an awfully good job at 
managing the various registries for the standards they maintain.

(Names and addresses are, of course, different beasts - by the nature of 
the volume of data and transactions involved.)

Miles Fidelman

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 19 Nov 2014 14:58:57 +0900

> explosive bolts and look elsewhere, but in any case this text is

I agree that independent of whether we use the old or the new text, I'd 
not want to see point 3). To me, it reads much like a hint to ICANN that 
we currently get this service for free, but we might be ready to pay for 
it. I'd rather not we give ICANN or anybody else that impression. If 3) 
were reworded to say that the service is currently free and we expect it 
to continue to be so, I might be okay with keeping 3), but as Brian 
says, this is already implied by other language.

Regards,   Martin.

---

From: "Richard Hill" <[email-masked]>
Date: Wed, 19 Nov 2014 09:20:42 +0100

I agree with what Miles says below.

To answer Miles's question, yes, the current IANA Functions contract between 
the NTIA and ICANN does specify that the functions wil be performed at no 
cost.  That is also specified in the MoU between ICANN and the IETF.

However, as noted before, it is not obvious whether the MoU between ICANN 
and the IETF is a legally binding contract.

That's one of the points where I think proper legal advice is required. 
I'll elaborate on that separately.

Best,
Richard
----- Original Message ----- 
From: "Miles Fidelman" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, November 19, 2014 3:38 AM
Subject: Re: [Ianaplan] Trial balloon: suggested text

>> This looks pretty good to me. The sentence starting with "However in the 
>> absence of the NTIA contract..." is essential to what wins me over: at 
>> least we are recognizing reality, linking it to the NTIA change and 
>> proposing a plan. Would there need to be any specification of who would 
>> put these arrangements in place?
>>
>>> day-to-
> I REALLY think this merits more thought about the intent of the statement, 
> and run by the lawyers, for two reasons:
>
> 1. public domain does not exist in all jurisdictions, and its meaning also 
> changes from jurisdiction to jurisdiction
>
>>> transition
>>> (currently at
> charging.  Better to amend the MoU to incorporate a clear requirement that 
> the services remain free.  (I've lost track, is this one of those things 
> the NTIA contract says has to remain free? If yes, why not propose 
> amending the MoU to include what the NTIA contract says?)
>
> Miles Fidelman
>
>
> --

---

From: "Richard Hill" <[email-masked]>
Date: Wed, 19 Nov 2014 09:26:56 +0100

----- Original Message ----- 
From: "Milton L Mueller" <[email-masked]>
To: "Leslie Daigle (TCE)" <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 19, 2014 2:49 AM
Subject: Re: [Ianaplan] Trial balloon: suggested text

>I think people are over-focusing on the cost issue to avoid dealing with 
>the real difference in the "trial balloon" - the differences that really 
>matter. Let me try to highlight the differences more clearly.
>

SNIP

> OK, what's the difference here? The OLD says IETF has a "preference" that 
> all parties >acknowledge that the registries are in the public domain. 
> What if all relevant parties do _not_ >make this acknowledgement? Nothing 
> is specified. Nothing happens. This is not a transition >plan. This is a 
> description of your current mental state. I cannot understand how anyone 
> can >think stating a preference that could be ignored by any relevant 
> party is a transition plan, or >provides adequate protection to IETF's 
> interests.

I agree with Milton.  If the language that is in "03" were tranformed into 
the language of a plan, it would say something like: "If the IETF is 
dissatisfied, for whatever reason, with ICANN's performance of the IANA 
function, then the IETF will make other arrangements for the performance of 
the IANA function.  It would be easier to make those other arrangements if 
ICANN were to agree to allow the new IANA functions operator to continue to 
use the IANA trademark and the IANA.ORG domain name."

That is indeed a plan, but not a plan that I can support, for reasons that I 
will explain in a separate E-Mail.

SNIP

---

From: JFC Morfin <[email-masked]>
Date: Wed, 19 Nov 2014 09:46:45 +0100

At 05:16 19/11/2014, Miles Fidelman wrote:
>I've periodically wondered about this.  IEEE does an awfully good 
>job at managing the various registries for the standards they maintain.
>(Names and addresses are, of course, different beasts - by the 
>nature of the volume of data and transactions involved.)

Miles, Milton,

The IETF is to be consistant. What is discussed is a whole - let call 
it I*Doc - including names, numbers, documentation and parameters. 
Parameters are public domain. Documentation is not (subject to BCP 
78). I do not know about names and numbers. They are privately owned 
(except these which belong to parameters) but I suppose their 
knowledge/use is public domain?

Why would IETF pay to get someone to republish something in public 
domain? So the problem is only BCP 78. And in BCP 78 the provision 
regarding derivative works (such as IAB's demanded internetsec), what 
may also aspect special parameters uses.

What is needed is a stable format for public domain I*Doc 
publications that repositories can adapt to their RFC 6852 global 
market because "we embrace a modern paradigm for standards where the 
economics of global markets, fueled by technological advancements, 
drive global deployment of standards regardless of their formal status".

May I remind you that "in this paradigm standards support 
interoperability, foster global competition, are developed through an 
open participatory process, and are voluntarily adopted 
globally.  These voluntary standards serve as building blocks for 
products and services targeted at meeting the needs of the market and 
consumer, thereby driving innovation.  Innovation in turn contributes 
to the creation of new markets and the growth and expansion of 
existing markets."

This is why the few following things to do are:

1. make "http://iana.arpa" resolve.forever.
2. make ".arpa" reserved in every DNS class.
3. put RFCs and parameters in public domain with the impliction that 
the use of names and number is free.
4. support information on internetsec at http://internetsec.arpa
5. accustom users to use ".arpa" in makig http://ietf.arpa, 
http://iesg.arpa, http://irtf.arpa, and http://iab.arpa to also resolve.

Then to seat and wait.
jfc

---

From: "Richard Hill" <[email-masked]>
Date: Wed, 19 Nov 2014 09:46:55 +0100

Dear  Jon,

Thank you for this.  I think that your comments are very helpful because 
they help to clarify the differences in points of view.  Please see embedded 
comments below.

Thanks again and best,
Richard
----- Original Message ----- 
From: "Peterson, Jon" <[email-masked]>
To: "Milton L Mueller" <[email-masked]>; "Leslie Daigle (TCE)" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 19, 2014 4:47 AM
Subject: Re: [Ianaplan] Trial balloon: suggested text

SNIP

> "hostile" cases here,

Not necessarily hostile.  ICANN is subsidizing the IANA function: it costs 
money to run it, but the IETF does not pay for it.  ICANN is, at present, 
constrained to provide the function at no cost by its contract with NTIA:

Absent that contract, ICANN could decide that it does not wish to provide 
that function for free, or even that it does not wish to provide that 
function at all.

Or ICANN could cease to exist (unthinkable now, but how many of us thought 
that Wang or Digital Equipment would cease to exist?).

>let me try to put this in the starkest, most
> protocol parameter registry.

That is correct.  Way back when, and I believe on a different list, Miles 
made the point that the protocol parameters function is not rocket science 
and similar things are done by and for many other standards making bodies, 
such as ISO.

That's correct, and, as far as I  know, most of those other standards making 
bodies don't have any particular agreements with whoever does the clerical 
equivalent of the IANA function.  It is either done by the organization's 
own secretariat, or by some other organization that does it in exchange for 
fees, or, in some cases, at no cost.

The situation is different here because the US government asserted its 
authority to make contractual arrangements regarding the performance of the 
clerical function.  As a consequence, the intellectual property, including 
the mark IANA and the domain name IANA.ORG were transferred to ICANN.

In analogous cases for other standards making organizations, the 
intellectual property is owned by the standards making body, so an 
outsourced clerical operator is obliged to comply with the instructions of 
the standards making body.

That is not the case here: absent a new contract, there are no legal 
constraints on ICANN.

Back when ICANN was created, the IETF didn't have sufficient funding to 
envisage performing the function in its own secretariat.

Today, the IETF does have sufficient funding to envisage performing the 
function in its own secretariat.

I can well understand that the IETF is happy to have someone else perform 
the function at no cost, but, in my experience, there ain't no such thing as 
a free lunch, so I'm wary.

>They would lose everything, we would lose
> nothing.

The IETF might lost the ability to refer to the function as IANA, and it 
might not be able to continue to use the IANA.ORG domain name.  And it might 
not get the service at no cost.

SNIP

> on us as soon as the NTIA steps aside,

I agree.  I will propose something different for 3 in the trial balloon.

SNIP

---

From: "Richard Hill" <[email-masked]>
Date: Wed, 19 Nov 2014 09:56:47 +0100

Dear Leslie,

Thank you for this.  It is indeed a very helpful proposal to help resolve 
some differences in opinions.  However, I have some suggestions, and I do 
agree with others that 3 below is not appropriate.

Please see embedded comments below.

Thanks and best,
Richard
----- Original Message ----- 
From: "Leslie Daigle (TCE)" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 18, 2014 6:43 PM
Subject: [Ianaplan] Trial balloon: suggested text

SNIP

SNIP

> between ICANN and the NTIA [NTIA-Contract].

I think that we need to add at the end: " and it must allow the new IANA 
functions operator to use the IANA trademark and the IANA.ORG domain name."

> negotiated, and ample time is given for the transition to the new cost

I agree that this is not appropriate.  The current IANA Functions contract 
between NTIA and ICANN imposes zero cost.  The same is specified inthe 
current MoU between the IETF and ICANN, but it isn't clear whether that MoU 
is a legally binding contract.

So, in order to maintain the current situation, I propose the following for 
3:

"3) ICANN will agree, in a legally binding document, to continue to provide 
the IANA function for protocol parameters at no cost."

---

From: Andrei Robachevsky <[email-masked]>
Date: Wed, 19 Nov 2014 10:07:51 +0100

Richard,

> functions operator to use the IANA trademark and the IANA.ORG domain name."

There might be a scenario where multiple IANA functions operators would
exist. A smooth transition and minimum disruption are the outcomes we
are looking for, and without knowing other communities' positions I
think that 2) in its current state provides the necessary flexibility.

Andrei

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Nov 2014 05:08:29 -0500

--On Wednesday, November 19, 2014 09:56 +0100 Richard Hill
<[email-masked]> wrote:

>> 2) In case of future need to transition the operation of the
>> protocol parameters registries from ICANN to subsequent
>> operator(s), this transition will be smooth and have minimum
>> disruption in the use the protocol parameters registries or
>> other resources currently located at iana.org. This
>> arrangement should be comparable to current obligations
>> established under C.7.3 and I.61 of the current IANA
>> functions contract between ICANN and the NTIA [NTIA-Contract].
> 
> I think that we need to add at the end: " and it must allow
> the new IANA functions operator to use the IANA trademark and
> the IANA.ORG domain name."

Richard,

I'm glad you said "allow" because anything stronger would make
my somewhat-negative reaction below much more intense.
However...

That result, independent of text, would be my preference too if
the circumstances were right.  However, I think there are just
too many possible scenarios, include splitting up the IANA
function(s), that would make the text you propose more a source
of difficulties and disruptive attempts at hair-splitting (or,
in a different metaphor, baby-dividing) than a help.   

"will be smooth and have minimum disruption in the use [of] the
protocol parameters" seems to me to require availability and use
of the IANA trademark and IANA.ORG for all of the simple cases
because not having them available and using them so would be
much more disruptive.  If that is correct, the added text is
potentially useful for some edge cases and, at least IMO, it is
at least as likely to be problematic for other possible cases as
to be a benefit.

Stated differently, if any major transition in the IANA
functions operator or how those functions are organized is
needed, those who have to deal with it will have to sort out an
array of tradeoffs in which they try to minimize both short-term
disruptions (including service disruptions) while maximizing
long-term stability including references from specifications and
other documents that will not change.   Those two objectives
conflict, so there are no obvious answers.  I actually predict
some decisions would likely have to be made on a per-registry
basis rather than "for the IANA Function(s)".   Because we
cannot predict all of the scenarios, putting in text that could
later constrain or complicate choices seems unwise unless there
is a compelling reason to do so... and I haven't heard or seen
that reason, especially in the light of comments that several of
us have made about how small a portion of the transition
problems things like the IANA name or the domain actually are
likely to be.

best,
    john

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Nov 2014 12:57:59 +0000

> says, this is already implied by other language.

Same here. I think -03 is better overall. Some of the language in the
1st two bullets of the suggested text is better than -03 though but
I won't attempt to start the collective wordsmithing. I'd hope the
editors and chairs can figure out what editorial changes are ok from
the list and/or by checking with folks who've posted (that is, if a
-04 is to be done before IETF LC).

S.

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 19 Nov 2014 08:26:58 -0500

inline, below

Richard Hill wrote:
> Dear  Jon,
>
> Thank you for this.  I think that your comments are very helpful 
> because they help to clarify the differences in points of view. Please 
> see embedded comments below.
>
> Thanks again and best,
> Richard
> ----- Original Message ----- From: "Peterson, Jon" 
> <[email-masked]>
> Not necessarily hostile.  ICANN is subsidizing the IANA function: it 
> costs money to run it, but the IETF does not pay for it.  ICANN is, at 
> present, constrained to provide the function at no cost by its 
> contract with NTIA:
>
> Absent that contract, ICANN could decide that it does not wish to 
> provide that function for free, or even that it does not wish to 
> provide that function at all.
>
> Or ICANN could cease to exist (unthinkable now, but how many of us 
> thought that Wang or Digital Equipment would cease to exist?).
>
> That is correct.  Way back when, and I believe on a different list, 
> Miles made the point that the protocol parameters function is not 
> rocket science and similar things are done by and for many other 
> standards making bodies, such as ISO.

Actually, IEEE.

I think ISO delegates (example given: blocks of credit card numbers - 
that one actually shifted registries - and perhaps our attorney could 
look at the language in place that allowed that to happen)

And, let's remember, at one point, one human being did it all :-)

SNIP

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 19 Nov 2014 08:31:17 -0500

> think that 2) in its current state provides the necessary flexibility.
There's a simple model for that:
- the IETF Trust is not actually a separate legal entity, it's an 
agreement between ISOC and CNRI - it would be pretty easy to set up a 
similar agreement among the multiple organizations that contract with 
the IANA operator - to hold the registration and manage the top level 
domain records, and maybe the top-level web site's redirect file
- then delegate sub-domains as appropriate, to the contractor(s) of the day

That one really isn't rocket science.

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 19 Nov 2014 08:33:37 -0500

> my somewhat-negative reaction below much more intense.

Could someone please explain why folks are against clear language in a 
plan?  SHALLs and MUSTs are perfectly appropriate in contractual 
language.  MAYs are just an invitation for litigation.

Miles Fidelman

---

From: David Conrad <[email-masked]>
Date: Wed, 19 Nov 2014 09:04:12 -0800

Richard,

On Nov 19, 2014, at 12:20 AM, Richard Hill <[email-masked]> wrote:
> To answer Miles's question, yes, the current IANA Functions contract between the NTIA and ICANN does specify that the functions wil be performed at no cost.  

You left out a bit. The current IANA Functions contract states:

"B.2 COST/PRICE

The Contractor may not charge the United States Government to perform the requirements of this Contract. The Contractor may establish and collect fees from third parties provided the fee levels are approved by the Contracting Officer and are fair and reasonable. If fees are charged, the Contractor shall base any proposed fee structure on the cost of providing the specific service for which the fee is charged and the resources necessary to monitor the fee driven requirements. The Contractor may propose an interim fee for the first year of the contract, which will expire one year after the contract award. If the Contractor intends to establish and collect fees from third parties beyond the first year of the Contract, the Contractor must collaborate with the interested and affected parties as enumerated in Section C.1.3 to develop a proposed fee structure based on a methodology that tracks the actual costs incurred for each discrete IANA function. The Contractor must submit a copy of proposed fee structure, tracking methodology and description of the collaboration efforts and process to the Contracting Officer."

TL;DR: ICANN cannot charge _the USG_ for the performance of the IANA Functions, however ICANN can collect fees from third parties as long as the fee structure is fair, reasonable, based on the cost of providing the services, and developed in collaboration with the affected parties.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 19 Nov 2014 09:19:07 -0800

Richard,

On Nov 19, 2014, at 12:46 AM, Richard Hill <[email-masked]> wrote:
> ICANN is, at present, constrained to provide the function at no cost by its contract with NTIA:

This is inaccurate.

ICANN is only constrained not to charge the USG for the IANA services. As section B.2 clearly states, ICANN can charge third parties. 

> The situation is different here because the US government asserted its authority to make contractual arrangements regarding the performance of the clerical function.  As a consequence, the intellectual property, including the mark IANA and the domain name IANA.ORG were transferred to ICANN.

You are asserting causation that is not apparent. I do not believe ICANN received the domain name and trademark as a consequence of the US government asserting its authority, rather it was a natural consequence of the intent of the creation of ICANN that it should receive the domain name (I suspect the trademark was an afterthought). If you have evidence documenting otherwise, please provide it.

> That is not the case here: absent a new contract, there are no legal constraints on ICANN.

As documented, there are no legal constraints now that forbid ICANN from charging third parties.

Regards,
-drc

---

From: Richard Hill <[email-masked]>
Date: Wed, 19 Nov 2014 18:22:18 +0100

Dear David

I accept your corrections.

Best Richard

On November 19, 2014 6:19:07 PM CET, David Conrad <[email-masked]> wrote:
>ICANN is only constrained not to charge the USG for the IANA services.
>As section B.2 clearly states, ICANN can charge third parties. 
>
>> The situation is different here because the US government asserted
>its authority to make contractual arrangements regarding the
>performance of the clerical function.  As a consequence, the
>intellectual property, including the mark IANA and the domain name
>IANA.ORG were transferred to ICANN.
>
>You are asserting causation that is not apparent. I do not believe
>ICANN received the domain name and trademark as a consequence of the US
>government asserting its authority, rather it was a natural consequence
>of the intent of the creation of ICANN that it should receive the
>domain name (I suspect the trademark was an afterthought). If you have
>evidence documenting otherwise, please provide it.
>
>------------------------------------------------------------------------
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Wed, 19 Nov 2014 13:24:00 -0500

Okay, reading the list traffic, I'd say that virtually no one likes "3)" 
in the proposed new text. "2)" and "3)" don't shift consensus from where 
we were with -03.

But.

The one thing I wonder if we might want to retain from yesterday's 
proposed text is something from "However in the absence of the NTIA 
contract a few new arrangements have to be put in place that will ensure 
that: ".   Consistently with what this document is meant to do, I think 
it signals that the IETF does recognize that there is change with the 
departure of the NTIA from the scene.

There was support for that language in the list discussion; there was 
also some pushback on it in the specific context of the complete redraft 
of the section.

So, my last suggestion, working to find wording to capture that 
sentiment in a document expressing what the consensus of the IETF 
community is (not the instrument for effecting change), follows.

The one question is:  does this make a better statement than the 
original -03 text, or not, or indifferent?

[Proposed adjustment to the text as found in 
draft-ietf-ianaplan-icg-response-03:]
 > very well.  RFC 6220 has laid out an appropriate service description
Insert:

However in the absence of the NTIA contract a few new arrangements may 
be needed in order to ensure the IETF community's expectations are met. 

Leslie.

--

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Nov 2014 07:54:43 +1300

Works for me.

Regards
   Brian

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 19 Nov 2014 20:18:12 +0000

Actually the IANA contract allows the contractor to charge. My understanding is that the current IETF-ICANN agreement prevents this, nothing more. So the end of the NTIA contract is actually a step forward in that regard. However, ICANN could decide to stop being the IANA on its own initiative, and then propose to charge if IETF wanted to continue using it. Anyway, I don't find valid the argument that part 3 "is an invitation to charge" but I do find convincing the argument that any attempt to impose charges, reasonable or otherwise, could be handled via RFC 2826. So I don't care whether 3 stays or not.

> To answer Miles's question, yes, the current IANA Functions contract
> between the NTIA and ICANN does specify that the functions wil be
> performed at no cost.  That is also specified in the MoU between ICANN and
> the IETF.
>

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 19 Nov 2014 20:22:09 +0000

To answer your question directly (and rather hurriedly)

> The one question is:  does this make a better statement than the original -03
> text, or not, or indifferent?

Still too weak and vague, but massively better than -03.

--MM

> From: Ianaplan [mailto:[email-masked]] On Behalf Of Leslie
> Daigle (TCE)
> Sent: Wednesday, November 19, 2014 1:24 PM
> To: [email-masked]
> Subject: [Ianaplan] Where (I think) we're at and a final suggestion Re: Trial
> balloon: suggested text
> 
> 
> in the proposed new text. "2)" and "3)" don't shift consensus from where we
> were with -03.
> 
> But.
> 
> The one thing I wonder if we might want to retain from yesterday's proposed
> text is something from "However in the absence of the NTIA contract a few
> new arrangements have to be put in place that will ensure
> it signals that the IETF does recognize that there is change with the departure
> of the NTIA from the scene.
> 
> There was support for that language in the list discussion; there was also
> some pushback on it in the specific context of the complete redraft of the
> section.
> 
> So, my last suggestion, working to find wording to capture that sentiment in a
> document expressing what the consensus of the IETF community is (not the
> instrument for effecting change), follows.
> 
> 
> 
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 Nov 2014 16:49:03 -0500

> OK, what's the difference here? The OLD says IETF has a "preference" that all parties acknowledge that the registries are in the public domain. What if all relevant parties do _not_ make this ackno…

I think you are saying that we ask all of the parties to sign the acknowledgement, but if any of the parties is unwilling we need to have something else to say.

I have had discussions with all but one of the parties, and they are willing to sign in principle.  Of course, they will want their legal staff to review the text.  So, we could say that we expect the US Government to sign the acknowledgement as part of the transition.  The others could sign in advance to show good faith,

Russ

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Nov 2014 13:51:33 -0800

Leslie said:

"The one thing I wonder if we might want to retain from yesterday's
proposed text is something from "However in the absence of the NTIA
contract a few new arrangements have to be put in place that will ensure
that: ".

[BA]  I would be in favor of something along those lines.  It is important
that the text created by the IANAPLAN WG be treated as a minimum set of
requirements that the IAOC needs to address, not as a detailed solution or
a prohibition against addressing additional contractual issues that the
IAOC, on advice of counsel, might decide are important.

On Wed, Nov 19, 2014 at 10:24 AM, Leslie Daigle (TCE) <
[email-masked]> wrote:

> that: ".   Consistently with what this document is meant to do, I think it
> signals that the IETF does recognize that there is change with the
> So, my last suggestion, working to find wording to capture that sentiment
> in a document expressing what the consensus of the IETF community is (not
> the instrument for effecting change), follows.
>
> The one question is:  does this make a better statement than the original
> -03 text, or not, or indifferent?
>
>
>
> [Proposed adjustment to the text as found in draft-ietf-ianaplan-icg-
> response-03:]
> However in the absence of the NTIA contract a few new arrangements may be
> needed in order to ensure the IETF community's expectations are met.  Those
> expectations are:
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 19 Nov 2014 17:09:09 -0500

> Sure, but the existence of other alternatives does not in the least bit detract from the benefit that might be obtained by requiring ICANN to maintain fair and reasonable rates and to provide an ad…

If the IETF were to ever exercise the six month option in the MOU, the IETF (through the IAOC) would have to bear the costs for an protocol parameter registry, including the cost of any transition.  ICANN charging a fee for their IANA services would be one reason that the IETF might exercise the six month option.  If ICANN was consistently falling short on the SLA commitments would be another.

For many years, ICANN has provided a great service to the IETF at no cost.  I would expect this to continue.  So, we are talking about protections that are fairly far off in the future, possibly never.

To that end, I think that requesting language in the SLA for a smooth transition if the six month option is ever exercised by either party is the most important safety net we can expect.

Russ

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Nov 2014 03:42:39 +0200

I’d be OK with those changes.

Jari

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 19 Nov 2014 20:52:48 -0500

I'd be ok with the new text, along the reasoning that Bernard provided. 

A

-- 
Andrew Sullivan 
Please excuse my clumbsy thums. 

> On Nov 19, 2014, at 13:24, "Leslie Daigle (TCE)" <[email-masked]> wrote:
> 
> 
> Okay, reading the list traffic, I'd say that virtually no one likes "3)" in the proposed new text. "2)" and "3)" don't shift consensus from where we were with -03.
> 
> But.
> 
> The one thing I wonder if we might want to retain from yesterday's proposed text is something from "However in the absence of the NTIA contract a few new arrangements have to be put in place that will ensure that: ".   Consistently with what this document is meant to do, I think it signals that the IETF does recognize that there is change with the departure of the NTIA from the scene.
> 
> There was support for that language in the list discussion; there was also some pushback on it in the specific context of the complete redraft of the section.
> 
> So, my last suggestion, working to find wording to capture that sentiment in a document expressing what the consensus of the IETF community is (not the instrument for effecting change), follows.
> 
> The one question is:  does this make a better statement than the original -03 text, or not, or indifferent?
> 
> 
> 
> [Proposed adjustment to the text as found in draft-ietf-ianaplan-icg-response-03:]
> However in the absence of the NTIA contract a few new arrangements may be needed in order to ensure the IETF community's expectations are met.  Those expectations are:
>

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 20 Nov 2014 00:42:47 -0500

Hi Richard,

> not get the service at no cost.

I agree, and I think all of us agree, that that is a risk.  The
question is whether it matters.

Some of us think that it would be a bad thing, most unfortunate, and
not something that we would relish; but something that could
nevertheless be handled if it were to come to pass.  Some of us have
even suggested that, if this is what is worried about, we could blunt
all of that immediately with some less aggressive actions, such as
using a different namespace (e.g. parameters.iana.org or even
parameters.ietf.org) and using tricks like DNAME or http redirects to
make everything "just work" as it does now.  

The "not that big a deal" answer and the "use a technical trick to
skirt this" answer seem not to be satisfying to others in this
conversation.  What I don't understand is why they're not satisfying.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 20 Nov 2014 09:37:03 +0100

Dear Andrew,

Thanks for this, and please see below.

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Andrew
> Sullivan
> Sent: jeudi, 20. novembre 2014 06:43
> To: [email-masked]

Because we are looking at it from different points of view. I'm looking at
it from a legal and contractual point of view.  The evaluation of risks and
costs/benefits can be different when viewed from different perspectives.

I'll elaborate on that with a detailed example in my reply to Leslie.

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 20 Nov 2014 10:47:29 +0100

Dear Leslie,

Thank you for this.  I agree that this is an improvement over "03" but,
regretfully, I cannot support this text, for both procedural and subtantive
reasons.  In essence, I don't think that it is a plan, and I don't think
that it identifies the additional documentation or agreements required to
address the removal of the overarching NTIA contract (I'm paraphrasing here
from this group's charter).  Note that the charter explicitly empowers this
group to request the IAOC to provide such agreements.

The charter of this group assumes that current arrangements will continue,
and in particular that the existing MoU between ICANN and IETF will continue
to remain in force.

In my view, that will not be the case unless additional agreements are made.
I will give one specific example, but analogous reasoning applies to other
issues that have been raised.

David Conrad has correctly pointed out that the current IANA Functions
contract between NTIA and ICANN does not prevent ICANN from charging fees
for performance of the IANA function, under certain conditions.  ICANN can
charge fees as long as the fee structure is approved by NTIA, is fair,
reasonable, based on the cost of providing the services, and developed in
collaboration with the affected parties.

The current MoU between the IETF and ICANN specifies that the IANA function
services for the protocol parameters will be provided free of charge.

It is not clear to me that that MoU is a legally binding contract.  If it is
not, then, absent the NTIA contract, there are no contractual or legal
restrictions preventing ICANN from charging whatever fees it considers
appropriate for the IANA function.  That is, the "fair, reasonable,
cost-based, and collaboration" elements of the current arrangement would no
longer be legal requirements.

Some people are not concerned about legal requirements, so they are not
worried about this.

But, from my point of view, the new legal/contractual structure should be
similar to the current legal/contractual structure, and that will not be the
case if the IAOC is not requested to provide additional agreements, meaning
legally binding contracts.

That is, both "03" and the language that you are proposing would result in a
transition in which the legal/contractual structure is significantly
different from the current structure.

Again, some think this is not an issue, but I beg to differ.  I think that
it is an issue.

So I cannot support either "03" or the new language.

But I thank you again for having made the proposal,
Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Leslie
> Daigle (TCE)
> Sent: mercredi, 19. novembre 2014 19:24
> To: [email-masked]
> Subject: [Ianaplan] Where (I think) we're at and a final suggestion Re:
> Trial balloon: suggested text
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Nov 2014 12:50:57 +0000

> I'd be ok with the new text, along the reasoning that Bernard provided. 

Same here.

S.

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 20 Nov 2014 13:51:12 +0000

Now you're talking! Why shouldn't the RFP response just doesn't say that (sign the ack) ? 

> I think you are saying that we ask all of the parties to sign the
> acknowledgement, but if any of the parties is unwilling we need to have
> something else to say.
> 
> I have had discussions with all but one of the parties, and they are willing to
> sign in principle.  Of course, they will want their legal staff to review the text.
> So, we could say that we expect the US Government to sign the
> acknowledgement as part of the transition.  The others could sign in advance
> to show good faith,
>

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 20 Nov 2014 14:03:33 +0000

I agree with Richard's points, but believe that if we can get consensus on Leslie's latest modifications then that would be an acceptable basis on which to move forward, especially if Bernard Adoba's caveat is considered part of it. I reproduce it here: 

[BA]  It is important that the text created by the IANAPLAN WG be treated as a minimum set of requirements that the IAOC needs to address, not as a detailed solution or a prohibition against addressing additional contractual issues that the IAOC, on advice of counsel, might decide are important.

In other words, the current proposal, if understood as noted above, does not preclude the strengthened legal and contractual measures that Richard is calling for, it seems to leave the door open to them. If I am wrong about that someone please correct me.

--MM

> From: Ianaplan [mailto:[email-masked]] On Behalf Of Richard Hill
> Sent: Thursday, November 20, 2014 4:47 AM
> To: Leslie Daigle (TCE); [email-masked]
> Subject: Re: [Ianaplan] Where (I think) we're at and a final suggestion Re:
> reasons.  In essence, I don't think that it is a plan, and I don't think that it
> identifies the additional documentation or agreements required to address
> the removal of the overarching NTIA contract (I'm paraphrasing here from
> this group's charter).  Note that the charter explicitly empowers this group to
> request the IAOC to provide such agreements.
> 
> contract between NTIA and ICANN does not prevent ICANN from charging
> fees for performance of the IANA function, under certain conditions.  ICANN
> can charge fees as long as the fee structure is approved by NTIA, is fair,
> The current MoU between the IETF and ICANN specifies that the IANA
> function services for the protocol parameters will be provided free of charge.
> 
> It is not clear to me that that MoU is a legally binding contract.  If it is not,
> then, absent the NTIA contract, there are no contractual or legal restrictions
> preventing ICANN from charging whatever fees it considers appropriate for
> the IANA function.  That is, the "fair, reasonable, cost-based, and
> collaboration" elements of the current arrangement would no longer be legal
> requirements.
> 
> transition in which the legal/contractual structure is significantly different
> from the current structure.
> 
> Again, some think this is not an issue, but I beg to differ.  I think that it is an
> issue.
> 
> But I thank you again for having made the proposal, Best, Richard
> 
> 
> 
> > in the proposed new text. "2)" and "3)" don't shift consensus from
> > where we were with -03.
> >
> > But.
> >
> > also some pushback on it in the specific context of the complete
> > redraft of the section.
> >
> > > day-to-day, as they have been doing for the last decade or more.
> > The  > IETF community is quite satisfied with the current arrangement
> > with  > ICANN.  RFC 2860 remains in force and has served the IETF
> > community  > very well.  RFC 6220 has laid out an appropriate service
> > description  > and requirements.
> >  >
> > Insert:
> >
> > > the preference of the IETF community that all relevant parties  >
> >  > It is possible in the future that the operation of the protocol  >
> > parameters registries may be transitioned from ICANN to subsequent  >
> > operator(s).  It is the preference of the IETF community that, as  >
> > > functions contract between ICANN and the NTIA [NTIA-Contract] to  >
> > achieve a smooth transition to subsequent operator(s), should the  >
> > need arise. Furthermore, in the event of a transition it is the  >
> > expectation of the IETF community that ICANN, the IETF, and  >
> > subsequent operator(s) will work together to minimize disruption in  >
> > the use the protocol parameters registries or other resources  >
> > > Out of band, there's been a suggestion of text for a possible
> > > "middle ground" between -02 and -03.
> > >
> > > the
> > > (rough!) consensus to move forward, I'd like to hear whether
> > > proponents of -02 text think this suggestion is better than -03
> > > (and, from -03 proponents, whether this is unacceptable).
> > >
> > >
> > >> day-to-day, as they have been doing for the last decade or more.
> > >> The IETF community is quite satisfied with the current arrangement
> > >> with ICANN.  RFC 2860 remains in force and has served the IETF
> > >> community very well.  RFC 6220 has laid out an appropriate service
> > >> description and requirements.
> > >>
> > >> part of the NTIA transition, ICANN acknowledge that it will carry
> > >> out the obligations established under C.7.3 and I.61 of the current
> > >> IANA functions contract between ICANN and the NTIA [NTIA-Contract]
> > >> to achieve a smooth transition to subsequent operator(s), should
> > >> the need arise. Furthermore, in the event of a transition it is the
> > > day-to-day, as they have been doing for the last decade or more.
> > > The IETF community is quite satisfied with the current arrangement
> > > with ICANN.  RFC 2860 remains in force and has served the IETF
> > > community very well.  RFC 6220 has laid out an appropriate service
> > > description and requirements.
> > >
> > > However in the absence of the NTIA contract a few new arrangements
> > > have to be put in place that will ensure that:
> > >
> > > protocol parameters registries from ICANN to subsequent operator(s),
> > > this transition will be smooth and have minimum disruption in the
> > > use the protocol parameters registries or other resources currently
> > > located at iana.org. This arrangement should be comparable to
> > > current obligations established under C.7.3 and I.61 of the current
> > > IANA functions contract between ICANN and the NTIA [NTIA-Contract].
> > >
> > > negotiated, and ample time is given for the transition to the new
> > > cost and fee structure.
> > >
> > >
> > >
> > > Leslie.
> > >
> > >
> >
> > --
> >

---

From: Jefsey <[email-masked]>
Date: Thu, 20 Nov 2014 18:46:42 +0100

At 15:03 20/11/2014, Milton L Mueller wrote:
>In other words, the current proposal, if understood as noted above, 
>does not preclude the strengthened legal and contractual measures 
>that Richard is calling for, it seems to leave the door open to 
>them. If I am wrong about that someone please correct me.

All this is based neither on the charter nor on reality. It is about 
contracts/understandings considered as protocols, by protocol 
engineers, i.e. on the basis of cooperative ends. Modern policy is 
based upon the opposite approach which is the precautionary principle.

Reality is:

- http://csis.org/files/publication/141117_Lewis.pdf
- 
http://sendsonline.org/wp-content/uploads/2011/06/Deterring-VNSA-in-Cyberspace-FINAL.pdf
- http://www.rand.org/content/dam/rand/pubs/monographs/2009/RAND_MG877.pdf
   "Cyber attacks are possible only because systems have flaws".

As long as architecture is left to engineers who ignore what 
architectonics may mean, and do not make difference between cyber, 
digital and numeric, the world is in danger. Russ Housley has engaged 
two steps in the NTIA planned proper direction in calling for a 
secure internet and assuming control of ".arpa" were the two 
prerequistes. I hope this WG's Draft is not going to weaken them.

The next step is to make the IANA names, numbers, documentation, and 
protocol accessible under "http://iana.arpa".
Would the IAOC be unable to organize and finance it, we will ask the 
Libre's community to carry the job and, this way, insure the ICANN 
accountability to the multitude of the internet users.

jfc

---

From: JFC Morfin <[email-masked]>
Date: Thu, 20 Nov 2014 20:05:04 +0100

Dear John and Richard,

The Last Call period is over. Now, we are waiting for the Chairs to 
decide on the Rough Consensus that they observed. Therefore, the IESG 
can start an IETF Last Call and can make a decision that I will most 
probably appeal.

Being barred from sharing in the IETF Last Call, I am now at ease to 
organize a Libre involvement in what is to follow. Moreover, 
circumstances have unexpectedly led to an early friendly fork, while 
I feared an unfriendly and later one.

The questions are:
- who will be the final Internet referent to replace the NTIA oversight?
- what will be its accountability framework?

I hereby identify several candidates.

1. The US arrangement is the FCC.
2. The WEF arrangement seems to be ICANN.
3. The ISOC strategy has to adapt to Fadi's/Rosetta-NETmundial 
initiative and hesitates.
4. The de facto one is IAB.
5. The ITU-I is the most obvious one if the I*/WEF, etc. people do not agree.
6. A mess.
7. The emergence of a global Rastafarian "overstanding" based on the 
RFC 6852 paradigm, ITU/USG multistakeholderism, Libre's contribution, 
multitude's polycracy, etc.

The short-term solution is #4.
I analyzed the way the IAB can still easily address the situation now.
However, the IAB selection mode will not be enough unless the secure 
internet project takes off and gives technology leaders a respite. 
However, it is unlikely that the non-secure-internet IETF designer 
will be trusted very much by the world (nothing to with the people, 
but with the Tao).

IMHO, the long-term solution is #7.
The priority is, therefore, a precautionary approach of its emergence 
mechanism. To reach stability, this mechanism must be in tune with 
the political evolution and target the completion of the IEN 48 
internet project objective, i.e. "to allow new networking technology 
to be introduced into the existing catenet while remaining 
functionally compatible with existing systems".

There are currently two architectonical visions that I adhere to:
- my Intersem proposition of an inter-semiotic network for the whole 
digital ecosystem (WDE).
- Russ Housley's IAB requirement because the Intersem can only be 
confidential by default.
The question that needs to be answered now is which architecture is 
the best for both of them in considering the currently installed 
architecture (infrastructure, governance, contracts, and usages) and 
existing established trends.

There is a need for a major improvement for the IANA concept.
I extend the concept to what I call the MDRS (the "multiple 
definitions on record, metadata registry, multilingual distributed 
referent, etc. system): in order to include a single documentation of 
reference, to support multilinguality (i.e. the multilingualism 
cybernetics), to be multitechnology, and most of all to be locally 
distributed and processed at  everyone's machine.

Now, what to do?
If you want to negotiate, the best thing to do is to take the 
initiative and build your own independent solution. My target should, 
therefore, be:

A. on the technical side
-----------------------------

1. to maintain an <http://iana.zone/>http://iana.zone site 
replicating the iana.org site.
2. to progressively enhance that site with the help of the community.
3. to use the IUWG as a non-BCP78 restrained Libre (CC BY SA) working site.
4. to initiate an IU experimental Intelligent Use DNS class for IUI 
(Intelligent Use Interface) interoperations.
5. to foster Libre development/experimentation for my local 
non-profit Digital Services Providers project and Lab in the:
     - confidentiality area
     - MYCANN plug-in
     - intelligent networking
     - presentation layer.
6. to discuss and experiment a polycratic governance

B. on the political side
----------------------------

1. to appeal the final IETF position if it does not match our 
requirements that I stipulated.
2. to develop the FSP4NET (fail safe project for the net) as an 
operational Libre enhanced coalition (Govs, Industry, CS)

This already creates a few things that need to be done.

Best
jfc

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 20 Nov 2014 17:16:45 -0800

> The one question is:  does this make a better statement than the original -03 text, or not, or indifferent?

I’m fine with the suggested text below.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 20 Nov 2014 17:20:04 -0800

> In other words, the current proposal, if understood as noted above, does not preclude the strengthened legal and contractual measures that Richard is calling for, it seems to leave the door open to…

IETF process wonks can correct me, but nothing constrains the IAOC from acting on this or any other matter other beyond what is outlined in RFC 4071. The -03 text wouldn’t have constrained the IAOC, nor does Leslie’s suggested text.

Alissa

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Nov 2014 17:21:19 -0800

+1

---

From: "Lynn St.Amour" <[email-masked]>
Date: Thu, 20 Nov 2014 22:32:06 -0500

I support this as well.

Lynn

---

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 21 Nov 2014 09:55:55 +0100

I support this change.

Andrei

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 21 Nov 2014 08:39:02 -0500

> IETF process wonks can correct me, but nothing constrains the IAOC from acting on this or any other matter other beyond what is outlined in RFC 4071. The -03 text wouldn’t have constrained the IAOC…

Clarifying this point has turned out to be critical, so I'm happy with the language that makes people most comfortable with it.

Latest is fine.

Suzanne

---

From: Jari Arkko <[email-masked]>
Date: Fri, 21 Nov 2014 17:27:59 +0200

> IETF process wonks can correct me, but nothing constrains the IAOC from acting on this or any other matter other beyond what is outlined in RFC 4071. The -03 text wouldn’t have constrained the IAOC…

I wouldn’t mind stronger text either, but I do want to confirm that Alissa is right: the IAB, IAOC, along with our partners do already make updates and improvements. One example of this is the audit process, that got added to the 2014 SLA.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 21 Nov 2014 17:30:01 +0200

Do you believe that is enough to move forward? I’ve seen quite a lot of agreement.

Jari

---

From: Eric Burger <[email-masked]>
Date: Fri, 21 Nov 2014 11:33:12 -0500

I do.

> On Nov 21, 2014, at 10:30 AM, Jari Arkko <[email-masked]> wrote:
>

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 21 Nov 2014 17:54:55 +0100

Sorry, no, I don't think that it is enough to move forward.

ARIN has just published their first draft response to the ICG RFP, see:

  http://lists.arin.net/pipermail/iana-transition/2014-November/000097.html

That includes the following:

"The Internet number community proposes that a legally binding agreement for
IANA services for Internet number registries be established between the
present IANA operator (ICANN) and the RIRs to replace the Internet number
registry-related elements of the current ICANN-NTIA agreement."

Since, as far as I can tell, it would cause less disruption for the RIRs if
they had to move their portion of the IANA function elswhere than it would
cause for the IETF, I still maintain that "03", even with the addition
proposed by Leslie and supported by many, is not a proper response to the
ICG's RFP.

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Jari Arkko
> Sent: vendredi, 21. novembre 2014 16:30
> To: Leslie Daigle (TCE); Marc Blanchet
> Cc: Ianaplan@Ietf. Org
> Subject: Re: [Ianaplan] Where (I think) we're at and a final suggestion
> Re: Trial balloon: suggested text
>
>

---

From: Jefsey <[email-masked]>
Date: Fri, 21 Nov 2014 18:20:17 +0100

In case I do not have to appeal, if we want to meet the Jan 15, 2015 
date, since it is likely that this WG will not change its mind and 
will not fullfil its charter, I also do.

Richard, I fully agree with you and the RIRs. The non-secure-protocol 
stack internet stability calls for a trilateral ICANN, IETF, RIRs 
contract. However,

1) you saw that this WG, in part due to the particular culture 
claimed bu its members, is not discussing contracts (based on 
skeptiscim) but protocols (based on cooperation). The faster we are 
finished with this misunderstanding, the faster we will be able to 
address the real world situation.

2) you may have more chances to get support at the IETF Last-Call 
(moreover I will not be here !)

3) the context of the new-secure-protocol-stack internet will become 
better known in the coming year. The common best interest is to delay 
the NTIA transition through clear political moves, that press and 
politicians understand. An IESG/IAB/ISOC appeal is an example of what 
is always possible and will be well identified.

jfc

At 17:33 21/11/2014, Eric Burger wrote:
> > Do you believe that is enough to move forward? I've seen quite a 
> lot of agreement.
> >
> > Jari
> >

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Nov 2014 09:24:55 -0800

> Do you believe that is enough to move forward? I’ve seen quite a lot 

Comments have been along the lines of 'the current version but with the
suggested changes.'

Especially given the importance of this document, would it be possible
to have a fully-integrated version available for review, prior to
conducting a consensus evaluation?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ted Hardie <[email-masked]>
Date: Fri, 21 Nov 2014 09:38:33 -0800

> Do you believe that is enough to move forward? I’ve seen quite a lot of
​Not entirely clear whether you are addressing just ​the chairs or the
whole group,
but I think it is enough to move forward.

Ted

---

From: John Curran <[email-masked]>
Date: Fri, 21 Nov 2014 18:21:40 +0000

> proposed by Leslie and supported by many, is not a proper response to the

Richard - 
 
You failed to note that the mention of the agreement in the draft proposal 
is not the same as including an actual agreement in the proposal.  In fact, 
the IANA number community proposal from the ARIN-region representatives goes 
on to include the following text - "An outline for the proposed agreement 
is attached as Appendix A." (which is presently blank and to-be-determined )

Given that the IETF _already has an MOU_ with ICANN for IANA services, and
references such in their IANAplan draft response, that is the same level of 
specificity suggested by the initial draft ICG number response provided by
the ARIN-region reps.

In other words, thank you for raising this data point, but I do believe that
supports that assertion that the proposed IANAplan response is presently at 
the correct level of detail with the current text.

Thanks!
/John

John Curran
President and CEO
ARIN

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Nov 2014 08:19:14 +1300

> conducting a consensus evaluation?

1) I think we have something that can be called rough consensus (i.e. only
two or three people expressing doubts, but their arguments have been
carefully listened to and argued against by numerous others).

2) I agree with Dave to the extent that I'd like the chance to run rfcdiff
one more time on a -04. But we can all do that within 24 hours of it being
posted.

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Fri, 21 Nov 2014 20:24:04 +0100

On 11/21/14, 8:19 PM, Brian E Carpenter wrote:
> 2) I agree with Dave to the extent that I'd like the chance to run
> rfcdiff one more time on a -04. But we can all do that within 24 hours
> of it being posted.

Working on it.

Eliot

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Fri, 21 Nov 2014 16:56:36 -0500

Hi,

Marc and I, as chairs of this WG, believe the mailing list discussion of 
the document has reached (rough) consensus on the text.  Eliot and Russ 
are working to get the text, as discussed, into the document and we will 
see the -04 draft over the weekend or at the beginning of next week.

Leslie.

--

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 22 Nov 2014 09:04:33 +0100

Dear John,

Thank you for this, and please see below.

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of John
> Curran
> Sent: vendredi, 21. novembre 2014 19:22
> To: [email-masked]
> Cc: Marc Blanchet; Leslie Daigle (TCE); Jari Arkko; Ianaplan@Ietf. Org
> Importance: High
> Given that the IETF _already has an MOU_ with ICANN for IANA services,

As I've stated before, I'm not convinced that that MoU is contract, that is,
I'm not convinced that it is legally binding.

Thus, it is not the same as what ARIN is proposing, which is "a legally
binding agreement for IANA services".

That is, in the absence of the NTIA contract, there might not be any legally
binding agreement for the protocol parameters part of the IANA services
unless something other than the existing MoU is agreed.  I've pointed out
some of the possible consequences of that in previous posts.  I don't think
that anybody has disputed that there could be consequence, but they have
disputed that the consequences are of any significance.  That it, the
feeling seems to be that, whatever the consequences might be, it is better
to handle them if and when they arise, rather than to try to minimize them
now.

> and

No, I think that the same level of specificity would be something like:

"The IETF proposes that a legally binding agreement for IANA services for
protocol parameters be established between the present IANA operator (ICANN)
and an appropriate entity representing the IETF to replace the Internet
protocol parameters-related elements of the current ICANN-NTIA agreement."

> the correct level of detail with the current text.

For the reasons given above, I cannot agree.

---

From: John Curran <[email-masked]>
Date: Sat, 22 Nov 2014 09:20:58 -0500

> I'm not convinced that it is legally binding.

I acknowledge you have such a viewpoint.  Others likely have a somewhat 
different viewpoint, and in the end, it is up to the IETF leadership to 
determine, once have been informed by appropriate legal counsel.

> binding agreement for IANA services".

Actually, it may be the same (or may not), depending on one's views on 
the present MOU's legally binding nature.

> disputed that the consequences are of any significance.  ...

Yes, in the case where _there might not be any legally binding agreement 
for the protocol parameters_", there could be consequences.  Again, your 
argument hinges on that initial viewpoint.

> protocol parameters-related elements of the current ICANN-NTIA agreement."

Given your worldview, such language makes sense; otherwise, it is inflammatory, 
as it asserts that something must "be established" when it already exists (to
those readers of a different perspective.)

The essence of your position, however, is not particularly with respect to the 
present MOU but simply that the arrangement with the IANA operator be legally 
binding.  This is not an unreasonable position, although it may not strictly
be necessary for the IETF given its mission and range of mitigation options 
available to it.

If the community felt that "legally binding agreement" was important, but did 
not want to opine regarding the present MOU, one option would be to rephrase 
the draft language to indicate such... i.e. -  

"The IETF community is quite satisfied with the current arrangement with ICANN.  
 RFC 2860 remains in force and has served the IETF community very well. "

would need to become:

"The IETF community is quite satisfied with the current IANA operations
 arrangement with ICANN (as described in RFC 2860), and seeks to continue 
 this relationship via a legally-binding agreement."

Whether the present MOU serves adequately in this role would thus become 
an item for the IETF leadership to determine during the implementation of 
the proposal.

This specific point (i.e. does the IANA operator arrangement need to be a 
legally binding agreement) is probably worthy of working group discussion.
If there is no need for arrangement to be legally-binding, then the present 
language would appear to be fine.

/John

Disclaimer: my views alone.

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 22 Nov 2014 15:28:11 +0100

Dear John,

Thank you for these very constructive comments and suggestions.

I look forward to comments from others.

Best,
Richard

> Sent: samedi, 22. novembre 2014 15:21
> To: [email-masked]

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 22 Nov 2014 10:21:54 -0500

> On Nov 22, 2014, at 3:04 AM, Richard Hill <[email-masked]> wrote:
<SNIP>
>   this relationship via a legally-binding agreement."

Perhaps, extended with something like" "The agreement should address the 
possible future eventuality where IANA functions become split across 
multiple operators."
> language would appear to be fine.

Agreed.

---

From: Milton L Mueller <[email-masked]>
Date: Sat, 22 Nov 2014 15:35:28 +0000

> "The IETF community is quite satisfied with the current arrangement with
> ICANN. RFC 2860 remains in force and has served the IETF community very well. "
> 
> would need to become:
> 

That would be an improvement, imho. I have never quite understood why it couldn't be phrased that way. My understanding of the opposing point of view is that they feel that if the MoU did not prove to be binding, the IETF could "fork" the IANA and create their own, even without the domain or trademark. I am convinced that they could do that, but still do not understand why such a course would be preferable to a legally binding agreement.