Subject: [Ianaplan] Proposed text reflecting IETF91 discussion

From: Alissa Cooper <[email-masked]>
Date: Tue, 11 Nov 2014 16:22:04 -1000

Below is suggested text for the first part of the response to RFP Section III, based on the WG discussion yesterday. As discussed, this text focuses on the IETF community’s must-haves, states the desired outcomes and not the processes to arrive there, and removes the "the IAOC is asked to conclude a supplemental agreement that” text. The other reference to the IAOC remains, since it’s asking them to engage with other parties, which is something they do anyway.

=== OLD ===
IETF Response:

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

First and foremost, 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.

To address issues raised by the IETF community relating to intellectual property rights, the IAOC is asked to engage the appropriate parties, both inside and outside the IETF, to make clear that data in the protocol parameters registries is in the public domain.

To address a desire by the IETF community to have mechanisms that allow for additional dispute resolution between the IETF and the current IANA protocol registries operator, the IAOC is asked to conclude a supplemental agreement regarding jurisdiction and any necessary dispute resolution mechanisms that are mutually acceptable to the parties.

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

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

2.  requires the transfer of any associated marks and identifiers to subsequent operators.

=== NEW ===
IETF Response:

No major changes are required. Over the years since the creation of ICANN, the IETF, ICANN, and IAB have together created a system of agreements, policies, and oversight mechanisms that covers what is needed.

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.

To address issues raised by the IETF community relating to intellectual property rights, the IAOC is asked to engage the appropriate parties, both inside and outside the IETF, to make clear that data in the protocol parameters registries is in the public domain.

It is possible in the future that the operation of the protocol parameters registries will be transitioned from ICANN to subsequent operator(s). In the event of such a transition, it is the expectation of the IETF community that ICANN 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. Furthermore, in the event of a transition it is the expectation of the IETF community that ICANN and the IETF will work together to minimize confusion on the part of those who use the protocol parameters registries and other visitors to iana.org.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Nov 2014 15:51:43 +1300

It's a yes from me.

Regards
   Brian

On 12/11/2014 15:22, Alissa Cooper wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 11 Nov 2014 16:53:48 -1000

I agree with Coop.

-Ekr

On Tue, Nov 11, 2014 at 4:51 PM, Brian E Carpenter <
[email-masked]> wrote:

> > Below is suggested text for the first part of the response to RFP
> Section III, based on the WG discussion yesterday. As discussed, this text
> focuses on the IETF community’s must-haves, states the desired outcomes and
> not the processes to arrive there, and removes the "the IAOC is asked to
> conclude a supplemental agreement that” text. The other reference to the
> IAOC remains, since it’s asking them to engage with other parties, which is
> something they do anyway.
> >
> > === OLD ===
> > IETF Response:
> >
> > No major changes are required, however, the IETF community has expressed
> a desire for several points to be addressed by supplemental agreements to
> the IETF-ICANN MoU, prior to a transition to post-NTIA regime. Over the
> years since the creation of ICANN, the IETF, ICANN, and IAB have together
> created a system of agreements, policies, and oversight mechanisms that
> covers what is needed.
> >
> > First and foremost, 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.
> >
> > To address issues raised by the IETF community relating to intellectual
> property rights, the IAOC is asked to engage the appropriate parties, both
> inside and outside the IETF, to make clear that data in the protocol
> parameters registries is in the public domain.
> >
> > To address a desire by the IETF community to have mechanisms that allow
> for additional dispute resolution between the IETF and the current IANA
> protocol registries operator, the IAOC is asked to conclude a supplemental
> agreement regarding jurisdiction and any necessary dispute resolution
> mechanisms that are mutually acceptable to the parties.
> >
> > To address concerns regarding appropriate contingencies to transition to
> another operator, the IAOC is asked to conclude a supplemental agreement
> that-
> >
> > 1.  maintains the IANA functions operator's obligations established
> under C.7.3 and I.61 of the current IANA functions contract between ICANN
> and the NTIA [NTIA-Contract]; and
> >
> > No major changes are required. Over the years since the creation of
> ICANN, the IETF, ICANN, and IAB have together created a system of
> agreements, policies, and oversight mechanisms that covers what is needed.
> >
> > 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.
> >
> > To address issues raised by the IETF community relating to intellectual
> property rights, the IAOC is asked to engage the appropriate parties, both
> inside and outside the IETF, to make clear that data in the protocol
> parameters registries is in the public domain.
> >
> > It is possible in the future that the operation of the protocol
> parameters registries will be transitioned from ICANN to subsequent
> operator(s). In the event of such a transition, it is the expectation of
> the IETF community that ICANN 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. Furthermore,
> in the event of a transition it is the expectation of the IETF community
> that ICANN and the IETF will work together to minimize confusion on the
> part of those who use the protocol parameters registries and other visitors
> to iana.org.
> >
> >
> >

---

From: Ted Hardie <[email-masked]>
Date: Tue, 11 Nov 2014 17:07:14 -1000

I think this is fundamentally good. I have a minor (really minor) proposed
edit.

The current text has this:

"to minimize confusion on the part of those who use the protocol parameters
registries and other visitors to iana.org. "

I propose:

"to minimize disruption in the use the protocol parameters registries or
other resources at iana.org".

This wording seems to me to get at what we want a little more cleanly, but
I think you decide between them at your editorial discretion.

Ted

On Tue, Nov 11, 2014 at 4:22 PM, Alissa Cooper <[email-masked]> wrote:

> Below is suggested text for the first part of the response to RFP Section
> III, based on the WG discussion yesterday. As discussed, this text focuses
> on the IETF community’s must-haves, states the desired outcomes and not the
> processes to arrive there, and removes the "the IAOC is asked to conclude
> a supplemental agreement that” text. The other reference to the IAOC
> remains, since it’s asking them to engage with other parties, which is
> No major changes are required, however, the IETF community has expressed a
> desire for several points to be addressed by supplemental agreements to the
> IETF-ICANN MoU, prior to a transition to post-NTIA regime. Over the years
> since the creation of ICANN, the IETF, ICANN, and IAB have together created
> a system of agreements, policies, and oversight mechanisms that covers what
> is needed.
>
> 1.  maintains the IANA functions operator's obligations established under
> C.7.3 and I.61 of the current IANA functions contract between ICANN and the
> NTIA [NTIA-Contract]; and
>
> No major changes are required. Over the years since the creation of ICANN,
> the IETF, ICANN, and IAB have together created a system of agreements,
> policies, and oversight mechanisms that covers what is needed.
>
> It is possible in the future that the operation of the protocol parameters
> registries will be transitioned from ICANN to subsequent operator(s). In
> the event of such a transition, it is the expectation of the IETF community
> that ICANN 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. Furthermore, in the event
> of a transition it is the expectation of the IETF community that ICANN and
> the IETF will work together to minimize confusion on the part of those who
> use the protocol parameters registries and other visitors to iana.org.
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Nov 2014 18:53:53 -1000

On Nov 11, 2014, at 4:22 PM, Alissa Cooper <[email-masked]> wrote:
> 
> It is possible in the future that the operation of the protocol parameters registries will be transitioned from ICANN to subsequent operator(s). In the event of such a transition, it is the expectation of the IETF community that ICANN 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. 

[BA] The plan for carrying out those contractual obligations was to have been submitted by ICANN to NTIA. However AFAIK, the plan has not been made public. So how do we evaluate it? Is it our expectation that mentioning this in the ICG response will make it more likely to be released?

---

From: Seun Ojedeji <[email-masked]>
Date: Wed, 12 Nov 2014 06:27:18 +0100

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

operator(s).
I think a "may" will be more appropriate here. Because it's  currently
looking like a certain possibility which is not the case. ;)

In the event of such a transition, it is the expectation of the IETF
community that ICANN 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.
Is there a reason why we are making reference to a contract that is going
to become null and void? I would suggest not referencing NTIA-Contract.
However since there is a text in there to be referenced then it will be
good to paste those text as part of this proposal.

Furthermore, in the event of a transition it is the expectation of the IETF
community that ICANN and the IETF will work together to minimize confusion
on the part of those who use the protocol parameters registries and other
visitors to iana.org.
I think the transition referred to here is incase ICANN is no more the
operator right? So I think it should be ICANN, the IETF and the new
operator....

Cheers!

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 12 Nov 2014 09:01:50 +0100

> On 12 Nov 2014 03:21, "Alissa Cooper" <[email-masked]> wrote:
<snip>
> operator right? So I think it should be ICANN, the IETF and the new

Agree, the possible new operator should be mention so even if it's
quite obvious. Could that change be combined with what Ted Hardie
wrote earlier:

On Wed, Nov 12, 2014 at 4:07 AM, Ted Hardie <[email-masked]> wrote:
> "to minimize disruption in the use the protocol parameters registries or other resources at iana.org".

Old text:
Furthermore, in the event of a transition it is the expectation of the
IETF community that ICANN and the IETF will work together to minimize
confusion on the part of those who use the protocol parameters
registries and other visitors to iana.org.

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

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

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

Thank you for this.

I do not agree with the new text, for the reasons mentioned in previous
E-Mails.

Best,
Richard
  -----Original Message-----
  From: Ianaplan [mailto:[email-masked]]On Behalf Of Alissa
Cooper
  Sent: mercredi, 12. novembre 2014 03:22
  To: [email-masked]
  Subject: [Ianaplan] Proposed text reflecting IETF91 discussion

  Below is suggested text for the first part of the response to RFP Section
III, based on the WG discussion yesterday. As discussed, this text focuses
on the IETF community’s must-haves, states the desired outcomes and not the
processes to arrive there, and removes the "the IAOC is asked to conclude a
supplemental agreement that” text. The other reference to the IAOC remains,
since it’s asking them to engage with other parties, which is something they
do anyway.

  === OLD ===
  IETF Response:

  First and foremost, 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.

  2.  requires the transfer of any associated marks and identifiers to
subsequent operators.

  === NEW ===
  IETF Response:

  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.

  It is possible in the future that the operation of the protocol parameters
registries will be transitioned from ICANN to subsequent operator(s). In the
event of such a transition, it is the expectation of the IETF community that
ICANN 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. Furthermore, in the event of a transition it
is the expectation of the IETF community that ICANN and the IETF will work
together to minimize confusion on the part of those who use the protocol
parameters registries and other visitors to iana.org.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Nov 2014 08:58:41 +0000

Yep, that NEW text is much better and I think
reflects the discussion I (remotely) heard/saw at
IETF-91.

S.

On 12/11/14 02:22, Alissa Cooper wrote:
> Section III, based on the WG discussion yesterday. As discussed, this
> text focuses on the IETF community’s must-haves, states the desired
> outcomes and not the processes to arrive there, and removes the "the
> IAOC is asked to conclude a supplemental agreement that” text. The
> other reference to the IAOC remains, since it’s asking them to engage
> with other parties, which is something they do anyway.
> 
> === OLD === IETF Response:
> 
> No major changes are required, however, the IETF community has
> expressed a desire for several points to be addressed by supplemental
> agreements to the IETF-ICANN MoU, prior to a transition to post-NTIA
> regime. Over the years since the creation of ICANN, the IETF, ICANN,
> and IAB have together created a system of agreements, policies, and
> oversight mechanisms that covers what is needed.
> 
> 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.
> 
> To address issues raised by the IETF community relating to
> intellectual property rights, the IAOC is asked to engage the
> appropriate parties, both inside and outside the IETF, to make clear
> that data in the protocol parameters registries is in the public
> domain.
> 
> To address a desire by the IETF community to have mechanisms that
> allow for additional dispute resolution between the IETF and the
> current IANA protocol registries operator, the IAOC is asked to
> conclude a supplemental agreement regarding jurisdiction and any
> necessary dispute resolution mechanisms that are mutually acceptable
> to the parties.
> 
> To address concerns regarding appropriate contingencies to transition
> to another operator, the IAOC is asked to conclude a supplemental
> agreement that-
> 
> under C.7.3 and I.61 of the current IANA functions contract between
> ICANN and the NTIA [NTIA-Contract]; and
> 
> === NEW === IETF Response:
> 
> 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.
> 
> To address issues raised by the IETF community relating to
> intellectual property rights, the IAOC is asked to engage the
> appropriate parties, both inside and outside the IETF, to make clear
> that data in the protocol parameters registries is in the public
> domain.
> 
> operator(s). In the event of such a transition, it is the expectation
> of the IETF community that ICANN 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. Furthermore, in the event of a transition it is
> the expectation of the IETF community that ICANN and the IETF will
> work together to minimize confusion on the part of those who use the
> protocol parameters registries and other visitors to iana.org.
> 
> 
> 
> _______________________________________________ Ianaplan mailing
> list [email-masked]

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 12 Nov 2014 08:59:35 +0000 (UTC)

De : Roger Jørgensen <[email-masked]>
 À : "[email-masked]" <[email-masked]>; Alissa Cooper <[email-masked]> 
 Envoyé le : Mercredi 12 novembre 2014 9h01
 Objet : Re: [Ianaplan] Proposed text reflecting IETF91 discussion
   
Old text:

Suggested new text:

--------------------------------------Hi to all,We must look at it deeply.
new operator(s) = possibility to have one or more operators !!!This statement can open some confusion in the implementation tomorrow

Regards,/Janvier Ngnoulaye
--

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 12 Nov 2014 10:37:27 +0000

Great stuff. I do like Ted's proposed tweak to the text, but overall this admirably captures the direction we should head.

I still have some nagging doubts about our ICG response assigning tasks to the IAOC - though I heartily agree that the IETF's position must be that the protocol parameter registry contents reside in the public domain, regardless of how we instruct advocates to clarify our position.

Jon Peterson
Neustar, Inc.

From: Alissa Cooper <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 11, 2014 at 6:22 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Ianaplan] Proposed text reflecting IETF91 discussion

=== OLD ===
IETF Response:

=== NEW ===
IETF Response:

It is possible in the future that the operation of the protocol parameters registries will be transitioned from ICANN to subsequent operator(s). In the event of such a transition, it is the expectation of the IETF community that ICANN 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. Furthermore, in the event of a transition it is the expectation of the IETF community that ICANN and the IETF will work together to minimize confusion on the part of those who use the protocol parameters registries and other visitors to iana.org<http://iana.org>.

---

From: JFC Morfin <[email-masked]>
Date: Wed, 12 Nov 2014 11:10:32 +0100

At 09:04 12/11/2014, Richard Hill wrote:
>Thank you for this.
>
>I do not agree with the new text, for the reasons mentioned in 
>previous E-Mails.

+1
jfc

---

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

I can't support the new version. It's a short-sighted and complacent approach to the transition. I don't think it responds to the ICG RFP in a way that provides a well-defined transition plan.

From: Ianaplan [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: Tuesday, November 11, 2014 9:22 PM
To: [email-masked]
Subject: [Ianaplan] Proposed text reflecting IETF91 discussion

Below is suggested text for the first part of the response to RFP Section III, based on the WG discussion yesterday. As discussed, this text focuses on the IETF community's must-haves, states the desired outcomes and not the processes to arrive there, and removes the "the IAOC is asked to conclude a supplemental agreement that" text. The other reference to the IAOC remains, since it's asking them to engage with other parties, which is something they do anyway.

=== OLD ===
IETF Response:

=== NEW ===
IETF Response:

---

From: Seth Johnson <[email-masked]>
Date: Wed, 12 Nov 2014 09:26:43 -0500

I have to agree with Mueller in his broadly stated position.

I promised a bit back to offer input on version -01 but have had to
focus on the stuff going on in the ITU Plenipot.  I still intend to
offer something with a more sufficient methodological approach.  But
this transition is being moved right in the midst of a lot of things
going down all at once, and I personally remain distracted.

Occasionally dipping back into the discussion, watching the dynamics
has been revelatory -- as well as reading that IETF session.

Seth

On Wed, Nov 12, 2014 at 9:08 AM, Milton L Mueller <[email-masked]> wrote:
> I can’t support the new version. It’s a short-sighted and complacent
> approach to the transition. I don’t think it responds to the ICG RFP in a
> way that provides a well-defined transition plan.
>
>
>
> First and foremost, 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.
>
> To address a desire by the IETF community to have mechanisms that allow for
> additional dispute resolution between the IETF and the current IANA protocol
> registries operator, the IAOC is asked to conclude a supplemental agreement
> regarding jurisdiction and any necessary dispute resolution mechanisms that
> are mutually acceptable to the parties.
>

---

From: Geoff Huston <[email-masked]>
Date: Thu, 13 Nov 2014 03:41:46 +1100

I agree with this suggested text.

Geoff

> On 12 Nov 2014, at 1:22 pm, Alissa Cooper <[email-masked]> wrote:
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Nov 2014 11:51:58 -0500

I think this proposal, with or without Ted's friendly amendment, is fine.

Downthread someone asks why to refer to a contract that is going away;
the point here is precisely to state the IETF's preference that those
terms persist.  This is in keeping with the interpretation of this
text as not "text of an agreement" but "an expression of the IETF's
position."  So I think it is also the right thing to do.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Nov 2014 09:32:40 -1000

Hi,

On 11/11/14, 4:22 PM, Alissa Cooper wrote:
> that data in the protocol parameters registries is in the public domain.
>
> that data in the protocol parameters registries is in the public domain.

The above statement is not strong enough.  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.

> smooth transition. Furthermore, in the event of a transition it is the
> expectation of the IETF community that ICANN and the IETF will work
> together to minimize confusion on the part of those who use the
> protocol parameters registries and other visitors to iana.org
> <http://iana.org>. 

The above statement is again not strong enough, and I would prefer the
following:

It is possible in the future that the operation of the protocol
parameters registries will be transitioned from ICANN to subsequent
operator(s). It is the *preference* of the IETF community that,*as part
of the 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 a new operator, should the need arise.*
Furthermore, in the event of a transition it is the expectation of the
IETF community that ICANN and the IETF will work together to minimize
confusion on the part of those who use the protocol parameters
registries and other visitors to iana.org <http://iana.org>.

This addresses your earlier concerns by allowing sufficient flexibility
for any discussions that happen in the coming months.  The issue with
the word "expectation" is that we can all have expectations, and they
may be realized or not.  A preference states what we would like to see
happen.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Nov 2014 10:02:57 -1000

This seems like gratuitous bikeshedding; this level of detailed language
hermeneutics
generally doesn't make a difference outside of legal contexts.

With that said, I think your proposed changes make things worse. In *this*
context,
expectation means that we want you to do it *and* believe that you will do
so
and that we don't have a meeting of the minds if you don't. That's stronger
than preference.

-Ekr

On Wed, Nov 12, 2014 at 9:32 AM, Eliot Lear <[email-masked]> wrote:

> registries will be transitioned from ICANN to subsequent operator(s). It is
> the *preference* of the IETF community that,* as part of the transition, *
> ICANN *acknowledge that it *will carry out the obligations established
> and the NTIA [NTIA-Contract] to achieve a smooth transition *to a new
> operator, should the need arise.* Furthermore, in the event of a
> transition it is the expectation of the IETF community that ICANN and the
> IETF will work together to minimize confusion on the part of those who use
> the protocol parameters registries and other visitors to iana.org.
>
> for any discussions that happen in the coming months.  The issue with the
> word "expectation" is that we can all have expectations, and they may be
> realized or not.  A preference states what we would like to see happen.
>
> Eliot
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Nov 2014 10:07:37 -1000

On 11/12/14, 10:02 AM, Eric Rescorla wrote:
> This seems like gratuitous bikeshedding; this level of detailed
> language hermeneutics
> With that said, I think your proposed changes make things worse. In
> *this* context,
> expectation means that we want you to do it *and* believe that you
> will do so

Expectations are often not met, and worse, needn't even be acknowledged
by others.

Eliot

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Nov 2014 10:26:42 -1000

Be aware that there *is* a legal context here (the NTIA-ICANN contract), but it required filing of a transition plan for all IANA functions that AFAIK is not public. So the ICANN transition plan could cover everything we care about, nothing or something in between. 

Also keep in mind that the plan not only covers ICANN obligations to the new contractor, but also potentially to the USG which may not be willing to participate in a transition once it leaves the scene. So some of the text in the referenced sections may not apply post-transition.

So my perspective is that the paragraphs are a conversation starter. We probably do need something and it is IAOC's job to figure it out. But let's not over constrain them.

> On Nov 12, 2014, at 10:02 AM, Eric Rescorla <[email-masked]> wrote:
> 
> This seems like gratuitous bikeshedding; this level of detailed language hermeneutics
> With that said, I think your proposed changes make things worse. In *this* context,
> expectation means that we want you to do it *and* believe that you will do so
>> The above statement is not strong enough.  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.
>> 
>>> 
>> The above statement is again not strong enough, and I would prefer the following:
>> 
>> 
>> 
>> It is possible in the future that the operation of the protocol parameters registries will be transitioned from ICANN to subsequent operator(s). It is the preference of the IETF community that, as part of the 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 a new operator, should the need arise. Furthermore, in the event of a transition it is the expectation of the IETF community that ICANN and the IETF will work together to minimize confusion on the part of those who use the protocol parameters registries and other visitors to iana.org. 
>> 
>> This addresses your earlier concerns by allowing sufficient flexibility for any discussions that happen in the coming months.  The issue with the word "expectation" is that we can all have expectations, and they may be realized or not.  A preference states what we would like to see happen. 
>> 
>> Eliot
>>

---

From: Andrei Robachevsky <[email-masked]>
Date: Wed, 12 Nov 2014 21:38:04 +0100

Hi,

I am fine with the proposed NEW version. I also like Ted's editorial
suggestions.

To the point of not being "strong enough" raised by some people, I am
glad that in the proposed version we do not go down the road embedding
solutions in the response, because it will never be strong enough,
unless we attach the actual contract, preferably signed by both parties.

At the same time I have a question: is there an expectation that
additional work will be done by the IAOC to find appropriate instruments
(e.g. a supplemental agreement, exchange of letters, etc.) to ensure
that the expectation of the IETF community is met?

Andrei

Alissa Cooper wrote on 12/11/14 03:22:
> IAOC is asked to conclude a supplemental agreement that” text. The other
> reference to the IAOC remains, since it’s asking them to engage with
> other parties, which is something they do anyway.
> 
> === OLD ===
> IETF Response:
> 
> a desire for several points to be addressed by supplemental agreements
> to the IETF-ICANN MoU, prior to a transition to post-NTIA regime. Over
> the years since the creation of ICANN, the IETF, ICANN, and IAB have
> together created a system of agreements, policies, and oversight
> mechanisms that covers what is needed.
> 
> arrangement with ICANN.  RFC 2860 remains in force and has served the
> IETF community very well.  RFC 6220 has laid out an appropriate service
> property rights, the IAOC is asked to engage the appropriate parties,
> both inside and outside the IETF, to make clear that data in the
> protocol parameters registries is in the public domain.
> 
> protocol registries operator, the IAOC is asked to conclude a
> supplemental agreement regarding jurisdiction and any necessary dispute
> resolution mechanisms that are mutually acceptable to the parties.
> 
> property rights, the IAOC is asked to engage the appropriate parties,
> both inside and outside the IETF, to make clear that data in the
> protocol parameters registries is in the public domain.
> 
> ICANN and the NTIA [NTIA-Contract] to achieve a smooth transition.

---

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

I strongly support these very sensible amendments proposed by Eliot. They are minor and ought to satisfy both sides of this disagreement. In particular, without the words “to a new operator, should the need arise” the sentence becomes a completely indefinite gesture in the direction of some kind of unspecified ‘transition,’ which would never be acceptable to me.

--MM

It is possible in the future that the operation of the protocol parameters registries will be transitioned from ICANN to subsequent operator(s). It is the preference of the IETF community that, as part of the 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 a new operator, should the need arise. Furthermore, in the event of a transition it is the expectation of the IETF community that ICANN and the IETF will work together to minimize confusion on the part of those who use the protocol parameters registries and other visitors to iana.org<http://iana.org>.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Nov 2014 10:52:12 -1000

On Wed, Nov 12, 2014 at 10:07 AM, Eliot Lear <[email-masked]> wrote:

> Expectations are often not met, and worse, needn't even be acknowledged by
> others.
>

And preferences are often ignored and also don't need to be acknowledged.

-Ekr

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 12 Nov 2014 13:37:06 -1000

Hi Seun,

On Nov 11, 2014, at 7:27 PM, Seun Ojedeji <[email-masked]> wrote:

> > It is possible in the future that the operation of the protocol parameters registries will be transitioned from ICANN to subsequent operator(s).
> >
> I think a "may" will be more appropriate here. Because it's  currently looking like a certain possibility which is not the case. ;)
> 
> 

Agreed.
> >
> In the event of such a transition, it is the expectation of the IETF community that ICANN 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.
> >
> Is there a reason why we are making reference to a contract that is going to become null and void? I would suggest not referencing NTIA-Contract. However since there is a text in there to be referenced then it will be good to paste those text as part of this proposal.
> 
> 

The idea here is that there is a good set of obligations outlined in the existing contract (have a transition plan, furnish phase-in and phase-out services, etc.), but the precise words there would not necessarily be appropriate here, since they make references to the USG and specific timelines and so forth that could be different in the event of a future transition. So referencing the obligations generally makes more sense than quoting the text.
> >
> Furthermore, in the event of a transition it is the expectation of the IETF community that ICANN and the IETF will work together to minimize confusion on the part of those who use the protocol parameters registries and other visitors to iana.org. 
> >
> I think the transition referred to here is incase ICANN is no more the operator right? So I think it should be ICANN, the IETF and the new operator....
> 
> 

Agreed, assuming we make room for multiple subsequent operators.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 12 Nov 2014 13:39:01 -1000

Hi Janvier,

On Nov 11, 2014, at 10:59 PM, [email-masked] wrote:

> 
> 
> --------------------------------------
> Hi to all,
> We must look at it deeply.
> new operator(s) = possibility to have one or more operators !!!

Indeed, that is the intent, as has been discussed on this list. There is no need to constrain ourselves at this point.

Alissa

> This statement can open some confusion in the implementation tomorrow
> 
> 
> Regards,
> /Janvier Ngnoulaye
> 
> -- 
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Nov 2014 00:57:24 +0000

That fact that you would see such a vast change in the semantics of the sentence due to this addition makes me fear that we're reading for code words here rather than the simple propositions Alissa put forward. What else would a "smooth transition" be to, given that the previous sentence says "transitioned from ICANN to subsequent operator(s)"? Is that the operator would be "new" that is so transformative to this idea? And what could "should the need arise" possibly add to this?

Jon Peterson
Neustar, Inc.

From: Milton L Mueller <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 12, 2014 at 12:42 PM
To: Eliot Lear <[email-masked]<mailto:[email-masked]>>, 'Alissa Cooper' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ianaplan] Proposed text reflecting IETF91 discussion

--MM

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Nov 2014 15:35:56 -1000

It's not codeword.  What we are seeking is a basis for further
discussion on points that are our preferences.

It's that simple, and the timeframe of the ICG allows for that dialog to
occur in a way that is not rushed.

Eliot

On 11/12/14, 2:57 PM, Peterson, Jon wrote:
>
> That fact that you would see such a vast change in the semantics of
> the sentence due to this addition makes me fear that we're reading for
> code words here rather than the simple propositions Alissa put
> forward. What else would a "smooth transition" be to, given that the
> previous sentence says "transitioned from ICANN to subsequent
> operator(s)"? Is that the operator would be "new" that is so
> transformative to this idea? And what could "should the need arise"
> possibly add to this?
>
> Jon Peterson
> Neustar, Inc.
>
> From: Milton L Mueller <[email-masked] <mailto:[email-masked]>>
> To: Eliot Lear <[email-masked] <mailto:[email-masked]>>, 'Alissa
> Cooper' <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>'" <[email-masked]
> <mailto:[email-masked]>>
> I strongly support these very sensible amendments proposed by Eliot.
> They are minor and ought to satisfy both sides of this disagreement.
> In particular, without the words “*to a new operator, should the need
> arise” *the sentence becomes a completely indefinite gesture in the
> direction of some kind of unspecified ‘transition,’ which would never
> be acceptable to me.
>
>  
>
> --MM
>
>  
>
> community that all relevant parties acknowledge that fact as part of
> the transition.
>
>
>
>     parameters registries will be transitioned from ICANN to
>     subsequent operator(s). In the event of such a transition, it is
>     the expectation of the IETF community that ICANN 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. Furthermore, in the event of a
>     transition it is the expectation of the IETF community that ICANN
>     and the IETF will work together to minimize confusion on the part
>     of those who use the protocol parameters registries and other
>     visitors to iana.org <http://iana.org>. 
>
>
> operator(s). It is the *preference* of the IETF community that,*as
> part of the 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 a new operator, should the need
> arise.* Furthermore, in the event of a transition it is the
> This addresses your earlier concerns by allowing sufficient
> flexibility for any discussions that happen in the coming months.  The
> issue with the word "expectation" is that we can all have
> expectations, and they may be realized or not.  A preference states
> what we would like to see happen.
>
> Eliot
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 12 Nov 2014 16:36:40 -1000

Hi Eliot,

I’m fine with the changes you suggest below since to me they don’t seem to change anything substantive in a direction that I disagree with, but I have one question:

On Nov 12, 2014, at 9:32 AM, Eliot Lear <[email-masked]> wrote:
> It is possible in the future that the operation of the protocol parameters registries will be transitioned from ICANN to subsequent operator(s). It is the preference of the IETF community that, as part of the 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 a new operator, should the need arise.

The first sentence of the paragraph refers to a potential future transition from ICANN to subsequent operator(s). In the second sentence, when you say “as part of the transition,” were you referring to the NTIA transition? Or did you mean something like “in advance of such a transition” in the second sentence?

Thanks,
Alissa

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Nov 2014 16:48:56 -1000

Hi Alissa,

Please see below:

On 11/12/14, 4:36 PM, Alissa Cooper wrote:
>> achieve a smooth transition *to a new operator, should the need arise.*
>
> The first sentence of the paragraph refers to a potential future
> transition from ICANN to subsequent operator(s). In the second
> sentence, when you say “as part of the transition,” were you referring
> to the NTIA transition? Or did you mean something like “in advance of
> such a transition” in the second sentence?

Indeed I meant "as part of the NTIA transition".  That is- let's have
the conversation now, on good terms, with a view towards what is best
for the Internet.  Thanks for asking for the clarification.

Eliot

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 12 Nov 2014 17:36:28 -1000

Ok. Sharing updated text reflecting edits suggested by Ted, Seun, and Eliot:

=== NEW ===
IETF Response:

To address issues relating to intellectual property rights, it is the preference of the IETF community that the appropriate parties, both inside and outside the IETF, make clear that data in the protocol parameters registries is in the public domain.

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.

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

> Indeed I meant "as part of the NTIA transition".  That is- let's have the conversation now, on good terms, with a view towards what is best for the Internet.  Thanks for asking for the clarification.
> 
> Eliot
>

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Nov 2014 22:56:02 -0500

I think this is fine text.  I would like to see it achieve broad agreement.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Nov 2014 18:22:44 -1000

It is indeed fine text. The part I  am unclear about is whether it implies task(s) for the IAOC.

> On Nov 12, 2014, at 5:56 PM, Andrew Sullivan <[email-masked]> wrote:
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 12 Nov 2014 22:59:41 -1000

Hi Bernard,

> It is indeed fine text. The part I  am unclear about is whether it implies task(s) for the IAOC.

The intent is to simply make clear that discussions should take place,
perhaps at multiple points between organizations.

Eliot

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 13 Nov 2014 10:33:16 +0100

Dear Alissa,

Thank you for your efforts, but I'm afraid that I still cannot agree to the
text that  you propose below.  In order to explain why, I'd like to recall
the background.

This process was initiated by the NTIA requesting ICANN to propose a plan to
transition away from the NTIA's current role.  ICANN chartered the ICG to
prepare that plan, and in turn the ICG asked the IETF to prepare a proposal
regarding the protocol parameters part of the IANA function.

The IETF created this working group to prepare that proposal.  The charter
of this working group says "This working group is chartered solely with
respect to the planning
needed for the transition, and is not meant to cover other topics related to
IANA. Possible improvements outside that scope will be set aside for future
consideration. However, the mechanisms required to address the removal of
the overarching NTIA contract may require additional documentation or
agreements. The WG will identify, but
not create, such required agreements."

In this context, a plan is a series of specific steps that are expected to
result in the desired outcome.  As indicated in the charter of this working
group, the plan might include a call for the creation of additional
documentation or agreements.

In this context, the desired outcome is a situation in which the IANA
functions are performed at least as well as they are today, and that
maintains security, stability, and resiliency.

As far as I can tell, many people in this group are of the view that the
current NTIA-ICANN IANA functions contract has no significant consequences
or effects with respect to the protocol parameters part of the IANA
functions, and that it would be difficult, and even counter-productive, to
try to develop a detailed contigency plan (and associated contracts or
whatever) to deal with various scenarios that might arise after the current
contract ends.  As I understand it, the view is that appropriate steps can,
and will be taken, in response to whatever situation may arise in the
future.  Any disruptions that might arise would not be significant and it is
not appropriate to try to foresee them and minimize them at this time, much
less to call for negotiation of new contracts.

The text that you propose below is consistent with that view, but it is not
a plan: expressing a preference for something specifies a goal, not a series
of steps to meet the goal.  Similarly, stating an expectation is not a plan.

Further, in my opinion, the text in question is not a proper response to
what was requested in the RFP.

The text in question appears in the section of the RPF that says:

"If your community is not proposing changes to arrangements listed in
Section II.B, the rationale and justification for that choice should be
provided here."

So it seems to me that an appropriate text would be some version of what
I've outlined above, namely that there does not appear to be a need to
change anything at this time, but that the IETF will take appropriate steps
in the future, if needed and as the case may be.

Needless to say, I don't agree with that.

But I think that it would be better if the response to the ICG replied more
explicitly to what the ICG requested.

Best,
Richard

-----Original Message-----
From: Ianaplan [mailto:[email-masked]]On Behalf Of Alissa Cooper
Sent: jeudi, 13. novembre 2014 04:36
To: Eliot Lear
Cc: [email-masked]
Subject: Re: [Ianaplan] Proposed text reflecting IETF91 discussion

=== NEW ===
IETF Response:

To address issues relating to intellectual property rights, it is the
preference of the IETF community that the appropriate parties, both inside
and outside the IETF, make clear that data in the protocol parameters
registries is in the public domain.

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.

Hi Alissa,

Please see below:

It is possible in the future that the operation of the protocol parameters
registries will be transitioned from ICANN to subsequent operator(s). It is
the preference of the IETF community that, as part of the 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 a new operator, should the
need arise.

The first sentence of the paragraph refers to a potential future transition
from ICANN to subsequent operator(s). In the second sentence, when you say
“as part of the transition,” were you referring to the NTIA transition? Or
did you mean something like “in advance of such a transition” in the second
sentence?

Indeed I meant "as part of the NTIA transition".  That is- let's have the
conversation now, on good terms, with a view towards what is best for the
Internet.  Thanks for asking for the clarification.

Eliot

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Nov 2014 10:01:28 +0000

On 11/13/14, 1:33 AM, "Richard Hill" <[email-masked]> wrote:
>contract ends. 

The IETF's MoU with ICANN for the protocol parameter registries has no
explicit dependency on the NTIA. In so far as many people here express a
desire to continue the relationship described in RFC2860, you are correct,
our understanding of that relationship is not predicated on the NTIA
retaining any particular role. However, the IETF has several remedies at
our disposal in the event that the RFC2860 relationship is no longer
viable. Our power to exercise these options constitutes a sufficient
contingency plan in my estimation; I understand that others feel more
drastic, disruptive, and preemptive measures are required to ensure
"stability" and to stave off some future unlikely contingencies. But
actually taking these steps would only guarantee the opposite of stability
today.

> As I understand it, the view is that appropriate steps can,

We can foresee and minimize them without, you know, utterly transforming
our organization and overstepping our bounds as a constituent of the
multistakeholder model. Upending the multistakeholder model is clearly a
priority for some participants in this discussion, and I grasp how that
upheaval might benefit some parties and penalize others. Ultimately, I
don't think the IETF would benefit under those conditions.

>of steps to meet the goal.  Similarly, stating an expectation is not a

Given the dynamism inherent in this situation, I don't think the IETF
would be wise to seek consensus on a "plan," as it would quickly be
overcome by events. Instead, we need consensus on the goals and outcomes
we hope to seek. I think the current text provides exactly that.

Jon Peterson
Neustar, Inc.

---

From: Russ Mundy <[email-masked]>
Date: Thu, 13 Nov 2014 00:07:57 -1000

Jon,

Thanks for the clearly stated position in your email - I fully support that position.

Russ Mundy

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Nov 2014 10:28:32 +0000

Ditto. I'm fine with the latest text Alissa proposed and
agree with Jon's response to Richard.

I'd also note that just because the wg is concerned with
planning does not mean that it ought produce a plan - in
just the same way as other wgs develop requirements but
don't need to have those requirements published in an RFC.

And in any case, that para in the charter is more saying
"don't go off topic, just plan as needed for <this>" and
is not saying "go document me a plan" so I think Richard's
argument falls in any case.

S.

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 13 Nov 2014 14:26:58 +0000

> Our power to
> exercise these options constitutes a sufficient contingency plan in my
> estimation; I understand that others feel more drastic, disruptive, and
> preemptive measures are required to ensure "stability" and to stave off

Calling for a more explicit approach to transition arrangements which may not ever have to be exercised, is not "drastic, disruptive, or pre-emptive." I am scratching my head trying to figure out why you have to resort to such hyperbole, but maybe your next argument clarifies this.

> upheaval might benefit some parties and penalize others. Ultimately, I don't
> think the IETF would benefit under those conditions.

Upending the multistakeholder model? Are you serious? This is way out of line. I've been fighting for that model before anyone in the IETF knew how to pronounce the term. And I still am. 

I think you're going to have to explain how pushing for IETF, a voluntary, private sector standards organization, to retain control of a domain and trademark associated with its own IANA functions is an attack on the MS model. Some of us think it strengthens it. 

I've become increasingly convinced that the resistance to the calls for an intelligent disposition of the domain and trademark was motivated by something other than the factual and logical merits of the case; this clinches the deal.

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Nov 2014 11:51:02 -0500

(cc list trimmed)

--On Thursday, November 13, 2014 14:26 +0000 Milton L Mueller
<[email-masked]> wrote:

>> Our power to
>> exercise these options constitutes a sufficient contingency
>> plan in my estimation; I understand that others feel more
>> drastic, disruptive, and preemptive measures are required to
>> ensure "stability" and to stave off
> 
> Calling for a more explicit approach to transition
> arrangements which may not ever have to be exercised, is not
> "drastic, disruptive, or pre-emptive." I am scratching my head
> trying to figure out why you have to resort to such hyperbole,
> but maybe your next argument clarifies this.

Milton, I agree that hyperbole is not helpful, but there seems
to be a lot of it going around.  See below (where I also try to
respond to the core issue of "transition arrangements which may
not ever have to be exercised").

>> multistakeholder model. Upending the multistakeholder model
>> is clearly a priority for some participants in this
>> discussion, and I grasp how that upheaval might benefit some
>> parties and penalize others. Ultimately, I don't think the
>> IETF would benefit under those conditions.
> 
> Upending the multistakeholder model? Are you serious? This is
> way out of line. I've been fighting for that model before
> anyone in the IETF knew how to pronounce the term.

Excuse me?  "anyone in the IETF"?  "pronounce the term"?   Can
we _all_ try to keep the hyperbole down in the hope of having a
focused discussion and making progress?  If nothing else,
reducing or eliminating the hyperbole would save people the
temptation to accuse others of things they are doing themselves.

>...
(Reordering for convenience - I hope you don't feel it distorts
meaning)

> I've become increasingly convinced that the resistance to the
> calls for an intelligent disposition of the domain and
> trademark was motivated by something other than the factual
> and logical merits of the case; this clinches the deal.

The above appears to me to move past hyperbole and into
activities close to name-calling.  Personal predictions that it
would occur (without any desire or need to predict where and
with whom it would start) were what kept me off this list until
about a week ago.  If we cannot have a civilized and focused
discussion, with a minimum of hyperbole, unsupported allegations
of secret motives, etc., the value of the list itself becomes
questionable.  See below.

>...
> I think you're going to have to explain how pushing for IETF,
> a voluntary, private sector standards organization, to retain
> control of a domain and trademark associated with its own IANA
> functions is an attack on the MS model. Some of us think it
> strengthens it.

Disclaimer: personal opinions, not speaking for any other member
of the IETF community, especially those who have taken the
strategy and editorial leads in this matter.

First, I think it would have been desirable and appropriate for
the various  domain names and other marks and trappings to have
been transferred to the IAB, or perhaps ISOC as trustee for the
IAB, back when IANA was moved out of ISI.   I said so at the
time.   For a lot of reasons, at least some of which were good
ones, it didn't happen.

As I have explained in a different context, when I look at the
present situation in terms of threat models rather than
theoretical concerns in the best of all possible worlds, I don't
worry very much about a lot of the trappings of either an
ICANN-operated IANA function or a smooth and relatively friendly
transfer of the entire IANA function to another body.  In either
scenario, I just cannot identify incentives to use or misuse the
domain or mark(s) in ways that would cause harm to the Internet
community (perhaps irritation, but not harm) -- links,
redirects, and subdomains are just too easy if people are
cooperating.  Conversely, I believe that any truly hostile
situation, including massive and uncorrected malfeasance on
ICANN's part, would almost certainly result in splitting up the
IANA function, separating  at least the address and protocol
functions (including the ARPA TLD) from the root zone (TLD)
allocation and management functions.  

If the community is required to untangle the three collections
of services, that process will be painful and disruptive
regardless of what the resulting components are called and who
controls them.  In particular, who "owns" the domain and/or
various trademarks or service marks is unlikely to cause more
than minor annoyance, if that, in the grand scheme of such a
transition.  Yes, I've thought a lot about that set of
contingencies but they just don't seem to have much to do with
the present NTIA transition.

Would I prefer that the domain and marks end up in IAB (or IETF
Trust) hands?  Yes.  But, for the reasons above, I don't
consider it important enough to justify complicating this
document, especially since it would then require sorting through
a series of other contingencies such as what would occur if the
IETF community decided to organize one group or the other out of
existence.   I would rather keep this document and statement as
simple, focused on critical issues, and non-complex as possible
and do not, for the reasons above, consider that issue critical.

YMMD.

Finally, despite the wide use of the term and who could
pronounce it and when, I don't consider the invocation, as a
kind of litany, of "multistakeholder model" to be helpful.
Especially when a function that is essentially technical and
administrative (rather than policy-developing) like the IANA is
concerned, there are strong arguments for discussions that favor
the voices of those with expertise in the kinds of operations
involved and who have "skin in the game".  In that context, the
multistakeholder model has too often been interpreted as giving
an equal voice to those who merely have strong opinions and
maybe excessive time on their hands.  I've described that pair
of qualifications before as the ability and willingness to pick
up a stake and carry it around, noting that a stake is often
historically a sharp, pointed, instrument characterized by its
uses in punishing those who disagree with the stake
administrator or holder.   Sharpening, counting, and carrying
stakes is not how I think we should be making decisions about
the Internet or much of anything else. 

I don't want to cut anyone out of the conversations, but I do
think it is necessary to keep expertise and fact-grounded
reasoning as priorities, not just yield to, e.g., those who can
repeat that they disagree or wish things were otherwise.

Again, YMMD.

best,
    john

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Nov 2014 16:58:09 +0000

> the present NTIA transition.

Well said.

S.

---

From: Seth Johnson <[email-masked]>
Date: Thu, 13 Nov 2014 12:18:04 -0500

It is a good statement, though it focuses on explicit relations among
IETF, IANA and ICANN.

The basic nature of the real problem raised by the transition isn't
about ICANN, but the inter-governmental context that arises in the
international arena, wherever it will arise.  ICANN is sort of one
type of proxy for that.

Seth

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2014 06:24:54 +1300

> temptation to accuse others of things they are doing themselves.

Fair enough, but I do think my friend Jon was a bit wrong in that
particular statement. There certainly are people who would have
liked to upend the multistakeholder model - many of them were
recently in Busan, I believe - but Milton surely isn't one of them.
And regardless of who first used the term "multistakeholder"
the model has been in de facto use inside the IETF world for a long
time, and lies behind our rough consensus model.

What I do see in this discussion is that long-time IETF participants
are very keen on narrowly scoping the WG document to limit it strictly
to the IETF's concerns. Whenever broader considerations are raised,
we push back. If I take my IETF hat off, I might be sympathetic to
those broader considerations. But over many years, the IETF has done
quite well in the wider multistakeholder world by sticking to its own
knitting.

   Brian

---

From: Steve Crocker <[email-masked]>
Date: Thu, 13 Nov 2014 12:55:46 -0500

[Resending from my Shinkuro email address because that’s apparently how I signed up for the Ianaplan WG.]

Folks,

With respect to making it clear that data in the protocol parameter registries is in the public domain, I am in strong agreement with this and I don’t see any reason for ICANN to assert any rights or impose any restrictions on the protocol parameter registries, though one small detail comes to mind; see below.

I write to move beyond a general agreement in principle to comment on implementation.  The information in the protocol parameter registries are created by the IETF and by various individuals who register specific parameters.  Intellectual property rights originate with the originators of the information.  Thus it seems to me the natural way to implement the intended result is for the IETF to declare, which it may already have done, that this information is in the public domain.  Further, if the appropriate language is not already in the agreements between the IETF and ICANN, some wording can be added to require that the information provided by the IETF to ICANN for publication shall be available without restriction.  I’ll leave it to the lawyers to refine these words as needed.

The small detail I mentioned above is that I can imagine there may be specific instances where proprietary information is provided to the IANA team for the purpose of documenting the use of a particular parameter, and that information is not intended to be distributed publicly.  I haven’t checked with the IANA team to see if there are such instances.  In particular, I don’t know how much of the information in the PEN register is public.

I’m also aware that each specific collection of public information becomes a new and separate piece of intellectual property, so it would be possible, at least in principle, for ICANN — or any future IANA operator — to assert rights over the collection of information in a registry.  Speaking from the ICANN perspective, we will not do this and would have no problem with language added to the agreements that require us to agree not to put limitations on any collection we create as part of our IANA publication service.  (I’ve chosen my words a bit carefully here.  Suppose ICANN or an individual or another organization decided to publish this information in another form for a purpose not covered under the general concept of the “IANA publication service.”  An example might be a chapter in a book explaining how this all works.  That publication would likely have a copyright and may well require payment.  I would consider such publication as falling outside the agreement ICANN has entered into with the IETF to publish the protocol parameters for anyone to use without restriction.) 

In response to Bernard’s question about whether there is an implied task for the IAOC, I think this is up to the IETF to determine.  If the IETF wants to make more explicit and more robust the very long-standing rule that the information in the protocol parameter registries is in the public domain, it seems to me the right path is for the IAOC to initiate the incremental changes in the agreements with ICANN to do this.  This can be done at any time, including now; it need not be in synch with the transition decisions and actions.

For the benefit of those who are unfamiliar with my multiple contacts with this topic, I…

… created the RFCs and set the rule that they are available to anyone without cost (See RFC 3)

… helped form and served on the initial IAOC

… am currently chair of the ICANN Board of Directors.

Thanks,

Steve Crocker

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 13 Nov 2014 17:55:49 +0000

>recently in Busan, I believe - but Milton surely isn't one of them.

My mail did not say that Milton personally was trying to upend the
multistakeholder model. Among other things, that mail wasn't a response to
him and it didn't mention him. In fact, I seem to recall previously saying
in this thread to Milton directly that I believed he was acting in good
faith, even though I don't agree with the direction he endorses. I have
also said words to that effect at the IETF meeting going on right now.

But let me say it yet again, and directly - I think you're trying to help,
Milton. I really do. I'll also concede that "upend" is perhaps not a very
sharp term, and that the range of possibilities that "upending the
multistakeholder model" might encompass includes things I don't hear
people saying on this list.

That said, Milton, please don't take umbrage at perceived slights as a pat
justification to dismiss positions that have been explained and motivated
in some detail, and which clearly have substantial support on this list.
My views are not motivated by anything other than my experience working in
the IETF and my assessment of its realistic needs going forward.

Jon Peterson
Neustar, Inc.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 13 Nov 2014 08:11:49 -1000

Hi Richard,

...

> in the future, if needed and as the case may be.

This is almost exactly what the text says, in fact. The plan for the transition is not to change anything. The justification given is:

"Over the years since the creation of ICANN, the IETF, ICANN, and IAB have together created a system of agreements, policies, and oversight mechanisms that covers what is needed.

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 existing agreements are further elaborated in the earlier sections of the document. So the elements requested by the ICG are all there.

From my perspective, the portion of the response provided to address RFP Section III could have ended after the second paragraph quoted above. But participants in this WG felt that further specification about the IETF community’s preferences for the future could also be usefully included. These are not a plan, I agree with you. They are provided as additional information about the community’s preferences. They didn’t have to be included in the document, but they don’t hurt either, and their inclusion is helping us to arrive at what seems like rough consensus within the WG.

> Needless to say, I don't agree with that.

Indeed, I think the substantive differences between your position and the text are clear. To my eye you seem to be in the rough, but hopefully very soon the chairs will make a consensus determination.

> explicitly to what the ICG requested.

As explained above, the existing text already does this.

Alissa

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Nov 2014 10:24:24 -0800

> With respect to making it clear that data in the protocol parameter registries is in the public domain,

I have a 'technical' question, for whoever can answer it:

     For many/most/all of these registries, the IETF intends to retain
chainge control over the contents.  This does not match my understanding
of the term of art "public domain".

     Do we really mean public domain or something else that suits our
action model of control?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Nov 2014 14:14:32 -0500

--On Thursday, November 13, 2014 12:55 -0500 Steve Crocker
<[email-masked]> wrote:

>...
> The small detail I mentioned above is that I can imagine there
> may be specific instances where proprietary information is
> provided to the IANA team for the purpose of documenting the
> use of a particular parameter, and that information is not
> intended to be distributed publicly.  I haven't checked with
> the IANA team to see if there are such instances.  In
> particular, I don't know how much of the information in the
> PEN register is public.

Once upon a time, IANA was willing to take certain types of
registration requests privately and even to sign non-disclosure
agreements about the requests.   One particular example of that
involved port number requests that, if described in sufficient
detail to satisfy IANA about what was being proposed and then
disclosed  would have constituted premature product
announcements.    I gather that practice stopped (perhaps not
all at once) after the ICANN transition and increased IESG
supervision of registry allocations and contents.   It is
possible that some of the relevant NDAs might still be in effect
and would prevent _any_ publication of the relevant material
although they are probably now old enough for few people to
actually care about that material.

best,
    john

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 2014 10:10:43 +1300

>      Do we really mean public domain or something else that suits our

IANAL, and YANAL either afaik... but I have been told by lawyers in
the past that "in the public domain" is not very well defined, legally.
That's why, for example, the IETF-ICANN MOU speaks of "available to the
public, on-line and free of charge" (which avoids the issue of change
control and derivative works, intentionally).

   Brian

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 13 Nov 2014 21:44:46 +0000

Jon:
A gracious response, thanks. And thanks to Brian for prompting it.
While your message did not mention me by name it did imply that people who were arguing for a specific position were attempting to "upend the model." 

Let me respond to some of Klensin's responses below, which I found very interesting and useful:   

> First, I think it would have been desirable and appropriate for the various
> domain names and other marks and trappings to have been transferred to
> the IAB, or perhaps ISOC as trustee for the IAB, back when IANA was moved 
> out of ISI.   I said so at the time.

Thanks for acknowledging that. I suspect your thinking at that time was very similar to my rationale for insisting on it now. 

> As I have explained in a different context, when I look at the present
> situation in terms of threat models rather than theoretical concerns in the
> best of all possible worlds, I don't worry very much about a lot of the
> trappings of either an ICANN-operated IANA function or a smooth and
> relatively friendly transfer of the entire IANA function to another body.  In

I am not concerned about a friendly transfer either. But if IETF controls the domain and trademark now the likelihood of a cooperative transition is stronger. If a customer who wants to leave a provider feels locked in, and change is linked to a bunch of cumulative annoyances unrelated to the actual service, the parting of ways is more likely to be unfriendly.

> Conversely, I believe that any truly
> hostile situation, including massive and uncorrected malfeasance on ICANN's
> part, would almost certainly result in splitting up the IANA function,
> separating  at least the address and protocol functions (including the ARPA
> TLD) from the root zone (TLD) allocation and management functions.

On the contrary, "massive and uncorrected malfeasance" by ICANN would make it easy for all 3 communities to coordinate a transition, wouldn't it? So I find this premise faulty. 
(Unless you believe that the names community would be responsible for and in favor of the malfeasance ;-)  which, knowing you John, may be the case. But I will make you come out and say it!) 

> If the community is required to untangle the three collections of services,
> that process will be painful and disruptive regardless of what the resulting
> components are called and who controls them.  In particular, who "owns"
> the domain and/or various trademarks or service marks is unlikely to cause
> more than minor annoyance, if that, in the grand scheme of such a
> transition.  Yes, I've thought a lot about that set of contingencies but they just
> don't seem to have much to do with the present NTIA transition.

So your argument hinges on the premise that any attempt to shift the IANA functions out of ICANN would be so disruptive as to render the issue we are debating here either moot, or trivial? It seems to me then that you are indeed locked in, and this calls into question your claims that RFC 2820 already gives you the ability to opt out. That concerns me. That is really _all_ that concerns me: I don't want any operational community to be locked in. Really, that is all I care about. Convince me that you're not and I will acquiesce. 

> Trust) hands?  Yes.  But, for the reasons above, I don't consider it important
> enough to justify complicating this document, especially since it would then
> require sorting through a series of other contingencies such as what would
> occur if the IETF community decided to organize one group or the other out
> of existence.   

That, frankly, seems like a really minor issue, trivial to solve when needed in the future. 

Sorry to keep this going. I just still think there are holes in the logic and that the differences still matter. 

--MM

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Nov 2014 13:29:28 -1000

Hi Dave,

>      Do we really mean public domain or something else that suits our

We want to retain the ability to express  what OUR view of the world is,
such that there is no confusion on that point.  We haven't sought
control over the ability of others to reproduce the parameters, nor do I
think it a good path to go down.

Eliot

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 14 Nov 2014 16:43:45 +0100

Dear Alissa,

Thank you for this and please see embedded comments below.

Best,
Richard

> From: Alissa Cooper [mailto:[email-masked]]
> Sent: jeudi, 13. novembre 2014 19:12
> To: [email-masked]
> Cc: Eliot Lear; [email-masked]
> This is almost exactly what the text says, in fact. The plan for
> the transition is not to change anything.
>
>The justification given is:
>
> "Over the years since the creation of ICANN, the IETF, ICANN, and
> IAB have together created a system of agreements, policies, and
> 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 existing agreements are further elaborated in the earlier
> sections of the document. So the elements requested by the ICG
> are all there.
>
> From my perspective, the portion of the response provided to
> address RFP Section III could have ended after the second
> paragraph quoted above. But participants in this WG felt that
> further specification about the IETF community’s preferences for
> the future could also be usefully included. These are not a plan,
> I agree with you. They are provided as additional information
> about the community’s preferences. They didn’t have to be
> included in the document, but they don’t hurt either, and their
> inclusion is helping us to arrive at what seems like rough
> consensus within the WG.

Version "02" identified three types of issues: intellectual property rights,
additional dispute resolution, and contingencies to transition to another
operator.  And it addressed those issues by specifying a plan to deal with
them.

The text that now has considerable support does not materially address the
issues.  As you state above, that new text is based on the view that the
previously identified issues need not be addressed at this time, they can be
addressed later, if they come up.

According to section 6 of RFC 7282, consensus (including rough consensus) is
reached only when issues have been addressed.

I don't consider that an issue has been addressed if it is left open for the
future.

That is, if X is an issue, then saying "we will address that later" when
there is an alternative that allows addressing it now cannot, in my view, be
considered to constitute "we have addressed the issue".

Saying X is not an issue does constitute addressing the issue.  But, as far
as I can tell, most of what has been said on this list is not that the items
in question are not issues, it is that they are not issues that should be
dealt with now.

So, in my view, the issues have not been addressed.

SNIP

>
> I think the substantive differences between your position
> and the text are clear. To my eye you seem to be in the rough,
> but hopefully very soon the chairs will make a consensus determination.

As noted above, I don't think that this would be consistent with RFC 7282,
but maybe I do not understand that RFC properly.

> parameters
> parameters

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Nov 2014 15:50:36 +0000

> reached only when issues have been addressed.

For rough consensus "addressed" can be satisfied by "no need to do that
now, we can look at it later." See section 3 of 7282. [1] I'm sure the
ianaplan chairs will take that properly into account when evaluating
what they see as the rough consensus.

S.

[1] https://tools.ietf.org/html/rfc7282#section-3

---

From: John Curran <[email-masked]>
Date: Fri, 14 Nov 2014 07:20:28 -1000

On Nov 12, 2014, at 11:33 PM, Richard Hill <[email-masked]> wrote:
> agreements. The WG will identify, but not create, such required agreements."
> 

The charter calls for planning activities that identifies the mechanisms 
_required_ to address the removal of the overarching NTIA contract.

The IETF consensus position appears to be that the existing mechanisms 
(RFC 2860 & RFC 6220) are entirely sufficient arrangements for that 
purpose, thus the plan is to rely upon those mechanisms to address the 
removal of the overarching NTIA contract.

The _required_ mechanisms to appear to covered in the suggested text,
even if the suggested text then continues with IETF preferences that
may be helpful to consider in the transition but (in the WG's view) not 
strictly required and thus not necessary to fully plan for at this time.

I see no discrepancy between the proposed text and the WG charter.

> Section II.B, the rationale and justification for that choice should be

While the proposed ICG response as a whole does provide this reasoning (e.g. 
"RFC 2860 remains in force and has served the IETF community very well. RFC 
6220 has laid out an appropriate service description and requirements.”), 
I do believe that there is some reasoning which may be hard to discern by 
readers who are only familiar with the NTIA IANA functions contract and 
not the details of today's IETF/ICANN IANA arrangements.  In particular, 
the WG outcome position of the IETF (that the present NTIA IANA functions 
contract does not have an operational bearing on performance of these 
functions today and hence expects no change if that contract were to be 
eliminated) does not appear to be plainly stated in the present text.

/John

Disclaimer: my views alone.

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 14 Nov 2014 18:36:08 +0100

> From: Ianaplan [mailto:[email-masked]]On Behalf Of John
> Curran
> Sent: vendredi, 14. novembre 2014 18:20
> To: [email-masked]
> Cc: [email-masked]; Alissa Cooper; Eliot Lear

SNIP

> removal of the overarching NTIA contract.

This implies that the three issues identified in "02", namely intellectual
property rights, additional dispute resolution, and contingencies to
transition to another operator, are not actually issues that need to be
addressed, because, unless I am mistaken, the existing mechanisms do not
address those issues.

SNIP

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Nov 2014 12:49:07 -0500

On Fri, Nov 14, 2014 at 06:36:08PM +0100, Richard Hill wrote:
> addressed

I certainly agree with that statement, at least in the sense of
"issues" and "need to to be addressed" that some seem to have
understood.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Burger <[email-masked]>
Date: Fri, 14 Nov 2014 11:00:20 -0800

I would offer there is an important distinction between needing copyright on the RFC’s (change control) and the protocol parameters registry (distribution control). Unless we are worried about the brand as the source of authority (I’m thinking of why the LERG is copyrighted), all a copyright on the registry would do is confuse people.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 14 Nov 2014 10:29:00 -1000

> what they see as the rough consensus.
​Note also that RFC 7282 is an informational document that explores the
space; it is not a BCP that describes a required procedure.  As the
document notes:

   The point of this document is to get all of us to
   think about how we are coming to decisions in the IETF so that we
   avoid the dangers of "majority rule" and actually get to rough
   consensus decisions with the best technical outcomes.

​It and RFC 2026 try to reinforce that consensus-building is a process, and that
judging consensus is not mechanical.  Certainly the existence of an issue which
has been explicitly discussed and deferred does not require the chairs to
defer a judgement of consensus.

regards,

Ted

---

From: Seth Johnson <[email-masked]>
Date: Fri, 14 Nov 2014 15:43:58 -0500

Their relevance here is in abstract terms -- in terms of whether
there's anything about the transition to an international context
without a connection to a US national agency that needs to be
acknowledged or addressed, pertaining to those issues (or any issue in
this discussion).  It can be stated more generally than these
particular issues, though some of them represent interesting examples.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 14 Nov 2014 15:56:25 -0500

On Fri, Nov 14, 2014 at 03:43:58PM -0500, Seth Johnson wrote:
> this discussion). 

I think the current draft does in fact acknowledge the related issues,
and we have uncovered the way to cope with the issues.  

On dispute resololution, it turns out the MoU already says that
disputes are resolved by the IAB.  This may be surprising to some, but
if IANA is ok with it (and apparently they are), why should we chase
that more?

On the IPR issues, the IETF's preferences are communicated in the
newest text on this matter, without overtly constraining the IAOC's
freedom of movement.

Some seem to want very specific words in the draft.  My impression is
that the WG on the whole has rejected that approach.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Burger <[email-masked]>
Date: Fri, 14 Nov 2014 11:44:51 -1000

A lawyer needs to validate the IAB being the venue for arbitration is binding. Some venues always allow legal proceedings, even if waived in a contract. Others allow waiver, but only to binding arbitration. We may be able to say the IAB counts as binding arbitration, but that is a call for a lawyer to make.

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 14 Nov 2014 22:53:12 +0100

Although I'm not a lawyer, I do know a bit about arbitration, and I doubt
that the clause "In the event of technical dispute between the IANA and the
IESG, both will seek guidance from the IAB whose decision shall be final"
would be considered to be a valid arbitration clause, if by arbitration
clause you mean a clause that is inserted in a contract in order to specify
a jurisdiction other than a national court.

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Eric
> Burger
> Sent: vendredi, 14. novembre 2014 22:45
> To: [email-masked]
> A lawyer needs to validate the IAB being the venue for
> arbitration is binding. Some venues always allow legal
> proceedings, even if waived in a contract. Others allow waiver,
> but only to binding arbitration. We may be able to say the IAB
> counts as binding arbitration, but that is a call for a lawyer to make.
>

---

From: Seth Johnson <[email-masked]>
Date: Fri, 14 Nov 2014 16:56:11 -0500

Their relevance here is in abstract terms -- in terms of whether
there's anything about the transition to an international context
without a connection to a US national agency that needs to be
acknowledged or addressed [SNIP]. It can be stated more generally than
these particular issues, though some of them represent interesting
examples.

You simply reiterated the same issues.  I understand that addressing
what we're trying to do here this way is worrisome to many.

Seth

---

From: John C Klensin <[email-masked]>
Date: Fri, 14 Nov 2014 18:21:01 -0500

--On Thursday, November 13, 2014 21:44 +0000 Milton L Mueller
<[email-masked]> wrote:

>> First, I think it would have been desirable and appropriate
>> for the various domain names and other marks and trappings to
>> have been transferred to the IAB, or perhaps ISOC as trustee
>> for the IAB, back when IANA was moved  out of ISI.   I said
>> so at the time.
> 
> Thanks for acknowledging that. I suspect your thinking at that
> time was very similar to my rationale for insisting on it now. 

Don't know.  When I was pushing for that, Jon Postel was still
alive, we were all assuming he would be adding "ICANN CTO" as a
part-time activity, no one, at least no one I was aware of, was
talking about splitting the IANA function up or even designing a
web page that created three category-groups of registries, etc.
I don't think it was even clear that we would soon create a
clear boundary between the IANA and RFC Editor functions even
though they had been staffed somewhat differently for years.  I
just thought the transfer of the DNS zone would be a lot more
orderly if it was associated with the IAB rather than an ICANN
whose long-term future seem a bit less certain.  Interestingly,
at least one of the reasons the transfer to the IAB wasn't done
was very similar to one of the arguments today: it just didn't
seem important enough to spend a lot of energy on.

>> As I have explained in a different context, when I look at
>> the present situation in terms of threat models rather than
>> theoretical concerns in the best of all possible worlds, I
>> don't worry very much about a lot of the trappings of either
>> an ICANN-operated IANA function or a smooth and relatively
>> friendly transfer of the entire IANA function to another
>> body.  In
> 
> I am not concerned about a friendly transfer either. But if
> IETF controls the domain and trademark now the likelihood of a
> cooperative transition is stronger. If a customer who wants to
> leave a provider feels locked in, and change is linked to a
> bunch of cumulative annoyances unrelated to the actual
> service, the parting of ways is more likely to be unfriendly.

Same reasoning, different conclusion for at least three reasons:

(i) One could equally well argue that, if the "customers" feel
locked in, regardless of what mechanisms do the locking, it is
less likely that any change or transition will occur at all
unless things get bad enough that other alternatives do not seem
plausible.  If things get that bad, the divorce (and transition)
are likely to be unfriendly regardless of what happens to the
domain name and trademark(s), etc.  One can rather easily argue
either for or against that: trying to ensure that there are
strong disincentives to non-cooperative or unilateral actions
unless all other approaches fail could be a good thing.

(ii) Given the hypothesis that any unfriendly change of
arrangements is likely to be accompanied by splitting the IANA
function up into two or more parts that are administered and
overseen separately, arguments about who should hold the domain
name and/or trademark are ultimately making assumptions about
who, if things become difficult, will act (and can be trusted to
act) in the best interests of the Internet rather than favoring
something more parochial.   I'd like to believe the IETF is the
most likely of the various entities on this scene to do that,
but if one projects far enough into the future, I realize that
there is real no basis for believing that other than hope.
While examples have been rare, certainly we've seen enough IETF
WGs and other bodies try to use protocol parameter registries to
control selections of technology and apply "not invented here"
principles to be completely confident that the IETF is incapable
of exhibiting bad behavior.  I also assume that others on this
list could make a case that the appropriate entity would be ISOC
and/or the NRO or perhaps even the Internet Governance Forum or
ITU, turning a discussion about whether the document should be
more specific about this into one about who should do it, a
topic one which I assume reaching consensus would be difficult.

(iii) The IETF has a great many documents, including many RFCs
that go back years and cannot be revised in place, that
reference IANA registries.  I assume that the address and domain
communities have at least some, even though most of their
documents may be more easily revised and updated.  If changing
the structure of the IANA while holding those references
constant by simply redelegating operational control of the
IANA.ORG domain, I'd be a lot more concerned about nailing down
ownership/ control of that domain.  But the reality is that, to
make the references stable while depending on the domain name,
we'd have to pin down the way the registries are organized and,
unless this process created a super-IANA that would be
guaranteed to control names and structure even if authority and
management for groups of registries was distributed.  I think
there is actually a pretty strong case to be made for that, but
I haven't seen anyone proposing it and doubt that the community
could sort out the right operational details while meeting the
current schedule and deadlines.    Absent that, the IANA
customers would either have to spend a lot of energy telling
people where the registries are "really" located --effort that
would go well beyond  questions about who owns IANA.ORG or
encouraging people to find ways to locate those registries that
are not dependent on the domain name at all.

At the risk of making a constructive suggestion rather than just
arguing that this topic is less important than appears at first
glance, if the various IANA "customers" were significantly
concerned about this issue or wanted to be extra-careful about
contingency plans, they should be working with ICANN to
restructure the naming arrangements at IANA.ORG so that the
three pieces referenced from the www.iana.org home page became
subdomains that could be referenced separately, e.g., as
http://protocols.iana.org and http://addresses.iana.org rather
than http://www.iana.org/protocols, etc.  If the "customers"
agreed that they wanted it, I would expect ICANN to respond to
that idea with enthusiasm: it doesn't weaken their position in
any way as long as they are perceived as doing a good job and it
would constitute a show of good faith wrt the community in
general.    That change would turn the operational stability
question from some variation on "who owns the name and how is
ownership handled long-term" to "anyone who owns the name has to
make guarantees about delegation of subdomains should the
'customers' conclude that is necessary".  I contend it would be
lots easier to get consensus about the latter, in part because
it doesn't involve nearly as much "ownership" clutter.

>> hostile situation, including massive and uncorrected
>> malfeasance on ICANN's part, would almost certainly result in
>> splitting up the IANA function, separating  at least the
>> address and protocol functions (including the ARPA TLD) from
>> the root zone (TLD) allocation and management functions.
> 
> On the contrary, "massive and uncorrected malfeasance" by
> ICANN would make it easy for all 3 communities to coordinate a
> transition, wouldn't it? 

Yes, unless that massive malfeasance were connected with
treating some communities better than others.  Unless ICANN were
overcome by some inclination toward evil independent of either
the best interests of the Internet or its own, I have trouble
imagining either a motivation for malfeasance or accidents that
could lead to it without willingness or ability to correct that
would not have that sort of differential effect.    We are
getting very far off into speculation here, but my guesses about
plausible sources of malfeasance are mostly connected with ICANN
falling onto hard times (or having sufficiently many other
priorities) sufficient to cause concerns (and possibly bad
decisions) about supporting some sets of registries in the style
to which their users or registrants have become accustomed.

The sort of "screw IANA" decisions that would push the three
communities together to find a new plan would require that ICANN
make decisions against the presumed wishes of at least one of
those communities that is rather well represented there (at the
other extreme, remember that all of the IETF/IAB representation
and even DNS root-level operational community representation is
non-voting).

> So I find this premise faulty. 

The premise would be faulty if one assumed, as you apparently
do, that any pattern of significant malfeasance would push the
three communities together to find a new organizational
structure.  For the reasons above, I find that situation
implausible and believe that, were a disaster to occur, it would
be much more likely to put some of those communities against
others in the struggle for resources.

> (Unless you believe that the names community would be
> responsible for and in favor of the malfeasance ;-)  which,
> knowing you John, may be the case. But I will make you come
> out and say it!) 

No, I don', actually.   However, I believe that, if ICANN were
to suffer a financial collapse --either through a collapse of
the names market or through seriously overextending itself-- the
names community would be in a better position to defend its
interests (as the source of most of the money, if nothing else)
than the protocol or address communities.    I would not expect
them to act against their best interests, especially given
repeated indications that many of the participants in that
community are barely aware of the existence of the other
communities and their importance to the Internet.

>> If the community is required to untangle the three
>> collections of services, that process will be painful and
>> disruptive regardless of what the resulting components are
>> called and who controls them.  In particular, who "owns" the
>> domain and/or various trademarks or service marks is unlikely
>> to cause more than minor annoyance, if that, in the grand
>> scheme of such a transition.  Yes, I've thought a lot about
>> that set of contingencies but they just don't seem to have
>> much to do with the present NTIA transition.
> 
> So your argument hinges on the premise that any attempt to
> shift the IANA functions out of ICANN would be so disruptive
> as to render the issue we are debating here either moot, or
> trivial? 

Essentially, yes.

> It seems to me then that you are indeed locked in,
> and this calls into question your claims that RFC 2820 already
> gives you the ability to opt out.

For the record, I have not personallly made that claim about
either 2820 or 2860, which I assume is what you intended to
reference.   I do believe that the IETF community has the right
and ability to, using your words, opt out (with an amount of
pain only somewhat disproportionate to the seriousness of the
decision) either completely or incrementally, but that the
ability to do so is not dependent on 2860 or any other agreement
with ICANN.  Instead, it depends on the observation that the
decision of where registries are located is essentially made one
protocol at a time.  IANA is, for many reasons, the obvious
default, but it is only a default.  Other choices are possible,
have occasionally been made, and, at least in principle, could
be made or changed for any existing protocol by a relatively
simple action if there were community consensus for doing it.

> That concerns me. That is
> really _all_ that concerns me: I don't want any operational
> community to be locked in. Really, that is all I care about.
> Convince me that you're not and I will acquiesce. 

I don't think any community is locked in and that the IETF is
the least locked in of all.  The RIRs might have been locked in
as long as IANA was the source of address blocks, but the
dependency is small and more of the community depends on the
interlocking set of RIR-level address registry databases than on
the IANA database itself.  It is possible to argue that the
names community is locked in as a consequence of the
relationship between root delegations and the root zone, but
that is a much more complex set of relationships than the
protocol registries.  Again, migration would be a major pain in
the anatomy and would be even worse if the IANA function were
disassembled in the process, but there is not real lock-in and,
to the extent to which the setup makes it harder for any of the
"customers", and especially the IETF, to migrate out, the domain
name and the "IANA" terminology, are very far down on the list
of problems or impediments.

That, of course, assumes that "ownership" of IANA.ORG and/or any
trademarks would withstand a serious challenge from the
community if the arrangements were to change.  ICANN has a
formidable array of legal resources, but, if the community were
to make a major effort to claim the the "IANA" term was a
generic one that belonged to the Internet community as a whole
rather than one particular operator, especially one that was not
a US Government designee operating under US Government
supervision, my ability to forecast the future isn't nearly good
enough to guess how that would come out.

>> Would I prefer that the domain and marks end up in IAB (or
>> IETF Trust) hands?  Yes.  But, for the reasons above, I don't
>> document, especially since it would then require sorting
>> through a series of other contingencies such as what would
>> occur if the IETF community decided to organize one group or
>> the other out of existence.   
> 

Interesting.  I've been through several situations in which
organizations either put themselves out of business and had to
sort or successor relationships (often after the fact).
Changes of the names of things are, in my experience, much
easier that changing the things themselves.  Indeed, one
colleague drew an analogy at one stage to the difference between
a human changing his or her name and undergoing a brain and/or
personality transplant.  One is fairly easy although often
confusing, the other rarely works well.

best,
    john

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 14 Nov 2014 13:29:05 -1000

> that the WG on the whole has rejected that approach.

[BA] Indeed, the suggested wording is about as specific as it can be while simultaneously respecting the IAOC's responsibility under RFC 6220. In essence, our charge is to provide the IAOC with requirements; the responsibility for delivering a solution is theirs.

---

From: Seth Johnson <[email-masked]>
Date: Fri, 14 Nov 2014 19:22:40 -0500

> [BA] Indeed, the suggested wording is about as specific as it can be while simultaneously respecting the IAOC's responsibility under RFC 6220. In essence, our charge is to provide the IAOC with req…

I agree.  The group's charter is to say what the necessary/expected
conditions of the transition are, while details are to be developed by
IAOC rather than specified by the group.  The conditions could be
detailed, but only inasmuch as they are requirements.

At the same time, I don't believe the nature of the transition really
requires detail, just a frank recognition that the transition is
significant and how.  One might enumerate areas that would be affected
to illustrate the nature of the transition, but the basic task is to
identify and acknowledge what is actually changing, what effects it
has and what we think is required given those facts.

Seth

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Nov 2014 16:15:33 +1300

> A lawyer needs to validate the IAB being the venue for arbitration is binding. Some venues always allow legal proceedings, even if waived in a contract. Others allow waiver, but only to binding arb…

Once again, with feeling: the MoU was heavily lawyered by counsel for both
the IETF and ICANN before Fred Baker, Mike Roberts, and I signed it in 2000.

I mean, seriously, would we have signed such a document without legal advice?
(And, at least in my case, checking that ISOC's liability insurance
covered me.)

   Brian

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 14 Nov 2014 23:01:55 -0500

> [BA] Indeed, the suggested wording is about as specific as it can be while simultaneously respecting the IAOC's responsibility under RFC 6220. In essence, our charge is to provide the IAOC with req…

Does this imply an expectation that the IAOC will review and revise the 
WG document before submitting it to the ICG?  It is, ultimately, a 
formal proposal - i.e., a legal document - not a protocol spec. we're 
talking about.

Miles Fidelman

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

---

From: Seth Johnson <[email-masked]>
Date: Sat, 15 Nov 2014 00:23:49 -0500

On Fri, Nov 14, 2014 at 7:22 PM, Seth Johnson <[email-masked]> wrote:
> I agree.

Actually, I only agree with your last sentence, not the previous, as
should be plain in what I said.  It could be more specific if we so
chose.  We can be specific in anything that we hold to be a
requirement.  That doesn't imply we have to say all the details of
how, just "these are the things it has to do."  That's how you provide
the necessary direction regarding what the transition has to cover.

> The group's charter is to say what the necessary/expected

---

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

> From: Ianaplan [mailto:[email-masked]]On Behalf Of John C
> Klensin
> Sent: samedi, 15. novembre 2014 00:21
> To: Milton L Mueller
> Cc: [email-masked]
SNIP
> it doesn't involve nearly as much "ownership" clutter.

In my opinion, that is a very constructive suggestion.  And it is exactly
the sort of thing that the IAOC could have suggested under version "02"
(with perhaps some tweaking of the language in "02" to make it less
prescriptive).

Whereas "03" implicitly calls for making no changes at this time.

But of course nothing prevents ICANN from making the changes suggested above
on its own.

SNIP

> enough to guess how that would come out.

In my view, such a claim might have been made in opposition to the trademark
filing, but it was not made.  So the trademark is valid and its grant cannot
be challenged now.

A term can become generic, and lose trademark protection, if it is widely
used to designate something that is provided by many companies (aspirin
being a well known example).  But that's not the case here.  The term "IANA"
is used exclusively to refer to what is provided by ICANN.  So I don't think
there is much chance of success in arguing that it is a generic term that
has lost its trademark protection.

Which leads me to think of something that I had not thought of earlier.
Absent any specific contractual committments, it seems to me that the ICANN
Board has a fiduciary duty to protect ICANN's intellectual property,
including its trademark.

So ICANN might well wish to take actions to prevent anybody else from using
its marks, if the IANA function were transferred elsewhere.

I think that we agree that this group is not chartered to explore complex
legal issues.

But it seems to me that this group should invite the competent body (IAOC)
to explore the issues and take appropriate action, if required.

The existing IANA functions contract does have language regarding
intellectual property rights (sections 1.9.4 and 1.9.5 of ICANN's Proposal,
which is incorporated by reference in the contract).

So it seems to me that competent experts (that is, lawyers) should evaluate
whether or not any additional agreements are needed after the existing
contract between NTIA and ICANN ceases to be in force.

So the output of this group should call for such an evaluation.  That's what
"02" did (albeit perhaps with language that was too prescriptive), but what
"03" does not do.

That is, "03" prejudges the outcome of a proper legal analysis, by
concluding that there is no need for anything to replace what is in the
current IANA functions contract.

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 15 Nov 2014 10:27:28 -0500

>>> [BA] Indeed, the suggested wording is about as specific as it can be while simultaneously respecting the IAOC's responsibility under RFC 6220. In essence, our charge is to provide the IAOC with r…

Maybe I'm starting to sound like a broken record here, but, let me try 
one more time:

I just spent some time reviewing all of the alphabet soup of acronyms 
and RFCs defining roles and responsibilities, and I keep coming back to 
the simple conclusions that:
1. Ultimately, the final document is a proposal (legal/contractual 
document, not protocol spec.),
2. From "the IETF" to the ICG and ultimately to NTIA.
3. "The IETF, IAB, IAOC, the IETF Trust, etc. are not separate legal 
entities.  Actually none of them are legal entities at all.
-- from a legal point of view, the IETF is a component of ISOC
-- the IAB, IAOC, etc. are administratively defined components of IETF 
(and hence of ISOC)
-- the IETF Trust, which everyone keeps talking about as if it's a 
separate corporate entity, is actually a contractual agreement
(from the founding document of the Trust)"THIS TRUST AGREEMENT (the 
"Agreement") is made as of the 15th day of December, 2005, by 
CORPORATION FOR NATIONAL RESEARCH INITIATIVES, a District of Columbia 
non-profit corporation ("CNRI"), INTERNET SOCIETY, a District of 
Columbia non-profit corporation ("ISOC"), as Settlors, the INTERNET 
ENGINEERING TASK FORCE ("IETF"), and the INITIAL TRUSTEES as defined 
herein, and amended on February 20, 2014 in accordance with the 
provisions of Section 10.1 hereof.
4. As far as the external world is concerned, for legal and contractual 
purposes, statements like "the IAB will decide" or "the IAOC will xxx" 
are equivalent to saying that "the IETF will xxx" with some details 
added as to the internal organization and procedures of the IETF.  
(E.g., If I bring a car back for warranty service, it's the dealership 
and the automaker that are legally responsible, and I really don't care 
about who the service manager reports to, or how the paperwork is 
handled.)  In the particular case of arbitration, between IETF and 
ICANN, "the IAB will decide" is essentially saying that "the IETF will 
decide" -- which is simply not the way the world works, one party to a 
dispute can not arbitrate that dispute.

So, yes, maybe the proposal to ICG has to "respect the IAOC's 
responsibility under RFC 6220," but....:
1.  the final document submitted to ICG has to be a single document, 
reflecting the the IETF-as-a-whole
2.  if there are issues that are in the IAB's and IAOC's purviews, they 
should be addressed in the final document sent to ICANN
---- the "IETF Proposal" that goes to the ICG should be complete, and 
reflect the considerations of all the components of IETF
------- a proposal that contains language like "the IAOC should address 
issues a, b, and c" is incomplete -- those issues should be addressed 
before a final proposal goes in
---- arguably, the document should be submitted by ISOC, since it's the 
only legal entity
---- the lawyers should really, really, have a look at the final 
proposal and adjust it as appropriate
3. the requirement for open/consensus process should apply to the 
complete proposal

Which all comes back to:
1. The working group majority view (NOT a consensus view) seems to be 
driving toward some combination:
-- punting legal and contractual issues to the IAOC
-- a Pollyannaish view that all will continue to work fine, there are no 
legal/contractual issues to address and/or we can deal with such issues 
in the future
-- very loose, subservient language ('if, in the event of a conflict, 
which of course will never happen, everyone will resolve the issues in 
good faith in zero time, with zero operational impact') -- as opposed to 
strong, clearly worded contractual terms that would empower the IAOC and 
the IETF to prevail quickly, if the relationship with ICANN were to go 
drastically wrong.  [I'm still confused as to why many of us don't see 
as much need for SHALL and MUST statements in contracts as in technical 
specifications, particularly in that the usage of these terms originates 
in the contractual world.]
2. If the WG is not going to deal with these issues, then how will they 
be dealt with, by whom, and by what process, and who's signature will 
actually be on the final proposal?  (I've yet to see a definitive answer 
to this.  For that matter, who actually gets to make this call?)

Miles Fidelman

---

From: Seth Johnson <[email-masked]>
Date: Sat, 15 Nov 2014 10:49:26 -0500

Nicely articulated.  I try to stress what the charter calls for to get
through, but your organizational treatment brings out things which in
my experience one has to work to gradually get a group of expert
"process owners" to start confronting.  One has to somehow convince
the culture you're not screwing with it before they'll fully examine
what's really going on -- and there is a lot at stake.

Seth

On Sat, Nov 15, 2014 at 10:27 AM, Miles Fidelman
<[email-masked]> wrote:
>>>> [BA] Indeed, the suggested wording is about as specific as it can be
>>>> while simultaneously respecting the IAOC's responsibility under RFC 6220. In
>>>> essence, our charge is to provide the IAOC with requirements; the
>>>> responsibility for delivering a solution is theirs.
>>>
>>>
>
> Maybe I'm starting to sound like a broken record here, but, let me try one
> more time:
>
> I just spent some time reviewing all of the alphabet soup of acronyms and
> RFCs defining roles and responsibilities, and I keep coming back to the
> simple conclusions that:
> 1. Ultimately, the final document is a proposal (legal/contractual document,
> not protocol spec.),
> -- the IAB, IAOC, etc. are administratively defined components of IETF (and
> hence of ISOC)
> -- the IETF Trust, which everyone keeps talking about as if it's a separate
> corporate entity, is actually a contractual agreement
> "Agreement") is made as of the 15th day of December, 2005, by CORPORATION
> FOR NATIONAL RESEARCH INITIATIVES, a District of Columbia non-profit
> corporation ("CNRI"), INTERNET SOCIETY, a District of Columbia non-profit
> corporation ("ISOC"), as Settlors, the INTERNET ENGINEERING TASK FORCE
> ("IETF"), and the INITIAL TRUSTEES as defined herein, and amended on
> February 20, 2014 in accordance with the provisions of Section 10.1 hereof.
> purposes, statements like "the IAB will decide" or "the IAOC will xxx" are
> equivalent to saying that "the IETF will xxx" with some details added as to
> the internal organization and procedures of the IETF.  (E.g., If I bring a
> car back for warranty service, it's the dealership and the automaker that
> are legally responsible, and I really don't care about who the service
> manager reports to, or how the paperwork is handled.)  In the particular
> case of arbitration, between IETF and ICANN, "the IAB will decide" is
> essentially saying that "the IETF will decide" -- which is simply not the
> way the world works, one party to a dispute can not arbitrate that dispute.
>
>
> So, yes, maybe the proposal to ICG has to "respect the IAOC's responsibility
> under RFC 6220," but....:
> issues a, b, and c" is incomplete -- those issues should be addressed before
> a final proposal goes in
> ---- arguably, the document should be submitted by ISOC, since it's the only
> legal entity
> ---- the lawyers should really, really, have a look at the final proposal
> and adjust it as appropriate
> 3. the requirement for open/consensus process should apply to the complete
> proposal
>
> Which all comes back to:
> legal/contractual issues to address and/or we can deal with such issues in
> the future
> -- very loose, subservient language ('if, in the event of a conflict, which
> of course will never happen, everyone will resolve the issues in good faith
> in zero time, with zero operational impact') -- as opposed to strong,
> clearly worded contractual terms that would empower the IAOC and the IETF to
> prevail quickly, if the relationship with ICANN were to go drastically
> wrong.  [I'm still confused as to why many of us don't see as much need for
> SHALL and MUST statements in contracts as in technical specifications,
> particularly in that the usage of these terms originates in the contractual
> world.]
> 2. If the WG is not going to deal with these issues, then how will they be
> dealt with, by whom, and by what process, and who's signature will actually
> be on the final proposal?  (I've yet to see a definitive answer to this.
> For that matter, who actually gets to make this call?)
>
> Miles Fidelman
>
> --

---

From: John C Klensin <[email-masked]>
Date: Sat, 15 Nov 2014 11:13:29 -0500

--On Saturday, November 15, 2014 15:32 +0100 Richard Hill
<[email-masked]> wrote:

>...
>...
>> if the various IANA "customers" were
>> significantly concerned about this issue or wanted to be
>> extra-careful about contingency plans, they should be working
>> with ICANN to restructure the naming arrangements at IANA.ORG
>> so that the three pieces referenced from the www.iana.org
>> home page became subdomains that could be referenced
>> separately, e.g., as http://protocols.iana.org and
>> http://addresses.iana.org rather than
>> http://www.iana.org/protocols, etc.  If the "customers"
>> any way as long as they are perceived as doing a good job and
>> it would constitute a show of good faith wrt the community in
>> ownership handled long-term" to "anyone who owns the name has
>> to make guarantees about delegation of subdomains should the
>> 'customers' conclude that is necessary".  I contend it would
>> be lots easier to get consensus about the latter, in part
>> because it doesn't involve nearly as much "ownership" clutter.

> In my opinion, that is a very constructive suggestion.  And it
> is exactly the sort of thing that the IAOC could have
> suggested under version "02" (with perhaps some tweaking of
> the language in "02" to make it less prescriptive).

Richard,

Thanks for the kind words, but let me try to make what is, to
me, an important distinction (one that others have been trying
to make as well, but perhaps using this as an example would make
it more clear)...

There are. IMO, two possible way to approach what is going on
now and, in particular, what this WG is chartered to discuss and
should be discussing.  One is to focus on the specific issues,
new agreements, and changes required to respond to NTIA's
questions about changes in US Government oversight.  That is the
course the IETF has chosen.  It may be the only choice that
makes sense given factors that include a very tight schedule, a
necessarily complex multi-step and multi-headed process, and the
NTIA instructions themselves.  The other, in its most extreme
form, would to view the NTIA question as an opportunity to
completely rethink the IANA model and the relationships
associated with it.   The latter is extremely tempting and,
because it is tempting, there is an inevitable temptation to try
to make it part of this effort, sort out all the details, and
incorporate them into this document.

While, in retrospect, I wish some of these future-proofing
changes had been discussed, designed, and made a decade ago, I
have to agree with those who want to keep those "change IANA"
discussions out of this document.  There just isn't time,
especially given the tendency, perhaps necessity given the
schedule, to try to do in-depth editorial work by committee.

> But of course nothing prevents ICANN from making the changes
> suggested above on its own.

Not quite "nothing".   Those changes, if not managed with
extreme care, would do quite as good a job of invalidating links
that point into http://www.iana.org/protocols,
http://www.iana.org/numbers, http://www.iana.org/some-registry,
http://www.iana.org/domains/idn-tables, etc., as dropping the
"iana.org" entirely and moving to, e.g., iana-protocols.org,
iana-domains.org, etc.  So it would be irresponsible (and
probably prohibited by existing agreements) for ICANN to make
those changes on its own.  Instead, even if redirects or aliases
were used to preserve superficial stability, it would require
considerable consultation, transition planning (including being
sure that things were done with timing and in an order that
would prevent DNS properties like slow synchronization from
causing issues), decisions about when to advertise which address
forms in various documents, and so on.  As a less-technical
example, I would expect that the domain names community would
want to have some very careful conversations about whether a
"domains" subdomain would be appropriate or whether, e.g.,
ccTLDs and gTLDs should be handled separately or other
distinctions made.  I don't think the IETF has much to
contribute to those decisions but assume there are likely to be
enough issues involved that the decisions could not be made
quickly and in an open, transparent, and consultative way.    

In any event, if there were agreement that we should move in
that general, I'd like to see a carefully-worked-out plan
presented to the community for review and approval, but I'd hate
to see the community (or even a large and diverse WG like this
one) try to develop that plan.

If others agree, I think it would be entirely reasonable for
this WG to recommend that the IAOC and IAB work with ICANN and
the other "customer" communities to improve IANA's robustness
relative to possible future changes in structure, taking some of
this discussion as a starting point.  I hope the IETF has not
become so procedurally-ossified to make such a recommendation a
heavy-duty process.   In particular, I believe the IAOC has more
than enough authority to initiate such a study on its own
initiative, saying "good idea, we will follow up" to the WG.
But it seems to me that getting this entangled with the current
document by trying to add precisely-appropriate text would be
unwise at best.

I'm not going to comment on your trademark concerns except to
say that, as many participants in this list know, I've gotten
both cynical and paranoid about possible bad consequences to the
Internet when ICANN starts making or justifying decisions on the
basis of ICANN's best present or future interests rather than
the best interests of the Internet.   I'm not particularly
worried about the particular issue of the IANA name because my
experience and observations lead me to believe that domain names
and related marks are a lot less important than those who are
immersed in DNS and names-market issues tend to assume.   If,
tomorrow, we decided to start calling the protocol registry
collection collection "Jon" in Postel's honor or "Richard" in
yours, we'd go through some months of confusion and disruption,
but we would all get over it.  At least absent considerable
external pressure, it would almost certainly take longer for the
community to agree on a new name than it would to make the
transition at the 80% level or better.

More generally and at least in retrospect, I think the community
would be better off if ICANN had strict charter provisions
requiring that it close up and dispose of its assets if ever
faced a choice between its perceived best interests and those of
the Internet.   ICANN is not unique in that regard: I have the
same preference about some other institutions with which you
and/or I have been associated.    I have no idea how such a
provision could be written, interpreted, or enforced in any
practical way, but you get the idea.   Incidentally, I think the
last 15 or so years strongly suggest that, for the ICANN case,
NTIA involvement and oversight isn't part of the solution and so
those concerns aren't appropriately part of this discussion
either (they might be part of the ICANN accountability one... or
not).

best,
    john

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 15 Nov 2014 17:20:07 +0100

> Sent: samedi, 15. novembre 2014 17:13
> To: [email-masked]
> Cc: Milton L Mueller; [email-masked]
> course the IETF has chosen.

Let's agree to disagree, because, from my point of view, the IETF is not
focussing on all the relevant issues.

> this discussion as a starting point.

That's what I thought that "02" did.  Maybe some adjustments to the language
of "02" would have been in order, but, in my view, "03" has changed
direction totally, essentially ruling out what you outline above.

SNIP

---

From: John C Klensin <[email-masked]>
Date: Sat, 15 Nov 2014 11:33:36 -0500

--On Saturday, November 15, 2014 17:20 +0100 Richard Hill
<[email-masked]> wrote:

>> relative to possible future changes in structure, taking some
>> of this discussion as a starting point.
> 
> That's what I thought that "02" did.  Maybe some adjustments
> to the language of "02" would have been in order, but, in my
> view, "03" has changed direction totally, essentially ruling
> out what you outline above.

My intent was to suggest that these suggestions be made
independent of, and outside, the document being prepared as ICG
input.   Putting it into that document would add what would be,
given my perception of the WG's current direction, irrelevant
and distracting text as far as the ICG or NTIA are concerned
with no binding effect on the IAOC or anyone else.   That is
precisely why I suggested that, if it seemed sensible to them to
do so, the IAOC might simply generate an "interesting
discussion, message received" comment and go off and pursue some
of those approaches.  So the omission from -03 does not, IMO,
"rule out" anything.

best,
   john

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 15 Nov 2014 17:54:09 +0000

> focussing on all the relevant issues.

Right, my reading of the list traffic is that I reckon that you
and others who have what I think is your point of view, by which
I mean the folks who'd like the draft to do "more" and be more
legalistic and who aren't (yet!) involved with the technical work
of the IETF.... just do not share the IETF's point of view, for
example that we'd likely prefer to just drop the term IANA and
pick another way to handle protocol parameters if using that
term required sorting out a load of problematic legalities.

S.

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 15 Nov 2014 12:56:57 -0500

> Le 2014-11-15 à 10:27, Miles Fidelman <[email-masked]> a écrit :
> 
> Seth Johnson wrote:
> Maybe I'm starting to sound like a broken record here, but, let me try one more time:
> 
> I just spent some time reviewing all of the alphabet soup of acronyms and RFCs defining roles and responsibilities, and I keep coming back to the simple conclusions that:
> 1. Ultimately, the final document is a proposal (legal/contractual document, not protocol spec.),
> 3. "The IETF, IAB, IAOC, the IETF Trust, etc. are not separate legal entities.  Actually none of them are legal entities at all.
> -- the IAB, IAOC, etc. are administratively defined components of IETF (and hence of ISOC)
> -- the IETF Trust, which everyone keeps talking about as if it's a separate corporate entity, is actually a contractual agreement
> (from the founding document of the Trust)"THIS TRUST AGREEMENT (the "Agreement") is made as of the 15th day of December, 2005, by CORPORATION FOR NATIONAL RESEARCH INITIATIVES, a District of Columbia non-profit corporation ("CNRI"), INTERNET SOCIETY, a District of Columbia non-profit corporation ("ISOC"), as Settlors, the INTERNET ENGINEERING TASK FORCE ("IETF"), and the INITIAL TRUSTEES as defined herein, and amended on February 20, 2014 in accordance with the provisions of Section 10.1 hereof.
> 4. As far as the external world is concerned, for legal and contractual purposes, statements like "the IAB will decide" or "the IAOC will xxx" are equivalent to saying that "the IETF will xxx" with some details added as to the internal organization and procedures of the IETF.  (E.g., If I bring a car back for warranty service, it's the dealership and the automaker that are legally responsible, and I really don't care about who the service manager reports to, or how the paperwork is handled.)  In the particular case of arbitration, between IETF and ICANN, "the IAB will decide" is essentially saying that "the IETF will decide" -- which is simply not the way the world works, one party to a dispute can not arbitrate that dispute.
> 
> 
> So, yes, maybe the proposal to ICG has to "respect the IAOC's responsibility under RFC 6220," but....:
> 1.  the final document submitted to ICG has to be a single document, reflecting the the IETF-as-a-whole
> 2.  if there are issues that are in the IAB's and IAOC's purviews, they should be addressed in the final document sent to ICANN
> ---- the "IETF Proposal" that goes to the ICG should be complete, and reflect the considerations of all the components of IETF
> ------- a proposal that contains language like "the IAOC should address issues a, b, and c" is incomplete -- those issues should be addressed before a final proposal goes in
> ---- arguably, the document should be submitted by ISOC, since it's the only legal entity
> ---- the lawyers should really, really, have a look at the final proposal and adjust it as appropriate
> 3. the requirement for open/consensus process should apply to the complete proposal
> 
> Which all comes back to:
> 1. The working group majority view (NOT a consensus view) seems to be driving toward some combination:
> -- a Pollyannaish view that all will continue to work fine, there are no legal/contractual issues to address and/or we can deal with such issues in the future
> -- very loose, subservient language ('if, in the event of a conflict, which of course will never happen, everyone will resolve the issues in good faith in zero time, with zero operational impact') -- as opposed to strong, clearly worded contractual terms that would empower the IAOC and the IETF to prevail quickly, if the relationship with ICANN were to go drastically wrong.  [I'm still confused as to why many of us don't see as much need for SHALL and MUST statements in contracts as in technical specifications, particularly in that the usage of these terms originates in the contractual world.]
> 2. If the WG is not going to deal with these issues, then how will they be dealt with, by whom, and by what process, and who's signature will actually be on the final proposal?  (I've yet to see a definitive answer to this.  For that matter, who actually gets to make this call?)
> 

As individual
- thanks for your research
- most of your points are right, but the question is where/how/when they will be dealt.  This wg is not chartered to do legal work.  It is as we were doing an SOW, not the contract itself. 

Marc

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 15 Nov 2014 13:02:51 -0500

> term required sorting out a load of problematic legalities.

Just to be clear, this person who shares Richard's view has:
- been indirectly involved in IETF technical work, admittedly not in a 
while, back in my year at BBN
- been involved in Internet policy matters for years
- and shares the view that the IETF is not focusing on MOST of the 
relevant issues, as the relevant issues (in my less than humble opinion) 
have nothing to do with technical matters, and everything to do with 
governance, regulatory, legal, and contractual matters -- issues that 
the IETF generally does not concern itself with

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 15 Nov 2014 13:18:34 -0500

> - most of your points are right, but the question is where/how/when they will be dealt.  This wg is not chartered to do legal work.  It is as we were doing an SOW, not the contract itself.

Yes, and the question remains on the table - who IS chartered to do the 
legal, and by implication, policy work, and how is the community to 
comment on that?

After all, the document is titled "Response to the Internet Coordination 
Group Request for Proposals on the IANA protocol parameters registries," 
and states right up front that "The IETF community is invited to comment 
and propose changes to this document."

Yet, it sure looks like the WG thinks its preparing the final document 
to be delivered to the ICG, in the form of an RFP prepared by normal 
processes for addressing technical issues.  That is simply broken.

The silence is deafening in regards to:
1. Is the intent that this document be the final deliverable to the ICG?
2. How will all of the issues the WG considers outside its charter be 
addressed, and by whom?
3. How is "the IETF community ... to comment and propose changes to this 
document?" To whom are such comments and proposed changes to be 
addressed, if not the WG?  How are such comments and proposed changes to 
be discussed and acted upon?
4. For that matter, who is the authoritative individual or group who can 
answer/decide these questions?

Miles Fidelman

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Nov 2014 07:50:34 +1300

Miles,

On 16/11/2014 07:18, Miles Fidelman wrote:
...

I think we hired the IESG, IAB and IAOC to act as our leadership.

> 1. Is the intent that this document be the final deliverable to the ICG?

Since the IAB is chartered to designate the IETF's IANA, I think
the IAB is evidently on the hook for final delivery to the ICG, which
will probably include some formatting, but shouldn't change the substance.

> 2. How will all of the issues the WG considers outside its charter be

If they do concern the IETF directly, our leadership, who know well
enough to consult the IETF at large when points of principle come up.

> be discussed and acted upon?

That's what an IETF last call is for, right? That's just normal document
shepherding over the next few weeks.

> answer/decide these questions?

BCP 9 (IETF process), BCP 39 (IAB Charter), and BCP 101 (IASA/IAOC)
seem to make it clear that the IAB, IESG and IAOC have the appropriate
roles and duties. I don't see any real mystery here.

   Brian

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 15 Nov 2014 13:52:21 -0500

Le 2014-11-15 à 13:18, Miles Fidelman <[email-masked]> a écrit :
> Yes, and the question remains on the table - who IS chartered to do the legal, and by implication, policy work, and how is the community to comment on that?

I see that we are in agreement in: 
- the wg has produced what it has to from the charter he has. 
- there are additional steps to be done by some other groups/individuals/committees/…

Nobody said that this ICG response is the end of the work. 

Marc.

> 
> After all, the document is titled "Response to the Internet Coordination Group Request for Proposals on the IANA protocol parameters registries," and states right up front that "The IETF community is invited to comment and propose changes to this document."
> 
> Yet, it sure looks like the WG thinks its preparing the final document to be delivered to the ICG, in the form of an RFP prepared by normal processes for addressing technical issues.  That is simply broken.
> 
> 2. How will all of the issues the WG considers outside its charter be addressed, and by whom?
> 3. How is "the IETF community ... to comment and propose changes to this document?" To whom are such comments and proposed changes to be addressed, if not the WG?  How are such comments and proposed changes to be discussed and acted upon?
> 4. For that matter, who is the authoritative individual or group who can answer/decide these questions?
> 
> Miles Fidelman
> 
> --

---

From: Jefsey <[email-masked]>
Date: Sat, 15 Nov 2014 20:11:04 +0100

At 19:02 15/11/2014, Miles Fidelman wrote:
>- been indirectly involved in IETF technical work, admittedly not in 
>a while, back in my year at BBN
>relevant issues, as the relevant issues (in my less than humble 
>opinion) have nothing to do with technical matters, and everything 
>to do with governance, regulatory, legal, and contractual matters -- 
>issues that the IETF generally does not concern itself with
>Miles Fidelman

Amen.

This other person who shares Richard's view has been involed in the 
international network in managerial capacity since may 1978, is the 
only (I believe) non-WG IETF mailing list facilitator who has the 
right to ban himself without having to discuss it with anyone, and 
has always been told for 15 years that there is not such a thing as 
an "IETF's point of view" before there is a rough consensus, 
something which does not exist in this WG.
jfc

PS I do not know what it is worth but "Jefsey IETF" returns 375.000 
hits on Google.

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 15 Nov 2014 20:09:22 -0500

> Therefore, my answers are:

"Hired?"

> roles and duties. I don't see any real mystery here.

Well... how about hearing from them, in their official capacity?

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 15 Nov 2014 20:10:55 -0500

> Nobody said that this ICG response is the end of the work.

I'm asking about the steps between the WG work, and work on the other 
issues that have to go into a formal response to the ICG. WHAT other 
groups/individuals/committees?

Miles

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 16 Nov 2014 11:49:13 +0100

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: samedi, 15. novembre 2014 18:54
> To: [email-masked]; John C Klensin
> of the IETF.... just do not share the IETF's point of view,

The NTIA explicitly requested inputs from the "global multistakeholder community", which is broader than the people who are involved with the technical work of the IETF.

Using the IETF process to solict those broad inputs for the protocol parameter part of the IANA function struck me as very sensible, because the IETF process is inherently open to all participants.

However, I now perceive that the intent is that decisions should be made on the basis of the positions and preferences expresed by "those who are involved with the technical work of the IETF", and that the "IETF's point of view"  regarding the transition of the protocol parameters will be the point of view of that narrow subset of the "global multistakeholder community".

If I had understood at the beginning that that was the intent, I probably would not have wasted everybody's time by bringing a different point of view, based on different knowledge and experience, to this discussion.

I apologize for my misundertanding and for any inconvenience that it may have caused.

> for

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 16 Nov 2014 11:55:13 +0100

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Marc
> Blanchet
> Sent: samedi, 15. novembre 2014 18:57
> To: Miles Fidelman
> Cc: [email-masked]

SNIP

> - most of your points are right, but the question is 
> where/how/when they will be dealt.  This wg is not chartered to 
> do legal work.  It is as we were doing an SOW, not the contract itself. 

Indeed.  And a Statement of Work is exactly what was in "02", namely a call for other organizations to do the legal work to evaluate whether any additional agreements were called for.

It is not disputed that the current IANA functions contract between NTIA and ICANN contains provisions which are not found in the current agreements between IETF and ICANN.

What is disputed is whether those provisions are of any significance or consequence.

I submit that that is a legal matter, which should be analysed by professional lawyers.

Draft "02" called for exactly that.  In contrast, draft "03" prejudges the matter, by implicitly concluding that the provisions in question are of no significance or consequence.

That does not seem appropriate to me, neither from the substantive point of view, nor from the procedural point of view.

As you correctly say above, this group is not chartered to do legal work.  So why is it doing legal work, by concluding that the provisions in question are of no significance or consequence?

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 16 Nov 2014 12:05:14 +0100

> From: John C Klensin [mailto:[email-masked]]
> Subject: RE: [Ianaplan] Proposed text reflecting IETF91 discussion
>
> >> http://www.iana.org/protocols, etc.

SNIP

> > nothing prevents ICANN from making the changes
> forms in various documents, and so on.

Sorry, but I cannot refrain from pointing out that you have given a very
convincing explanation of why what happens to "IANA.ORG" does matter.  That
is, it isn't that simple to just move everything to some other domain name.

> one) try to develop that plan.

As I understand "02", it merely said that there is an issue and that a
transition plan should be worked out.  That is missing from "03".

> this discussion as a starting point.

In my view, that is what "02" said.

>I hope the IETF has not

Perhaps some of the language in "02" was too prescriptive and could have
been made less prescriptive.  But that does not justify, in my view,
eliminating entirely the recommendation that appropriate work be carried out
by other groups.

SNIP

---

From: Milton L Mueller <[email-masked]>
Date: Sun, 16 Nov 2014 12:30:52 +0000

> > This is almost exactly what the text says, in fact. The plan for the
> > transition is not to change anything.

Alissa, 
How does this "plan" address the concerns raised by a significant number of the people in this WG? 
 
> That is, if X is an issue, then saying "we will address that later" when there is
> an alternative that allows addressing it now cannot, in my view, be

I agree with Richard but I think there is a more serious problem here, one of process. 
The revised 03 version is in fact a major step _away_ from consensus and towards a view that was fully aired and considered by some of us but failed to completely win our agreement. 

It seemed to me that Eliot Lear was making a serious good faith effort to do that at every step of the way, and at the Hawaii meeting a faction of this group went into a room and decided to toss out what he did and move toward a less accommodating view.

I do not understand why the other side of this debate is not willing to make a few minor compromises required to gain true consensus for this document. It raises major issues regarding the viability of any claim that this document has even rough consensus. That will raise problems for the proposal both at the ICG stage and at the broader public comment stage. 

We need to make a serious effort to gain real support for this proposal from all serious parties involved. I could have lived with something very close to draft 02 and even would have made concessions in the direction wanted by some of the people I have been debating with. But 03 is basically just saying: "to heck with you, your view doesn't matter, you lose." 

That's not how you achieve consensus.

---

From: Milton L Mueller <[email-masked]>
Date: Sun, 16 Nov 2014 12:48:50 +0000

> > Right, my reading of the list traffic is that I reckon that you and
> > others who have what I think is your point of view, by which I mean
> > the folks who'd like the draft to do "more" and be more legalistic and
> > who aren't (yet!) involved with the technical work of the IETF....
> > just do not share the IETF's point of view,

Stephen: 
I'd invite you to take a look at the ICG's RFP. 

The most relevant portion is in Section 0, where we asked for "complete formal responses:"

"Proposals should be developed through a transparent process that is open to and inclusive of all stakeholders interested in participating in the development of the proposal. In order to help the ICG maintain its light coordination role, all interested and affected parties are strongly encouraged to participate directly in these community processes."

That carefully worded and long-debated phrasing contains instructions both to interested participants and to the operational communities. It says to the interested participants: don't come to us with your own ideas, go into the OC process and participate in good faith and abide by what comes out of it. It says to the directly interested parties of the OCs: you had better allow full participation by people who are not normally part of your community but are interested enough to maintain serious and constructive engagement in your proposal development process. 

That, as far as I am concerned, is a requirement of our RFP process.

Thus, telling participants in the process that they have not historically been part of your group and therefore that their views don't count is clearly out of bounds and will definitely cause trouble in the assessment and public comment stages of the NTIA proposal development process. And any solution that represents "the IETF's point of view" and not that of a broader open OC proposal development process is not going to fly. 

--MM

---

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

> As you correctly say above, this group is not chartered to do legal work.  So why is it doing legal work, by concluding that the provisions in question are of no significance or consequence?

To which, I'll add that NOBODY seems to be charted to do legal work, FOR 
THIS DOCUMENT, for the IETF.  Nor is there a process for review and 
comment on that legal work in an open forum.  I.e., those of us who have 
contractual, policy, and regulatory points of view seem to have no venue 
for doing so.

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 16 Nov 2014 09:52:45 -0500

> That's not how you achieve consensus.

Indeed.

And, to the point of including folks names in the acknowledgements, as 
having contributed:  If they don't agree, then that constitutes false 
advertising, as to both the existence of consensus, and the implied 
agreement of those named.

Now, if there were to be minority opinions attached, that would be a 
more accurate reflection of the situation.

Miles Fidelman

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 16 Nov 2014 15:28:15 +0000

Milton,

On 16/11/14 12:48, Milton L Mueller wrote:
> 
> Thus, telling participants in the process that they have not
> historically been part of your group and therefore that their views
> don't count is clearly out of bounds and will definitely cause
> trouble in the assessment and public comment stages of the NTIA
> proposal development process. And any solution that represents "the
> IETF's point of view" and not that of a broader open OC proposal
> development process is not going to fly.

That's utter nonsense.

It's entirely obvious that there are a number of people on this
list (yourself included) who are coming at this with a different
viewpoint from the many people on this list that I know are very
much involved in writing RFCs that make changes to IANA protocol
parameters.

Those people (again yourself included) have I think provided good
inputs in various ways, I'm sure the editors could provide all the
details, but on this specific topic seem to me to be just wrong
and continually missing the point that the IETF does not need to
get all lawyered up to provide the ICG with the IETF's proposal
or feedback.

ISTM that you are attempting to cast doubt on the process just
because you and a few others are in the rough on one topic. And
as I said above, that's utter nonsense. In open processes like
the IETF's you just don't always get what you want, no matter
how often you (or Richard IMO) metaphorically try to throw the
toys out of the cradle.

S.

---

From: Jefsey <[email-masked]>
Date: Sun, 16 Nov 2014 18:50:30 +0100

>That's utter nonsense.

Dear Stephen,

let keep calm, please. Please understand why it makes far more sense 
than you seem to feel. I just hope you will bear with me for the 
length of this mail.

I am speaking here in copying the IUCG@IETF, i.e. as an IETF User.  So,
- it will be clear I am not "one of you". Actually "you" banned me for that.
- the IANA plus its complementary and missing sites are your 
interface with us.

What I can say is that we are unpleased with the IANA current venue 
for two simple reasons:
1) you never consider what we would need to see, only what you want 
to say there. This may not be a good way to manage an interface.
2) you only contracted with ICANN and we are not pleased with that 
monopoloy because it does not respect the many multistakeholder 
rights of our RFC 6852 global communities.

We have learned to live with this. We accept that if your whole thing 
could be better for us, it is a great success, and has resulted in a 
"huge bounty" (cf. RFC 6852).

However, we tend to identify both issues as reverberating the NTIA oversight
- (1) through the USCC/industry procurement/Anglo-Saxon cultural 
proximity for the IETF,
- (2) its contractual renewal live/death power on ICANN.

We are offered two serious/important responses by authorities we respect:
1) the NTIA transition to the FCC, by Strickling/Obama
2) the IAB statement on the technology transition toward a 
Confidential Internet, by Russ Housley.

Both may have a fundamental impactd on the quality of the IETF 
deliveries and on our daily digital operations.
This means that we are pleased but also that we have important concerns when
- we observe through this WG's debate that you only consider "your" 
interest in maintaining your own operational status-quo.
- while we look for an innovative, security oriented, steady 
technology development and a better control on our digital operations.

Unfortunately, at the end of the day we are those who pay, nationally 
vote for our Govs, and incidently develop our own technology and run 
our operations.i.e. the IANA Users.
1. We understand you do not like our Govs, we understand we are not 
much related to the Libre. This was more and more reciprocal 
***until*** both the USG and the IAB made their two major steps 
ahead. Now with NETmundial and the architectural possibilities being 
open by the offer of cooperation of the IAB, we are ready to 
consider/cooperate for the better.
2. As you say we see our own face of the interface, and we may be 
wrong. In such a case it is up to you to help us, as we try to help 
you in spending time working in here. Not to tell us "we know better, 
don't disrupt".

Please do not keep us in the situation where we feel in agreement 
with the NTIA and IAB, and as result, in opposition with you and (due 
to that) with ICANN.
Would it not be amazing if you made us to chose ICANN between "you" and them!

jfc

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 16 Nov 2014 19:04:31 +0000

On 11/16/14, 4:30 AM, "Milton L Mueller" <[email-masked]> wrote:
<snip>
>
>I do not understand why the other side of this debate is not willing to
>make a few minor compromises required to gain true consensus for this
>document. It raises major issues regarding the viability of any claim
>that this document has even rough consensus.

"True consensus" surely means something different than IETF consensus. But
if you ask the IETF a question, IETF consensus determines how it is
answered. Our consensus process is integral to who we are - arguably, it
is all that we are. It up to the chairs of this group to assess consensus
on this document, and there's little purpose in asserting on the list that
consensus has or has not been achieved.

>That will raise problems for the proposal both at the ICG stage and at
>the broader public comment stage.

I fear I must preface my remarks here with another declaration that I do,
really, believe you personally are trying to help here Milton. And I think
it is entirely appropriate for ICG members to be on this list and to
participate in this discussion - even to clarify what they believe the ICG
is asking for. But there is a line here. There is a fine line between an
ICG member telling the IETF its proposed response "will raise problems...
at the ICG stage" and an ICG member effectively threatening to raise
problems if the IETF response doesn't conform with personal preferences.

Now please, again, nobody freak out, we're all cool here, I'm not saying
that line has yet been crossed. But if that line is crossed by anyone on
the ICG, I would propose that we add an appendix to our ICG response
pointing to any relevant statements and explaining that this input
hampered our ability to answer these questions.

This isn't an ethics matter or a conflict of interest matter even - it
just defeats the purpose of process. The ICG, perhaps ill-advisedly, asked
the IETF for its response to this questionnaire. The response that the ICG
gets should be the IETF's response - not the response of some different
legally-savvy techno-political body, not a response based on something
other than our consensus process, but the IETF's response with all the
constraints and limitations that implies. If instead the ICG would rather
see a document reflecting what the ICG thinks the IETF should put into
such a response, surely the ICG could produce that document on its own and
save us some work.

Please, just let us resolve this - to us, relatively trivial technical
matter - to our own satisfaction.

Jon Peterson
Neustar, Inc.

---

From: Jefsey <[email-masked]>
Date: Sun, 16 Nov 2014 21:05:55 +0100

At 20:04 16/11/2014, Peterson, Jon wrote:
>Please, just let us resolve this - to us, relatively trivial 
>technical matter - to our own satisfaction.

Jon,

many of your points technically stand. But please remember that 
supposedly your own satisfaction is to make the internet run better, 
what  is something the Internet users appreciate.

This means that this WG's rough consensus appreciated by the Chairs 
is subject to the IETF last-call rough consensus, which is subject to 
the IESG decision which is subject to appeals which are subject to use.

The real issue is that the ultimate referent authority for IETF and 
ICANN appeals was the USG through the NTIA, most probably advised by 
the IETF rough consensus, and US industrial interests and that is 
what is transitionning.

- The question was raised by RFC 6852,
- then it was raised by the WCIT vote in Dubai
- then it was raised by Edward Snowden
- then it was raised by the Montevideo declaration
- then it was raised by the NTIA statement,
- then it was raised by the Geneva Davos NETmundial,
- then it was raised by President Obama a few days ago,
- then it was again raised by the IAB the next day.

You discuss issues related to a now ***obsolete/condemned*** Internet.

The internet we are interested in seeing properly redesigned, run and 
managed is an Internet you did not develop, says the IAB. It is a 
secure internet.

This is why we currently do not trust you. This WG is not about the 
ICG (show me the term in its Charter). It is about you making us to 
trust you are motivated in responsibly designing the internet we are 
promised. We certainly understand the difficulty and the Loc/ID 
missing presentation layer, etc. issues. And are ready to help you 
achieving the task; but do not start by ignoring, bashing or 
attacking us. This is counter productive and pushes us to do the job 
by ourselves, with our Govs, and to fork.

Implicitely the external world broad consensus (cf. RFC 6852) would 
be pleased if the referent was - at least temporarily - the IAB, what 
may not please ICANN. However, this consensus can only be temporary due to:

- the terms of the BCP 78, i.e. the internet licence which is not a 
CC license or public domain;
- the USG which wants to stay more equal than its 191 fellow governments.
- the technical solutions that will be found to make the internet 
secure (is this possible) or to build a secure internet.

Now, you can ignore me and my mails. I just send them to help and try 
to avoid the losses for many of you that a messy fork would 
represent. I/we fully understand that Neustar would be hurt by the 
secure internet DNS Class the Libre is planning to test, in the case 
it became a non-business equal open reality. However, it you really 
want to defend the Neustar interests, and the whole Naming ICANN 
"industry", please cooperate, try to find and document new trusted services.

We have been proposed a multistakeholder approach by the current 
oversight holder.
We have been proposed a secure internet design support by the 
architectural board.
We only see you discussing your own status-quo.

What do you want us to think. Even with the best good will?
Tell us, tell us ....

jfc

---

From: Jari Arkko <[email-masked]>
Date: Sun, 16 Nov 2014 10:07:56 -1000

I wanted to remind everyone of the process we are going through here.

We are documenting IETF’s transition plan because we want to see one and because the ICG has asked for one.

The process is open, and on we have collectively spent considerable energy talking about the process in various places so that we can draw in additional people who care about it. We care about all of these opinions. (But see below for “rough consensus”.)

The ICG set up a process where most of the responsibility for the planning is in the communities. We are using our community process just as we do for everything else. 

The chairs get to determine WG consensus; the area director and the IESG get to do that as well after IETF Last Call.

IETF operates on the principle of rough consensus. This may involve situations where not everyone agrees on all aspects of the result; please respect the possibility that on a specific topic you might be “in the rough”. What matters is the group’s opinion as a whole. Whatever it is.

Please also respect the role of the chairs in determining consensus; IETF consensus is not run on a formula, they need to use their judgment.

Finally, I’d like to urge everyone to treat other people’s opinions in a respectful manner. There is no need for emotional words to describe the goodness or badness of approaches.

Jari
(speaking as the group’s area director and as an ICG member with opinions but not speaking for the ICG)

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 16 Nov 2014 15:37:37 -0500

Milton,

> It seemed to me that Eliot Lear was making a serious good faith effort to do that at every step of the way, and at the Hawaii meeting a faction of this group went into a room and decided to toss ou…

I object in the strongest terms to that description of things.  I
think the minutes show, and the chairs' reactions indicate, that the
views supporting the statements you are unhappy with having removed
from the Internet Draft were in fact well exposed and discussed in the
room.  The WG just didn't agree.  That happens; it's what "rough
consensus" looks like.

> I do not understand why the other side of this debate is not willing
> to make a few minor compromises required to gain true consensus for
> this document. 

I don't think this is a matter of "compromises"; I think it's a matter
of participants in the WG weighing arguments and either coming around
or not.  The result is the rough consensus of the WG.  On some items,
your view is not going to make it in.  Just because people aren't
agreeing with you doesn't mean they're wrong; it means that they
disagree.  This particular topic, I should think it plain, is one on
which participants of good faith _can_ disagree; and I think in the
case of the text that you're unhappy to see go missing, people
disagree with you.  To put this another way, why isn't it you who
needs to compromise in this case?

> It raises major issues regarding the viability of any
> claim that this document has even rough consensus.

I think you have to make a much stronger argument that just saying so
if you want to assert that.  To begin with, we have two extremely
experienced chairs who've participated in the IETF for a long time and
who have been involved in contentious consensus calls before.  They're
in a position to make the determination of rough consensus, not you.
We also have a whole additional step to go through (IETF last call),
and different parties rule on the rough consensus there.  Finally,
there's a well-exercised reconsideration ("appeals") mechanism that
could yet heave into motion.  I might suggest some more reflection on
RFC 7282, but I expect you've already completely understood that
document; it may be that you disagree with it.

> That will raise problems for the proposal both at the ICG stage and
> at the broader public comment stage.

I think it would be good if you made clear that you are raising a
concern in that sentence, and not making a thinly-veiled threat.  An
observer who was less familiar with your mode of working could take it
either way, and surely it would be much worse for the entire NTIA
process if one member of the ICG were going around threatening
communities into following his preferred outcome than it would be if
some community came up with "the wrong answer".

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 16 Nov 2014 15:40:27 -0500

Jari,

> (speaking as the group’s area director and as an ICG member with opinions but not speaking for the ICG)

As the area director, perhaps you can speak authoritatively to the 
question of how those aspects of the ICG RFP, that seem to have been 
deemed outside the scope of the WG, and that are not generally addressed 
by IETF process, will be addressed.

In particular, the ICG has called for a "plan from the protocol 
parameters community" embedded in a "complete proposal" - focusing 
primarily on procedural, legal, and contractual considerations -- not 
normally the subject of IETF WGs.

Can you please advise as to the process by which those aspects of the 
proposal, that are deemed outside the WGs scope, are to be addressed 
through an open, consensus process, and how community input is to be 
incorporated regarding these non-technical aspects of the proposal?

Thank you,

Miles Fidelman

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 16 Nov 2014 13:06:01 -0800

Milton said:
> 
>> That will raise problems for the proposal both at the ICG stage and at the broader public comment stage.

[BA] The IANAPLAN WG's charter is very narrowly scoped. Under that Charter, as well as described in RFC 6220, the IAOC has responsibility for contracting with the IANA functions operator chosen by the IAB. Since the IAOC has access to counsel and a history of overseeing the protocol parameters contractor, they are the right group to carry out that responsibility.

Ultimately, the otput of the ICG needs to be evaluated within a broad context, which includes not only the proposal itself, but also agreements between the communities and ICANN as well as the outcome of efforts relating to ICANN accountability.  The IANAPLAN WG was only chartered to provide one (small) piece of this puzzle.

---

From: Seth Johnson <[email-masked]>
Date: Sun, 16 Nov 2014 16:14:02 -0500

No, the implications of the transition go well beyond the functional
perception of the process.

Our job is to conduct the transition in a controlled and responsible
manner, to articulate how that needs to be done.  Those who conduct
the process are stakeholders who are also process owners, and that
gives you a certain tunnel vision.  If the functions you're executing
are the same, then supposedly "obviously" the result will be the same.

Our job is to say, Yes, there is a transition.  How do we understand
its significance and implications and what can we do to transition the
process without screwing it up?

The notion that just saying it's all good is going to characterize the
process and the change we're undergoing sufficiently is the very
hallmark of a transition that fails because process owners did not
think it necessary to analyze the process sufficiently and went on how
they've done things and what they know (tacitly and explicitly),
because that's what they do every day.  It also allows the process to
change fundamentally as a result of unacknowledged factors, both in
tacit understandings and in the change of context surrounding the
process.  This is exactly *not* what we are supposed to do.  If we
don't rise to the task, we are simply handing off the process,
apparently just because it's always worked that way.  The protocol
registries are a product that has many stakeholders, and we are
responsible for understanding what the transition is going to do -- to
the protocol registries, what they mean, how they're used -- to the
role of government, which we have been able to expect not to meddle in
our communications -- to the process and how we conduct it -- and to
all of us who depend on the registries and the way we use them.

Seth

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 16 Nov 2014 16:37:39 -0500

> process without screwing it up?

I think this is exactly right.  But I think part of the controversy
may be that some disagree about the consequences.  Let me
describe two caricature positions, neither of which represents any
actual person AFAICT, to suggest where the poles of disagreement are
in my opinion.

Some of us, it appears, think that this is an extremely delicate
matter for the protocol parameters registries as well as for other
registries.  It appears to me that those who think this feel strongly
that it is important now to arrange the adoption of several
provisions.  It appears that those holding this position think that
the existing arrangements are open to negotiation in order to achieve
some of these other ends.

Others of us, it appears, think that the existing arrangements for the
protocol parameters registries are perfectly adequate, and the only
goal here is to do every possible thing to ensure that those
arrangements don't change an iota as a result of the transition.  It
appears to me that those who think this feel strongly that there are
no new provisions to be made, though there might be things that
currently follow as a result of the NTIA-ICANN agreement; those
provisions need to be documented.  It appears that those holding this
position think that there is nothing more important than avoiding
opening any existing agreement for any kind of negotiation.

Now, having drawn those cartoon versions of the positions, it seems to
me that most of us fall somewhere in between these views.  It also
seems to me that the closer one is to the first of these, the more one
might be uncomfortable with some of the changes from -02 to -03.  My
own impression is that the WG mostly leans toward the second end of
the spectrum.  If that's correct, then a couple things fall out.  

First, "How do we understand the transition's significance and
implications?"  Under this view, there is not a great significance,
and the implications are matters of detail (important detail, but just
details all the same).  Second, "What can we do to transition the
process without screwing it up?"  Under this view, the answer is to do
as little as possible, because the existing arrangements are good and
working, and we have always believed that the main protection to the
protocol parameters registries lay with the IETF's established (and
sometimes used) ability to manage the publication of its registries as
it sees fit.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Seth Johnson <[email-masked]>
Date: Sun, 16 Nov 2014 16:38:10 -0500

There are ways to do this -- bare minimum ways, more fully articulated
ways.  But saying we like the process the way it is and the transition
doesn't really represent a change that can affect the process at all,
is certainly not actually doing what we're chartered to do.

Seth

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 16 Nov 2014 21:39:34 +0000

Hard to take exception to much below. But hard as well to connect it to
anything I was saying in the prior mail.

No one, not even me, is reducing this to "it's all good, peace out." The
-03 response takes a somewhat more nuanced tack, say. We've all thought a
lot about the matters you enumerate below, and I don't think we are
failing the community in that regard - we're mindful of the risks and
opportunities alike inherent in the transition. Our response to the ICG
reflects that mindfulness.

Jon Peterson
Neustar, Inc.

---

From: Seth Johnson <[email-masked]>
Date: Sun, 16 Nov 2014 17:07:32 -0500

On Sun, Nov 16, 2014 at 4:37 PM, Andrew Sullivan <[email-masked]> wrote:
> provisions.

I'm not particularly concerned about those specific provisions.  I'm
concerned that we not place ourselves in a new context without
screwing ourselves over.  The specifics some are engaging on are
interesting mostly as proxies for what should be expressed about the
transition.

> It appears that those holding this position think that

Yeah, well this is not a concern I would open up.  It's simply
misunderstanding if that's projected onto me.  I'm simply doing it
like a properly conceived process transition, what you should
understand happens in that situation and how one guards against a
process falling "out of control."

> sometimes used) ability to manage the publication of its registries as

This is all unnecessarily political, a theater that's irrelevant.
Read what I said more carefully.

Forget the particular issues, which I have been largely agnostic on,
because they're sort of proxies rather than expressing how to
transition in a controlled manner -- and think about it as a process
that functions a certain way, you don't want to change without seeing
what's happening.  That's the right way to think about it, because you
can address the process in more general terms, as what can affect it
generally.  And you can then take a methodical approach and stance.  I
allude to that further on in my note, so do read further.

What you've expressed is what I described -- how to mess it up.  It's
not actually enough, not really analyzing the process sufficiently to
do the job.  It's easy to understand the general kinds of factors that
will affect a process -- in general terms.  You only need to be sure
to consider those factors.  It's very, very common for process owners
to have this type of shortened perception of their process, whereas
how to correct that and really do it, is something that is perfectly
understandable too.

Seth

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 16 Nov 2014 17:08:18 -0500

> opening any existing agreement for any kind of negotiation.

I'd characterize it more as:
- the current MoU is not very specific about accountability and 
transition, beyond either party can cancel with notice
- the current MoU does not detail roles, responsibilities, authority, 
etc. in the event of a hostile cancellation
- the current MoU does not provide for a model where events might lead 
to IANA functions being divided among multiple providers

Those are facts.  There's a difference of opinion as to whether those 
gaps should be addressed in IETF's proposal to ICANN, and if so, to what 
specificity.

I think I'm stating things fairly to characterize opinions as falling 
into several broad areas:

1. These are not technical issues, and thus outside the scope of the WG 
(except to the extent that a contractual dispute might disrupt operations).

2. These issues should be addressed, but things are working fine, so 
they don't need to be addressed now.

3. These issues should be addressed, in the WG draft, but with very 
loose language (at the level of MAY statements) that leaves details to 
the IAOC in the event of some future need to deal with these issues.

4. These issues should be addressed, in the IETF proposal (WG draft or 
otherwise), with very clear, concise, and strong language (at the level 
of SHALL and MUST statements), with the intent of avoiding protracted 
disputes (and possibly court hearings) in the event of a hostile 
cancellation.

I'd characterize 4 as the minority position, one that I take, and one 
that seems to be shared by Milton and Richard - perhaps because we come 
at this from a more policy-oriented perspective.

Miles Fidelman

---

From: Seth Johnson <[email-masked]>
Date: Sun, 16 Nov 2014 17:15:58 -0500

To what you in particular said, I'll say it relates mostly to your
telling Miles to essentially "leave [others besides Miles and an
ostensible alterior camp] alone to get the job done."  Here's the
quote: "Please, just let us resolve this - to us, relatively trivial
technical matter - to our own satisfaction."  That's close to saying
process owners' internal functional understanding is adequate for the
job -- and the concerns of Miles and others as supposedly deficient or
"outside" of what's "necessary" or your "trivial technical"
understanding of it.

But I excised the direct rebuttal to that and left the general point.
Which is the important general point.

Seth

---

From: Jari Arkko <[email-masked]>
Date: Sun, 16 Nov 2014 12:19:59 -1000

Miles,

Thanks for a good question.

Note that IETF working groups can and have been formed on topics beyond mere technical matters, such as is the case with IANAPLAN. This is not to take anything away from the role of operational or administrative committees such as the IAOC. However, those committees operate largely on the direction of the IETF community rather than vice versa. The IETF community has an opinion, the opinion is expressed or written down, the committees execute the administrative details relating to the matters. This is quite unlike a commercial enterprise hierarchy, which operates largely in the other direction.

Anyway, from my perspective the working group is in charge of delivering a complete proposal that is sufficient for the proposal to be understood and taken into execution. From my perspective they have done that.

However, this does not mean that the working group will itself write every detail. Obviously we have a lot of documentation that the proposal points to, such as existing RFCs. But just as is likely with other community plans, there are likely going to be statements of the form “X must happen” or “Y needs to be agreed with Z”. As long as X and Y are clearly described this is what we can and should do at this stage. An obvious example is any kind of an agreement or contract with someone else - clearly the WG or even the IETF cannot just say those things, as other parties are involved. Similarly, there is a role for experts to deal with their topic matters, and we should not be the amateurs trying to do that ourselves.

Maybe an example helps. The document says:

 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.

I think that is clear enough to be understood. And quite obviously, if we are to get an acknowledgment on this matter from various parties, that is a task that we can have our operational committees pursue with other parties.

Does this clarify?

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 16 Nov 2014 22:23:13 +0000

> at this from a more policy-oriented perspective.

I think that's a not unreasonable description of things, except of
course that we're not dealing with a majority/minority count. (As
before: see 7282 for commentary and we'll see what the chairs' make
of it all.)

FWIW, I'd count myself more as something like "1.5. There may or may
not be things to be addressed, but things are working fine, so they
don't need to be addressed now, especially since if the manure ever
does hit the fan, the IETF could work around any problems with protocol
parameters irrespective of whether NTIA are in the picture or not."

That last clause is IMO very important and is something that you, Milton
Richard etc. seem to entirely discount. My guess about that is that
that's where the difference in being involved in writing RFCs or not
comes in. IMO, and as others have also stated, the IETF can deal with
any potential messing from ICANN wrt protocol parameters fairly easily,
if that is ever needed, which we figure is not very likely. And while
I can conceive that that may not be so obvious if one hasn't written
IANA considerations text for protocols, I remain puzzled that it does
not seem to sink in despite having been explained a number of ways by
a number of people.

S.

---

From: Seth Johnson <[email-masked]>
Date: Sun, 16 Nov 2014 17:30:22 -0500

But in any case, I appreciate your recognition of my message.  Makes
things easier instead of harder.  :-)

Seth

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 16 Nov 2014 22:35:55 +0000

No, happy to reply - don't want to get into a "what I meant was" spiral
here, but...

My note was not a reply to Miles, and was speaking to a very different
matter concerning the handoff and cross-participation between the ICG and
IETF. It had nothing to do with whether or not the IETF's "internal
functional understanding" is sufficient for any particular purpose. For
whatever reason, the ICG asked the IETF these questions, and it will be
the IETF that answers these questions. My note snarkily commented that
this might have been "ill-advised," because what will satisfy us in a
response might not satisfy everyone sitting on the ICG. But this is what
you get when you point the IETF at a problem, and changing what we are in
order to answer these questions would defeat the purpose of asking us.

Jon Peterson
Neustar, Inc.

On 11/16/14, 2:30 PM, "Seth Johnson" <[email-masked]> wrote:

>>>>On Sun, Nov 16, 2014 at 2:04 PM, Peterson, Jon
>>>><[email-masked]>
>>>>wrote:
>>>>>
>>>>>
>>>>>>to
>>>>> "True consensus" surely means something different than IETF
>>>>>consensus.
>>>>>But
>>>>> participate in this discussion - even to clarify what they believe
>>>>>the
>>>>>ICG
>>>>> the IETF for its response to this questionnaire. The response that
>>>>>the
>>>>>ICG
>>>>> such a response, surely the ICG could produce that document on its
>>>>>own
>>>>>and
>>>>> save us some work.
>>>>>

---

From: Seth Johnson <[email-masked]>
Date: Sun, 16 Nov 2014 17:44:17 -0500

While I try to unravel your last sentence, let me ask:  Oh, are you
ICG?  Did not understand that if so.  Which puts things in a new
light.  You were snarky, though, as you granted.  :-)

Seth

---

From: "Peterson, Jon" <[email-masked]>
Date: Sun, 16 Nov 2014 22:54:29 +0000

.... no, I am not on the ICG, or the IAB, or the IESG, or speaking here for
any employer or organization, or for anything other than what I believe
lies in the best interests of the IETF based on my experiences
participating here. I'm sure there's a web site that lists the ICG
membership if needed, or you might surmise from the mail I quoted below
(Andrew quoted it as well, to similar effect).

Jon Peterson
Neustar, Inc.

On 11/16/14, 2:44 PM, "Seth Johnson" <[email-masked]> wrote:

>>>>>>> on this document, and there's little purpose in asserting on the
>>>>>>>list
>>>>>>>that
>>>>>>> I fear I must preface my remarks here with another declaration
>>>>>>>that I
>>>>>>>do,
>>>>>>> really, believe you personally are trying to help here Milton. And
>>>>>>>I
>>>>>>>think
>>>>>>> just defeats the purpose of process. The ICG, perhaps
>>>>>>>ill-advisedly,
>>>>>>>asked

---

From: JFC Morfin <[email-masked]>
Date: Sun, 16 Nov 2014 23:56:45 +0100

At 21:37 16/11/2014, Andrew Sullivan wrote:
>I think the minutes show, and the chairs' reactions indicate, that the

"Sometimes, a show of hands can be useful; sometimes, it can be quite
damaging and result in terrible decisions.  Sometimes, using a device
like a "hum" can avoid those pitfalls; sometimes, it is just a poorly
disguised vote." (RFC 7282)

"We believe in rough consensus and running code".

Dear Andrew,
I am sure you realize that the minutes of the meeting room in Hawaii 
only concern a rough consensus of non-secure-internet designers. How 
many of them where Libre engineers footing their own T&L? This is not 
consensus, but "concensus", if you permit me the pun.

Now, since it seems it will be hard to reach a rough consensus before 
we have completed the whole appeal process, and that this XG's dbate 
is already between ICG members, the IUWG.NET's approach looks faster: 
to help study, document and develop an accepted running code.

This means a secure internet based upon a MYCANN plug-in.

Russ has declared the new internet has to be secure. Obama has 
decided the FCC was to make it neutral. It seems the transition has 
been settled and we just to have it completed.

We just need to complete and test the code as per ICANN/ICP-3 and 
submit it to the RFC 6852 global communities' competition for 
innovation. Will the ICANN, Google, Apple, USCC, Chinese, NSA, 
Russian, European, Libre, Civil Society, etc. MYCANN Plug-in be the 
more innovating and accepted one by the users?

Competition will tell!
The contest is open.

jfc

---

From: Seth Johnson <[email-masked]>
Date: Sun, 16 Nov 2014 18:04:09 -0500

On Sun, Nov 16, 2014 at 5:07 PM, Seth Johnson <[email-masked]> wrote:
> screwing ourselves over.

?  :-)  I mean:

I'm concerned that we not screw ourselves over as we place ourselves
in a new context.

(eom)

> The specifics some are engaging on are

---

From: Jari Arkko <[email-masked]>
Date: Sun, 16 Nov 2014 13:07:17 -1000

> manner, to articulate how that needs to be done.  

Yes.

> The protocol

Also agree.

I cannot stress enough how important it is that we have the right transition plan, and have a strong system that can withstand various kinds of pressures and contingencies.

> because that's what they do every day.  

But here I disagree strongly. I think we all are acting with integrity, forethought, and careful consideration.

First off, the plan does have some changes, even if the general design is the continuation of existing arrangements. All relevant parties acknowledging that the data is in the public domain, for instance. 

But that is not the key point here. We are here to have that strong system, but it does not necessarily follow that we need a new system. The IETF protocol parameters arrangement has been evolving for 15 years, and during that time we have continuously strived for that strong system. Every RFC, every agreement, every arrangement has been made with that in mind. Now, the WG obviously is the place to decide whether the arrangements described in the document are sufficient. But I think we should have that argument on the merits of the arrangements (and we have) rather than how much the arrangements changed.

And I do not think it should be surprising that the IETF community thinks largely in terms of continuation, given their high reliance on running code in other parts of their work. And like with running code, the fact that something runs doesn’t reduce our need to be able to deal with bad outcomes (security, errors, misbehaving peers, scaling). We all try very hard to build safeguards for those into our specifications and code.

Jari

(speaking as an individual)

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 16 Nov 2014 18:12:37 -0500

> Thanks for a good question.

And you for a substantive answer.

> I think that is clear enough to be understood. And quite obviously, if we are to get an acknowledgment on this matter from various parties, that is a task that we can have our operational committee…

Yes, but not satisfy.  Specifically, the ICG RFP ask for a "complete 
proposal," for a transition plan, from the IETF as representing the 
"protocol parameters community."  And goes on state "Communities are 
asked to adhere to open and inclusive processes in developing their 
responses, so that all community members may fully participate in and 
observe those processes. Communities are also asked to actively seek out 
and encourage wider participation by any other parties with interest in 
their response."

But... the WG charter specifically limits the scope and focus of 
discussions:

"Fully documenting the interaction between the IETF and the operator
of IETF protocol parameters registries may require detailed terms of
agreements or other details of procedures that are normally delegated
to and handled by the IAB or IAOC. "

The mandate is to address the full range of issues, by "open and 
inclusive processes."  Delegating a significant class of issues to the 
IAB and IAOC, without a venue for the level of discussions that have 
been occurring in the WG, does not (IMHO) satisfy the requirement, nor, 
more importantly, does it allow for significant input from folks who 
have a more policy oriented perspective.

To use your example:
"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."

As several folks (with intellectual property knowledge) have commented, 
this might not be "right," for several reasons:
- public domain means different things in different jurisdictions
- public domain eliminates any ability to control the content in 
question, such as to assert the authenticity of material (there's a 
reason that folks argue incessantly about what license to apply to open 
source software)
- the current statement strikes me as more of a politically correct, 
feel good statement, than one that has been examined in detail from all 
perspectives

This is a case where the discussion has to be opened to folks who are 
both knowledgeable and care about intellectual property issues, 
including, but not only, IETF counsel -- to think through the full set 
of issues and options - from technical, operational, procedural, and 
contractual perspectives as well as the legal one.  Intellectual 
property lawyers are useful experts to consult in such matters, but only 
with direction as to what one wants to achieve (again - there's a reason 
there are so many varieties of creative commons licenses).
Personally, I'd reach out to folks from the Software Freedom Law Center 
in this part of the discussion)

Respectfully,

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 16 Nov 2014 18:34:27 -0500

> not seem to sink in despite having been explained a number of ways by

Leaving aside that I have had some hand in writing RFCs (indirectly, 
while working at BBN, supporting others who were active IETF 
participants)....

I'd argue that many of you are discounting the experience of those of us 
who have been involved in contract disputes between 800 pound gorillas, 
and regulatory affairs (or for that matter, the OSI/TCP-IP wars, back in 
the day).

In protocols "be rigorous in what you send, and liberal in what you 
receive" is generally good practice.  In system design, it's good 
practice to anticipate and provide for edge cases and unanticipated 
error conditions.  When it comes to contracts, it's important to 
anticipate unlikely, but painful, eventualities, and be very specific, 
in advance, as to how those cases are to be handled -- the goal being to 
maintain continuity of operations and avoid protracted legal disputes.

I remain unconvinced that the IETF "could work around any problems with 
protocol parameters" if those problems take the form of contract 
disputes and legal battles.

Just to use one example:  ICANN just spent a lot of time and money, in 
Federal Court, defending against the attachment of a series of domain 
names.  In large part, the decision in ICANN's favor hinged on technical 
legal issues - notably, the court rules that "country code top level 
domains are not subject to attachment in the District of Columbia."  
That ICANN prevailed was not a matter of "working around any problems" - 
it was a result of making some very good decisions in advance, as to 
contractual and jurisdictional matters associated with domain name 
registration (i.e., the "fine print").

The legal and contractual stuff matters.  A lot.  I remain puzzled that 
this "does not seem to sink in despite having been explained a number of 
ways by a number of people."

Miles Fidelman

---

From: Seth Johnson <[email-masked]>
Date: Sun, 16 Nov 2014 18:49:11 -0500

> I cannot stress enough how important it is that we have the right transition plan, and have a strong system that can withstand various kinds of pressures and contingencies.

Yes indeed.  :-)

> But here I disagree strongly. I think we all are acting with integrity, forethought, and careful consideration.

Very good.  I didn't exactly say folks weren't acting with integrity,
forethought and careful consideration, though I get your point.

> But that is not the key point here. We are here to have that strong system, but it does not necessarily follow that we need a new system.

I'm not advocating the transition plan come up with a new system for
the IANA functions.  I'm solely advocating that the transition plan
acknowledge effects that can occur, and head those off with
appropriate language.  I would also articulate the process's nature in
a way that I believe is more methodical so effects can be observed.

> The IETF protocol parameters arrangement has been evolving for 15 years, and during that time we have continuously strived for that strong system. Every RFC, every agreement, every arrangement has been made with that in mind. Now, the WG obviously is the place to decide whether the arrangements described in the document are sufficient. But I think we should have that argument on the merits of the arrangements (and we have) rather than how much the arrangements changed.
>

Again, I completely support the purpose of continuing the process as
it has existed.  The charter is also very specific on that.  I do not
advocate making the plan change the process, though if an effect
occurs we might say the organization may have to do something about
that.  The reason I speak is that the process may not continue as
expected as we undergo the transition, and I only advocate that the plan
anticipate effects that we don't want to see come to pass.

Seth

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 16 Nov 2014 23:57:48 +0000

> ways by a number of people."

People have tried to help you I think. The legal stuff matters far less
if we have a work around that means any legal attack is going to be
ineffective or legal problem is going to be avoided. In this case, and
as stated numerous times and still unacknowledged by you, we do have
that possibility as a fine back up in the event of problems. (Not that
we expect to need to exercise it, but it's pretty obvious we could.)

If you have some example of where someone has spent lots of time and
money related to how the IETF use protocol parameters that might be
interesting. But so far, you don't seem to. (Examples related to names
are not relevant for discussion.)

And fair enough that you're not convinced, but it's clear a lot of
others, me included, are convinced that we can work around things here
if need be.

And I'd be grateful if you'd at least have the good grace to
acknowledge that the position that the IETF can avoid potential legal
silliness here is tenable, even if you do not agree that that's in
itself a sound basis for planning.

Thanks,
S.

---

From: Seth Johnson <[email-masked]>
Date: Sun, 16 Nov 2014 18:59:59 -0500

(One insert at bottom)

> anticipate effects that we don't want to see come to pass.

The plan can acknowledge problems that can occur, but what to do about
them it doesn't have to get into.

(eom)

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 16 Nov 2014 19:04:06 -0500

Folks,

In reviewing the original ICG RFP (conveniently included as an 
attachment to the IETF draft), I'm drawn to the following language:

"Members of the ICG will ensure that the communities from which they
    are drawn are working on their part of the transition plans. This
    involves informing them of requirements and schedules, tracking
    progress, and highlighting the results or remaining issues.  The role
    of a coordination group member during this phase is to provide status
    updates about the progress of his or her community in developing
    their component, and to coordinate which community will develop a
    transition proposal for each area of overlap (e.g., special-use
    registry)."

It strikes me that now would a good time for "Members of the ICG" to 
provide some feedback on the degree to which the process and draft, to 
date, are responsive, or otherwise.

Personally, I feel Milton has provided some good feedback, but he does 
not represent the protocol parameters community on the ICG. The 
following folks do, and one would think might have some relevant 
feedback to offer on the IETF proposal and process to date.  One would 
hope that each of them is monitoring this discussion.

IAB 		Russ Housley
IAB 		Lynn St Amour
IETF 		Jari Arkko
IETF 		Alissa Cooper
ISOC 		Narelle Clark
ISOC 		Demi Getschko

Miles Fidelman

---

From: Seth Johnson <[email-masked]>
Date: Sun, 16 Nov 2014 19:14:43 -0500

Miles is in earnest.  Adducing contractual language to address
concerns is a perfectly appropriate suggestion, the way we should
expect people to try to contribute to this process.  That I advocate a
more generalized approach does not mean I see anything in the
slightest wrong with his suggestions (And I might even endorse them.
I just don't approach things by that particular approach -- much like
you.  I have a certain kind of "technical" approach to processes).
They clearly should be treated as within the scope of good practical
conceptions worth addressing in the conversation.  The difficulty
should be choosing among a gamut of good ideas, not excluding
"lawyering."  :-)

Seth

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 16 Nov 2014 19:27:01 -0500

> we expect to need to exercise it, but it's pretty obvious we could.)

With all due respect, I don't need "help" to understand the issues or 
the opinions.  We simply disagree.

And, I'm not sure that's an accurate representation of a consensus 
opinion.  I've heard three different forms of "work around:"

- put all the protocol number info in the public domain, if necessary 
start publishing under a different domain -- I've seen a wide range of 
opinions as to whether that would be a satisfactory or sufficient 
work-around

- leave legal and contractual matters to others (let's not deal with the 
issue in this WG)

- the IAB and IAOC can deal with contractual and legal conflicts in the 
future

> itself a sound basis for planning.

I'm actually not sure I can, in good consciousness, do that.  Of course 
the group can decide to avoid dealing with "legal silliness" now.  But, 
to me, that is practically a guarantee of having to deal with it at some 
point in the future.

Miles Fidelman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Nov 2014 00:42:00 +0000

Hiya,

On 17/11/14 00:27, Miles Fidelman wrote:
>> acknowledge that the position that the IETF can avoid potential
>> legal silliness here is tenable, even if you do not agree that
>> that's in itself a sound basis for planning.
> 
> I'm actually not sure I can, in good consciousness, do that.  

Doing that while sleeping is also fine and might not trouble
your conscience:-)

> Of
> course the group can decide to avoid dealing with "legal silliness"
> now.  But, to me, that is practically a guarantee of having to deal
> with it at some point in the future.

I'll just count that as yet another case where those espousing a
more lawyered-up draft are arm-waving about potential but never
explicitly stated supposedly-specific issues at some point in
the future.

Frankly, that continued arm-waving whilst never acknowledging the
validity of the position of those who actually do practice the art
of dealing with real IETF protocol parameters is best IMO described
as risible.

S.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 17 Nov 2014 14:12:23 +1300

On 17/11/2014 13:27, Miles Fidelman wrote:

> ...  Of course the group can decide to avoid dealing with
> "legal silliness" now.  But, to me, that is practically a
> guarantee of having to deal with it at some point in the
> future.

Maybe. But the draft doesn't say that the IETF is immune from
having to deal with legal silliness. It says that contractual
and intellectual property issues are managed for the IETF by
the IAOC and IETF Trust, and that "The IAB, on behalf of the
IETF, has the responsibility to define and manage the
relationship with the protocol registry operator role."
It isn't conceivable to me that such matters, including taking
advice from counsel as needed, can be resolved by a
self-selected group such as this WG. We can reach rough
consensus on principles, but that's where it ends.

   Brian

---

From: JFC Morfin <[email-masked]>
Date: Mon, 17 Nov 2014 01:45:31 +0100

At 23:08 16/11/2014, Miles Fidelman wrote:
>4. These issues should be addressed, in the IETF proposal (WG draft 
>or otherwise), with very clear, concise, and strong language (at the 
>level of SHALL and MUST statements), with the intent of avoiding 
>protracted disputes (and possibly court hearings) in the event of a 
>hostile cancellation.

5. The roots of the technical governance and internet technology 
architecture are moving towards accountability to stakeholders and 
security.  The fudamentals of the IETF (organization, Tao, technical 
culture, IAOC structure, BCP 78, etc.) MUST be set in order that its 
self-organized criticality mechanism protects the stability of the 
end to end internet and the users' sure and secure operations 
necessary to the credibility and utility of names and numbers.

This WG is to explains the hows and the stress tests of this 
mechanism and who will be accountable for its precautionary 
maintenance, along which terms, incuding a fail-safe contingency 
plan, the internet governance multistakeholders may consensually trust.

Todate, I see no other alternative sanction to failures/conflicts to 
the past non-renewal of the ICANN contract by the NTIA, than
- an IETF fork that will attempt to make a better job at the WG 
charter in the new internet context I described in another mail
- unless the IAB is entrusted final sanction over ICANN and is 
credible as a responsible facilitator of competitive innovation.

jfc
---
"vox clamens in deserto"

---

From: Jari Arkko <[email-masked]>
Date: Sun, 16 Nov 2014 15:56:19 -1000

Seth,

> anticipate effects that we don't want to see come to pass.

Thanks for this. I think we are in agreement on the general principles at least :-)

Jari

---

From: John C Klensin <[email-masked]>
Date: Sun, 16 Nov 2014 21:46:40 -0500

--On Sunday, November 16, 2014 16:37 -0500 Andrew Sullivan
<[email-masked]> wrote:

>...
> I think this is exactly right.  But I think part of the
> controversy may be that some disagree about the consequences.
> Let me describe two caricature positions, neither of which
> represents any actual person AFAICT, to suggest where the
> poles of disagreement are in my opinion.
> 
> Some of us, it appears, think that this is an extremely
> delicate matter for the protocol parameters registries as well
> as for other registries.  It appears to me that those who
> think this feel strongly that it is important now to arrange
>...
> Others of us, it appears, think that the existing arrangements
> for the protocol parameters registries are perfectly adequate,
> and the only goal here is to do every possible thing to ensure
>...
> Now, having drawn those cartoon versions of the positions, it
> seems to me that most of us fall somewhere in between these
> views.  It also seems to me that the closer one is to the
> first of these, the more one might be uncomfortable with some
> of the changes from -02 to -03.  My own impression is that the
> WG mostly leans toward the second end of the spectrum.  If
> that's correct, then a couple things fall out.  
>...

Andrew, 

I share your belief about the leanings of the WG, but let me
suggest that there is a third position floating around and that
people who hold it are struggling to find a reasonable position
and to explain their views to others, more or less within the
constraints of the WG and, in the process, are perhaps confusing
a lot of people.  I've learned a lot more about that position
from some off list notes and conversations than in the
mainstream discussion on the list.   Let me try to caricature
that third position:

It starts from a view that, since ICANN's inception, NTIA's most
important role has not been any of the formalities of contracts
or oversight but as a guarantor of ICANN's good behavior.  From
that perspective, ICANN has periodically appeared to be much
more interested in collecting input in order to document that
they have done so than to actually listening, has from time to
time proven exceptionally easy for various interests to capture,
and so on. Should things ever get really out of hand, NTIA's
involvement has provided a formal and, more important, informal,
appeal and review channel.  That channel is important even if it
is used as often as the IETF recall procedure.  None of that
suggests anything other than that IANA has worked and worked
well, at least as far as the protocol and related registries are
concerned, but, should Bad Things happen, NTIA has been the
community's potential last line of defense.   If one has that
point of view and shares what seems to be the general opinion in
the WG that IANA has been working well and that no oversight
other what the IETF/IAB have been applying is needed as long as
everything stays on the current course, then, with the exception
of that guarantor role, this exercise is essentially pointless
because all it can accomplish is to change "NTIA really isn't
involved in protocol parameters although they might, in theory,
step in" into "NTIA isn't involved in protocol parameters and
has given up whatever rights it had to step in". 

In addition, the IANA in its specific present form really isn't
very important to the operational Internet.  Yes, lists of
assigned values have to be kept somewhere and someone needs to
do it (that is, of course, how IANA got started in the first
place).  But, especially with the changes about approval of
assignment requests that were made starting in the first half of
the 1990s and the further changes made since ICANN took over the
function from USC-ISI, the job, at least for protocol
parameters, is basically a combination of a clerical-recording
one and a database management one.  Any significant change other
than, perhaps, moving the function intact to another body, would
be unpleasant and disruptive but an extension of the argument
some of us have made about why the domain name and even the name
"IANA" are not very important suggests that we, and the
Internet, would have no long-term trouble surviving a change,
even the most drastic one of splitting the function up and
assigning different parts of it to different parties under
unpleasant circumstances..

However, the guarantor role remains an issue because, with NTIA
out of the picture, if any of the things that people can
fantasize about going seriously wrong happen, the entire story,
short of discussions about ways for us to unilaterally pull the
plug and how painful that would or would not be, ends up being
entirely about ICANN accountability.  However, not only this WG,
but the ICG have been told that topic is out of scope.  

For anyone holding that view either as a primary one or as the
result of thinking about matters as outlined above, this
discussion is inherently deeply frustrating: the main, core,
issue cannot be addressed, it is reasonable to try to patch
around its edges by thinking about contracts, jurisdictions, or
penalties but few if any of the people whose positions lie on
the spectrum between the two you have identified want to have
those discussions, and so on.

> implications?"  Under this view, there is not a great
> significance, and the implications are matters of detail
> (important detail, but just details all the same).  Second,
> "What can we do to transition the process without screwing it
> up?"  Under this view, the answer is to do as little as
> possible, because the existing arrangements are good and
> working, and we have always believed that the main protection
> to the protocol parameters registries lay with the IETF's
> established (and sometimes used) ability to manage the
> publication of its registries as it sees fit.  

I don't suggest it and think it would be the wrong strategy, but
I hope that it is possible in principle for this WG to discuss
and reach a conclusion very different from the above and from
anything that has appeared in any version of the current
document.   That conclusion would be similar to one that our
technical/protocol WGs always have in principle: the ability to
say "wrong question" or "overconstrained solution space" and
just stop, either explicitly or implicitly suggesting that
NTIA's continuing in its current role, at least until other
issues are sorted out, is preferable to the present lines of
discussion.  Again, not a suggestion and not my preference, but
I think we might be seeing less frustration if we acknowledged
it as a logical and procedural poossibility.

best,
    john

---

From: Seth Johnson <[email-masked]>
Date: Sun, 16 Nov 2014 21:58:48 -0500

Thank you.  I still intend to offer a good set of inputs.
Unfortunately, I have my fingers in many things related to the
Information Society project these days and am still deciphering the
ITU Plenipot and what's getting geared up to happen based on that.
Those are things that have to be gotten out in front of.

Here's what I'll do: tomorrow I will force my brain, which lets me
amass hugely complex systems with the aid of mindmaps very well, but
which transforms into clear lines of commentary very gingerly, to
spend time on both of these concerns.  I may end up with something to
show on this IANA topic by late tomorrow.  I guess I should at least
have something practical to say even if it's not complete, that way.

Seth

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 17 Nov 2014 09:23:20 +0100

----- Original Message ----- 
From: "Peterson, Jon" <[email-masked]>
To: "Milton L Mueller" <[email-masked]>; <[email-masked]>; "Alissa Cooper" 
<[email-masked]>
Cc: <[email-masked]>; "Eliot Lear" <[email-masked]>
Sent: Sunday, November 16, 2014 8:04 PM
Subject: Re: [Ianaplan] Proposed text reflecting IETF91 discussion

SNIP

SNIP

>The ICG, perhaps ill-advisedly, asked
> the IETF for its response to this questionnaire.

The ICG, responding to the NTIA's request, asked the IETF to convene a 
process, open to the global multi-stakeholder community, to respond to its 
RFP.

>The response that the ICG
> legally-savvy techno-political body,

In my view, it should be the response of the global multi-stakeholder 
community.

>not a response based on something
> other than our consensus process,

Agreed, the IETF must use its own process.

>but the IETF's response with all the
> constraints and limitations that implies.

Agreed, but dismissing the views of those that are not regularly involved in 
the specification of protocol parameters is not, in my view, a constraint 
that should apply in this particular discussion.

SNIP

> Please, just let us resolve this - to us,

That is, I think, the crux of the matter: who is "us"?

I submit that, for the purposes of this exercice, "us" is not just the 
people who regularly work on protocol parameters, but also people who don't 
work on that, but are concerned with the issues related to the IANA 
transition.

>relatively trivial technical
> matter -

In view, our differences of views are not related to technical matters. 
They are related to non-technical matters, and even to whether or not there 
are any non-technical matters that are of any significance.

>to our own satisfaction.

Again, the key question is who to include in "our".

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 Nov 2014 09:29:53 +0100

Hi Milton,

Please see below.

On 11/17/14, 9:23 AM, Richard Hill wrote:
>
> Agreed, but dismissing the views of those that are not regularly
> involved in the specification of protocol parameters is not, in my
> view, a constraint that should apply in this particular discussion.

For what it's worth, I agree 150%.  While I am sure it was done with the
best of intentions, the argument has been made on this list several
times that those who are just joining this discussion and are not
regular participants of the IETF should have their views discounted. 
That approach suffers the fallacy of appeal to authority, and will lead
to a suboptimal result.  It's important to take Jari's words to heart,
and to pay attention to the argument and not the name on the "From" line.

Eliot

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 17 Nov 2014 09:44:15 +0100

>From: "Jari Arkko" <[email-masked]>
>To: "Miles Fidelman" <[email-masked]>
>Cc: <[email-masked]>
>Sent: Sunday, November 16, 2014 11:19 PM
>Subject: Re: [Ianaplan] Consensus process for IETF proposal (Was: Re: 
>Proposed text reflecting IETF91 discussion)
>
>Miles,
>
>Note that IETF working groups can and have been formed on topics beyond 
>mere
> technical matters, such as is the case with IANAPLAN. This is not to take 
> anything
>away from the role of operational or administrative committees such as the 
>IAOC.
>However, those committees operate largely on the direction of the IETF 
>community

Indeed, so there should not be any objection in principle to this group 
suggesting or recommending, or even requesting, that the IAOC do something.

As currently written, "03" implies that the IAOC should not do anything 
regarding the transition, so, in effect, it requests the IAOC not to do 
anything.

Thus, as I've said before, it prejudges a legal analysis of the issues.

As a consequence, "03" implies that this group has made a legal analysis and 
reached conclusions regarding legal effects.  In my view, this is not 
appropriate.

SNIP

>Anyway, from my perspective the working group is in charge of delivering a
>complete proposal that is sufficient for the proposal to be understood and 
>taken
>into execution. From my perspective they have done that.

>From my perspective, the proposal is complete only from a formal point of 
view, because it has made conclusions regarding legal matters that are 
outside the scope of this group.

In reality, from the substantive point of view, it is not complete, because 
the legal issues in question should be addressed somewhere, and the proposal 
does not provide any plan or mechanism for dealing with those legal issues.

>However, this does not mean that the working group will itself write every 
>detail. Obviously >we have a lot of documentation that the proposal points 
>to, such as existing RFCs. But just as is >likely with other community 
>plans, there are likely going to be statements of the form “X must >happen” 
>or “Y needs to be agreed with Z”. As long as X and Y are clearly described

Agreed.  We are disagreeing regarding whether X and Y are clearly described.

> this is what we can and should do at this stage. An obvious example is any 
> kind of an >agreement or contract with someone else - clearly the WG or 
> even the IETF cannot just say >those things, as other parties are 
> involved.

For sure the WG can and should express its point of view.  And it has, in 
particular to the effect that ICANN should continue to provide the protocol 
parameters part of the IANA function.

>Similarly, there is a role for experts to deal with their topic matters, 
>and we should not
>be the amateurs trying to do that ourselves.

I agree.  So why is the group prejudging complex legal matters, by 
concluding that no expert work is needed in that area?

Once again, it is my view that this group should request that the IAOC (or 
whoever) undertake the analysis of the legal issues that have been 
identified.

>I think that is clear enough to be understood.

It is clear.  It does not oblige anybody to do anything.  And it prejudges a 
legal analysis of whether or not "public domain" is the appropriate choice. 
As I've said before, I'm happy with  public domain, but my views on 
intellectual property are extreme, so I think that proper legal analysis, 
with evaluation of advantages and disadvantages, would be in order.

SNIP

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 17 Nov 2014 10:01:12 +0100

>To: "Seth Johnson" <[email-masked]>
>Cc: "Peterson, Jon" <[email-masked]>; "Milton L Mueller" 
><[email-masked]>; <[email-masked]>; "Alissa Cooper" <[email-masked]>; 
>"Eliot Lear" <[email-masked]>; <[email-masked]>
>Sent: Monday, November 17, 2014 12:07 AM
SNIP

>I cannot stress enough how important it is that we have the right 
>transition plan, and have a >strong system that can withstand various kinds 
>of pressures and contingencies.

Agreed.  So why shouldn't the plan include requests that legal experts take 
a look at the legal issues and suggest how best to handle them?

SNIP

>First off, the plan does have some changes, even if the general design is 
>the continuation of >existing arrangements. All relevant parties 
>acknowledging that the data is in the public domain, >for instance.

Yes, and in so doing it is prejudging a proper legal analysis.  Again, I'm 
personally happy with public domain, but I think that it would make sense to 
ask for a proper legal analysis.

>And I do not think it should be surprising that the IETF community thinks 
>largely in
> terms of continuation,

The disagreement hinges on whether or not the current IANA functions 
contract has any significance or effect.  Many think not, so logically they 
don't see any need to replace it with anything.  Some think yes, so 
logically they think that there is a need to replace it with something.

So the divergence of views is about how whether some replacement of the NTIA 
contract is needed in order to ensure continuity.

>given their high reliance on running code in other parts of their work. And 
>like with running >code, the fact that something runs doesn’t reduce our 
>need to be able to deal with bad outcomes >(security, errors, misbehaving 
>peers, scaling). We all try very hard to build safeguards for >those into 
>our specifications and code.

So why not build safeguards into a future contractual framework, given that 
some safeguards are contained in the current contractual framework?

Rethorical question, I know the answer: because the current contractual 
framework does not actually affect us, we don't need it, and we don't need 
any replacement for it.

I disagree with that.  Nobody knows whether or not things would have worked 
as well as they do now in the absence of the current contractual framework. 
So assuming that the current contract has no significance is, in my opinion, 
an unwarranted assumption.

It would be more prudent to assume that the current contract does have an 
effect, and thus to ensure that a future contractual framework has 
provisions comparable to the current contract.

SNIP

---

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

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Andrew Sullivan" <[email-masked]>; <[email-masked]>
Sent: Monday, November 17, 2014 3:46 AM
Subject: [Ianaplan] Caricature position 3 (was: Re: Proposed text reflecting 
IETF91 discussion)

SNIP

> suggest that there is a third position floating around

I agree, but I think that there are some nuances within the third position, 
see below.

> but the ICG have been told that topic is out of scope.

Not entirely.  It is well within the scope of this WG to identify issues 
(such as legal issues) for which further analysis is required, and to 
request that IAOC (or whoever) perform that analysis.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Nov 2014 10:00:35 +0000

Eliot,

On 17/11/14 08:29, Eliot Lear wrote:
> For what it's worth, I agree 150%.  While I am sure it was done
> with the best of intentions, the argument has been made on this
> list several times that those who are just joining this discussion
> and are not regular participants of the IETF should have their
> views discounted. That approach suffers the fallacy of appeal to
> authority, and will lead to a suboptimal result.  It's important to
> take Jari's words to heart, and to pay attention to the argument
> and not the name on the "From" line.

I strongly disagree that anyone has dismissed participant's
views. I and others have disagreed with views expressed by
some participants with a much less direct experience of
the handling of IETF protocol parameters. Disagreeing-with
is just not at all the same as dismissing. (However, if
you would like to quote some text demonstrating "dismissal"
that might help, it is quite possible that I or others
haven't been careful enough in writing.)

I do maintain that people with a working knowledge of how the
IETF works and what IANA do wrt protocol parameters have a
higher liklihood of being correct when they assert what is or
is not feasible, e.g. if ICANN ever misbehaved, and what is
or is not an issue that needs to be dealt with here and now.
And those are the only places that experience has come into
the discussion that I recall.

That is entirely like other IETF discussions - for example
when dealing with cryptographic primitives, you and I both
should and do defer quite a bit to those with more cryptographic
clue, especially where we do not have a concrete and specific
issue with an expert's opinion. Even our IANA processes
directly recognise this via the designated expert role. There
is not reason whatsoever that this discussion needs to use
some other novel (to the IETF) approach and ignore the reality
that some people understand the real details better than some
others.

If it's the case that a number of new participants have not
convinced the WG of their position then that is just how it
is. The fact that they are new participants does not privilege
their positions or opinions no matter how often they are
repeated.

S.

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 17 Nov 2014 11:09:23 +0100

----- Original Message ----- 
From: "Stephen Farrell" <[email-masked]>
To: "Eliot Lear" <[email-masked]>; "Richard Hill" <[email-masked]>; 
"Peterson, Jon" <[email-masked]>; "Milton L Mueller" 
<[email-masked]>; "Alissa Cooper" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 17, 2014 11:00 AM
Subject: Re: [Ianaplan] Proposed text reflecting IETF91 discussion

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Eliot,
>
> is not feasible,

This is a form of appeal to authority: person X know more so we should defer 
to her.

There is nothing wrong with that in principle and sometimes it is the right 
thing to do, see below.

> clue,

Indeed, that is a good example of where it is a good idea to defer to 
someone with expertise.

In the discussion at hand, the points of contention are related to legal and 
contractual matters, not to matters related to the development of protocol 
parameters.

What I'm  asking is that those matters be referred to the proper expert 
authority (presumaby the IAOC), rather than being dismissed as irrelevant by 
people who invoke their expertise withthe development and operation of 
protocol parameters as qualifications for deciding legal issues.

SNIP

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Nov 2014 10:22:50 +0000

On 17/11/14 10:09, Richard Hill wrote:
> 
> In the discussion at hand, the points of contention are related to legal
> and contractual matters, not to matters related to the development of
> protocol parameters.

But that is exactly the point you and others appear to be getting
wrong. If ICANN misbehave badly, we can develop and deploy a technical
and non-legal solution. It's just not that hard for protocol
parameters as has repeatedly been stated by those who are familiar
with how those are handled.

And you and others have not described any scenario in which that
wouldn't just work. Please specify a credible legal threat that
would invalidate that approach or else stop asserting a shibboleth.

S.

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 17 Nov 2014 11:33:38 +0100

----- Original Message ----- 
From: "Stephen Farrell" <[email-masked]>
To: "Richard Hill" <[email-masked]>; "Eliot Lear" <[email-masked]>; 
"Peterson, Jon" <[email-masked]>; "Milton L Mueller" 
<[email-masked]>; "Alissa Cooper" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 17, 2014 11:22 AM
Subject: Re: [Ianaplan] Proposed text reflecting IETF91 discussion

> and non-legal solution.

There is no disagreement on that point.  The disagreement is regarding 
whether it is worth taking steps now to (1) reduce the chance of that 
happening and (2) reducing the effort required to receover from such an 
event.

>It's just not that hard for protocol

So you are saying that only those who are familiar with how protocol 
parameters are handled are competent to discuss the matter.  You are of 
course entitled to your opinion, but that's not what the ICG asked the IETF 
to do.  The ICG asked the IETF to take into account everbody's point of 
view, including people who are not familiar with how protocol parameters are 
handled.

> wouldn't just work.

I have never disputed that it would work.  My point is that the effort 
required can be minimized by taking steps now.

>Please specify a credible legal threat that

John Klensin has explained in some detail how changing the current structure 
of the web pages under IANA.ORG might require some effort.

Thus, if the protocol parameters have to be moved elsewhere than IANA.ORG, 
there will be some disruption and some effort..

That disruption and effort can be avoided if the transition plan clearly 
specifies that IANA.ORG will contiue to be used for the protocol parameters 
no matter who performs the IANA function.

Similar considerations apply to the IANA trademark.  And to the provisions 
in the current IANA functions contract regarding transition.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Nov 2014 10:53:43 +0000

Richard,

On 17/11/14 10:33, Richard Hill wrote:
> 
> ----- Original Message ----- From: "Stephen Farrell" 
> <[email-masked]> To: "Richard Hill" <[email-masked]>;
> "Eliot Lear" <[email-masked]>; "Peterson, Jon"
> <[email-masked]>; "Milton L Mueller" <[email-masked]>;
> "Alissa Cooper" <[email-masked]> Cc: <[email-masked]> Sent:
> Monday, November 17, 2014 11:22 AM Subject: Re: [Ianaplan] Proposed
> text reflecting IETF91 discussion
> 
> 
>> 
>> 
>>> In the discussion at hand, the points of contention are related
>>> to legal and contractual matters, not to matters related to the
>>> development of protocol parameters.
>> 
>> wrong. If ICANN misbehave badly, we can develop and deploy a
>> technical and non-legal solution.
> 
> There is no disagreement on that point.  

So *finally* one of you do ack that this would work. Great!

> The disagreement is
> regarding whether it is worth taking steps now to (1) reduce the
> chance of that happening and (2) reducing the effort required to
> receover from such an event.

I'm a clear "no" to both. And I see a lot more fundamental
disagreement than that from you for example.

>> It's just not that hard for protocol parameters as has repeatedly
>> been stated by those who are familiar with how those are handled.
> 
> parameters are handled are competent to discuss the matter.  

Rubbish. That is nothing whatsoever like what I said. I would be
happy to see you retract that baseless accusation. (But equally,
I just don't care if you do or not:-)

> You are
> of course entitled to your opinion, but that's not what the ICG asked
> the IETF to do.  The ICG asked the IETF to take into account
> everbody's point of view, including people who are not familiar with
> how protocol parameters are handled.

I interpret that as a continuation of your baseless attempt
to distract. Please desist in that.

> I have never disputed that it would work.  My point is that the
> effort required can be minimized by taking steps now.

Feel free to tell me exactly how. But of course you cannot, since
as has also been repeatedly pointed out, the right technical
work around would depend on a number of things that cannot be
known now (e.g. the state of the web, today we might use a github
like approach, that won't be true in 5 years; the right thing
to do will also depend on the specific triggering misbehaviour).
There's no benefit in speculation about such things now.

>> Please specify a credible legal threat that would invalidate that
>> approach or else stop asserting a shibboleth.
> 
> John Klensin has explained in some detail how changing the current 
> structure of the web pages under IANA.ORG might require some effort.

Yes, and he also correctly made the above point that it's pointless
speculating on that right now.

> Thus, if the protocol parameters have to be moved elsewhere than 
> IANA.ORG, there will be some disruption and some effort..
> 
> That disruption and effort can be avoided if the transition plan
> clearly specifies that IANA.ORG will contiue to be used for the
> protocol parameters no matter who performs the IANA function.

No. Again that has been repeatedly pointed out (e.g. by Andrew).
If ICANN ever start messing about wrt protocol parameters then
they will be able to cause probably about the same level of
annoyance regardless. And we can work around that regardless for
protocol parameters.

> Similar considerations apply to the IANA trademark.  

With the same answer. Actually even easier - we just call it
another thing, e.g. BLAHBLAH, or schmiana as has also been
previously stated.

> And to the 
> provisions in the current IANA functions contract regarding
> transition.

Please specify exact provisions and exactly how those are
relevant to the handling of protocol parameters. Arm-waving
such as this at this point in the process is something that
I believe ought be frowned upon.

But, at least we finally have an acknowledgement from you
that you agree that a technical work around will suffice.
That may perhaps be progress.

S.

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 17 Nov 2014 12:06:03 +0100

----- Original Message ----- 
From: "Stephen Farrell" <[email-masked]>
To: "Richard Hill" <[email-masked]>; "Eliot Lear" <[email-masked]>; 
"Peterson, Jon" <[email-masked]>; "Milton L Mueller" 
<[email-masked]>; "Alissa Cooper" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 17, 2014 11:53 AM
Subject: Re: [Ianaplan] Proposed text reflecting IETF91 discussion

> to distract. Please desist in that.

I interpret that as a continuation of  your desire that I stop contributing 
to this discussion.

> Feel free to tell me exactly how.

I have done so repeatedly, for example by proposing that the response to ICG 
request that ther IANA.ORG domain name and the IANA mark be transferred to 
the IETF Trust.

>But of course you cannot,

I can, see above, but you don't think that this is worth doing, which is 
what you say in what I snip below (because it has been said over and over).

SNIP

> Please specify exact provisions

They were specified with precision in draft "02".

SNIP

> that you agree that a technical work around will suffice.

It suffices in the sense that it is a possible way to deal with the issues.

I do not think that it suffices as a proper response to the ICG's RFP.

SNIP

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Nov 2014 11:22:16 +0000

On 17/11/14 11:06, Richard Hill wrote:
> Monday, November 17, 2014 11:53 AM Subject: Re: [Ianaplan] Proposed
>>> <[email-masked]> To: "Richard Hill"
>>> <[email-masked]>; "Eliot Lear" <[email-masked]>; "Peterson,
>>> Jon" <[email-masked]>; "Milton L Mueller"
>>> <[email-masked]>; "Alissa Cooper" <[email-masked]> Cc:
>>> <[email-masked]> Sent: Monday, November 17, 2014 11:22 AM
>>> You are of course entitled to your opinion, but that's not what
>>> the ICG asked the IETF to do.  The ICG asked the IETF to take
>>> into account everbody's point of view, including people who are
>>> not familiar with how protocol parameters are handled.
>> 
>> I interpret that as a continuation of your baseless attempt to
>> distract. Please desist in that.
> 
> I interpret that as a continuation of  your desire that I stop 
> contributing to this discussion.

No. I desire that you stop making (IMO bogus) claims that you are
being excluded when I and others are simply saying you are wrong
and basing our argument on experience with protocol parameters.

Would you prefer to be told you're wrong by people who do not
know about protocol parameters or something? ;-)

>>>> And you and others have not described any scenario in which
>>>> that wouldn't just work.
>>> 
> I have done so repeatedly, for example by proposing that the response
> to ICG request that ther IANA.ORG domain name and the IANA mark be 
> transferred to the IETF Trust.

And that has repeatedly been refuted by Andrew where he pointed
out that such a request/demand has downsides and is better not
done anyway as it is impossible to know if such a transfer now
would or would not save effort later, so there's also no very
concrete upside.

> I can, see above, but you don't think that this is worth doing, which
> is what you say in what I snip below (because it has been said over
> and over).
> 
> SNIP
> 
>>> And to the provisions in the current IANA functions contract
>>> regarding transition.
>> 

I do see some references to C.7.3 and I.61 in the diff
between -02 and -03. If you have a specific reason why those
references are still needed then I would suggest that you
start a new thread on just that topic.

> 
> SNIP
> 
>> 
>> But, at least we finally have an acknowledgement from you that you
>> agree that a technical work around will suffice.
> 

So yet another "I disagree for some unstated reason" arm-wave? If
you have a specific reason why the draft as a whole does not do
that, then start a thread on that with your suggested text and
see if folks like it or not. Of course the "technical work around
means fewer issues" point is not in itself the entire draft.

S.

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

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 17 Nov 2014 12:29:45 +0100

----- Original Message ----- 
From: "Stephen Farrell" <[email-masked]>
To: "Richard Hill" <[email-masked]>; "Eliot Lear" <[email-masked]>; 
"Peterson, Jon" <[email-masked]>; "Milton L Mueller" 
<[email-masked]>; "Alissa Cooper" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 17, 2014 12:22 PM
Subject: Re: [Ianaplan] Proposed text reflecting IETF91 discussion

> know about protocol parameters or something? ;-)

Yes, I am asking that my points be evaluated by people who know about legal 
and contractual issues.  All I'm asking is that the issues in questions be 
submitted to competent experts, such as the IAOC.

You, and others, take the view that it is obvious that there is no need to 
submit such issues to such experts.

But I submit that only the experts can decide whether or not the issues are 
consequential enough to require actions, such as new contractual clauses.

SNIP

> that,

I have done my best to attempt to explain that.

>then start a thread on that with your suggested text

No need to start a thread,  I have already suggested text, and my proposal 
was rejected.  The rejection is not an issue per se, but I think that it is 
an issue because of the reasons for the rejection.

Since we've aired that topic at length, I propose that we agree do disagree.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Nov 2014 11:38:01 +0000

On 17/11/14 11:29, Richard Hill wrote:
> Yes, 

Ah. Unfortunately for you the current IAOC members [1] almost
certainly do know how all this stuff works:-)

> I am asking that my points be evaluated by people who know about
> legal and contractual issues.  All I'm asking is that the issues in
> questions be submitted to competent experts, such as the IAOC.
> 
> You, and others, take the view that it is obvious that there is no need
> to submit such issues to such experts.
> 
> But I submit that only the experts can decide whether or not the issues
> are consequential enough to require actions, such as new contractual
> clauses.

Please see Jari's mail from yesterday where he explains how the
IETF process works here.

S.

[1] http://iaoc.ietf.org/members.html

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 17 Nov 2014 08:04:04 -0500

> explicitly stated supposedly-specific issues at some point in

It's really, really, simple.  You don't buy insurance because you expect 
catastrophe, you buy it to reduce risk in the eventuality of a highly 
unlikely catastrophe.  The same logic applies to contracts.  If you 
think unfortunate events are likely, then you don't enter into a 
contract in the first place.  The contract terms are insurance for edge 
cases.

> of dealing with real IETF protocol parameters is best IMO described

Leaving aside, that I have.... just because an issue is neither 
technical, nor operational, doesn't mean it doesn't exist.

Miles Fidelman

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Nov 2014 13:28:07 +0000

Miles,

On 17/11/14 13:04, Miles Fidelman wrote:
>>>> acknowledge that the position that the IETF can avoid
>>>> potential legal silliness here is tenable, even if you do not
>>>> agree that that's in itself a sound basis for planning.
>> Doing that while sleeping is also fine and might not trouble your
>> conscience:-)
>> 
>>> Of course the group can decide to avoid dealing with "legal
>>> silliness" now.  But, to me, that is practically a guarantee of
>>> having to deal with it at some point in the future.
>> explicitly stated supposedly-specific issues at some point in the
>> future.
> 
> It's really, really, simple.  You don't buy insurance because you
> expect catastrophe, you buy it to reduce risk in the eventuality of a
> highly unlikely catastrophe.  The same logic applies to contracts.
> If you think unfortunate events are likely, then you don't enter into
> a contract in the first place.  The contract terms are insurance for
> edge cases.

Yes, that is simple. But fully unresponsive. You are not stating
any specifics at all, but just generalising about insurance and
contracts.

>> of dealing with real IETF protocol parameters is best IMO
>> described as risible.
> 
> Leaving aside, that I have.... 

I have not seen you agree it is reasonable to conclude that a
"technical" approach of just working around the legalities is
sufficient (for this topic, for protocol parameters).

Richard has (eventually) done so but if you did earlier, I'm
sorry but I've forgotten and maybe you could send a pointer to
the archive for that message? (Or just agree now:-)

To be clear: I have seen you ack that those arguing against
you are reasonable people, but I've not seen you ack that its
quite possible that they (incl. me:-) are correct and you are
wrong.

> just because an issue is neither 

But a technical work around in this case can be (and I think is,
for protocol parameters) sufficient, in which case we're done on
that issue and do not need to enter into any legal or other
potential quagmires. If we're happy we can work around potential
ICANN misbehaviours that way, then we're done with this specific
topic I'd say. So while your statement is in general true, it
is not relevant in this case.

If your claim is that a technical work around cannot be sufficient
for this topic, for protocol parameters, then please show me the
convincing arguments. (And that "cannot" has to be your claim
unless you've ack'd that my position is reasonable above or
earlier.)

And please do that bearing in mind that a succession of people who
are constantly dealing with protocol parameters have said that they
do think that is quite doable. And have also said that we don't
need to or should try decide the details now. And to be clear, that
is not an argument from authority, it's asking you to make your case
in sufficient detail to convince those who we know do protocol
parameter stuff all the time.

S.

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 17 Nov 2014 08:58:59 -0500

> consensus on principles, but that's where it ends.

Just to be clear,
- assuming that there is going to be a single response to the ICG RFP, 
from the IETF, representing the protocol parameters community, and,
- that the document we've been working on is going to be that response,

And noting that,
- from an organizational and legal perspective, the IAB and IAOC are 
components of IETF, not separate entities,
- the IETF is organizationally part of ISOC,
- and the IETF Trust is a contractual agreement, not a separate legal 
entity,

By chartering this WG to produce the document, but,
- excluding a broad class of issues from consideration (as "managed for 
the IETF by <other parts of IETF>,"
- and stopping at "rough consensus on principles,"

You're saying that the IETF, representing the protocol parameters 
community, CAN'T OR WON'T MEET the ICG RFP requirements to:
- deliver a "complete formal response" (as in a complete, single 
document, on the letterhead of a legal entity),
- "supported by the broad range of stakeholders participating in the 
proposal development process,"
- "developed through a transparent process that is open to and inclusive 
of all stakeholders interested in participating in the development of 
the proposal."

Or am I missing something?

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 17 Nov 2014 09:01:46 -0500

I'd concur with this.

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 17 Nov 2014 09:20:59 -0500

Richard Hill wrote:
> <[email-masked]>
> This is a form of appeal to authority: person X know more so we should 
> defer to her.
>
> There is nothing wrong with that in principle and sometimes it is the 
> right thing to do, see below.
>
>>
> In the discussion at hand, the points of contention are related to 
> legal and contractual matters, not to matters related to the 
> What I'm  asking is that those matters be referred to the proper 
> expert authority (presumaby the IAOC), rather than being dismissed as 
> irrelevant by people who invoke their expertise withthe development 
> and operation of protocol parameters as qualifications for deciding 
> legal issues.
>

Or, even better, that they be directly engaged in this discussion as 
advisers.  It's  been my experience that one gets far better legal and 
contractual advice through interaction than through delegation. 
Sometimes one needs input before one has arrived at the right questions, 
or the right assignments.

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 17 Nov 2014 09:30:54 -0500

> would invalidate that approach or else stop asserting a shibboleth.

"can develop and deploy a technical and non-legal solution" does not 
mean that doing so is optimal, without cost, or impact, or the ideal 
response of first resort

I think we can all agree that operational disruption, and protracted, 
expensive legal disputes, are things to be avoided.  And that lesser 
annoyances, like confusion in user communities, and having to change all 
references to iana.org in documents, are not desirable.

Yes, there are technical and non-legal solutions, but why the vehement 
objection to proposing contractual and legal terms & conditions that 
might avoid the need to do so? Is not rectification of disagreements, or 
smooth transition to a new IANA functions contractor, the preferred 
outcome of a dispute?

Miles

---

From: JFC Morfin <[email-masked]>
Date: Mon, 17 Nov 2014 15:30:59 +0100

Dear Andrew,

Your analysis of the WG's attitudes is excellent!

This helps me a lot in explaining why I am "elsewhere" rather than in 
your scheme, why I think everyone is right, and where consensus is and why.

The IETF has an engineering culture, the IAB an architectural 
culture, and mine is difficult to follow for both. This is because it 
is an architectonical culture.

- Engineers work out detailed solutions within architectures;
- Architects choose global solutions that fit a common architectony;
- Architectonicians' job is to try to build an architectony, i.e. to 
comprehend and document how things work. This means that they are 
partly mathematicians, partly philosophers, partly politicians, etc. 
This is the Greek meaning of "archi", regarding what is below (and 
common to) everything. In particular due to cybernetics, logic, 
quantum physics, meshed networking, globalization, multilinguistics, 
multistakeholderism, etc. this is the intermultidisciplinarity of the 
"(g)locality problem".

Architectonics has dramatically progressed in the last 125 years and 
networking has contributed a lot (in particular in the agoric [meshed 
logic] way of thinking that addresses complexity). The target is to 
understand how our fractally deterministic chaos (nature, society, 
events, politics, groups, IETF decisions, etc.) works. E.g. how I 
obtained the RFC 4646 consensus I wanted.

This is called "SOC", self-organized criticality, studied from the 
Per Bak or Abelian sand pile model. 
<http://en.wikipedia.org/wiki/Abelian_sandpile_model>http://en.wikipedia.org/wiki/Abelian_sandpile_model. 
This should be conceptually linked to:
- the "n-body" issue of Poincaré
- the Catastrophe Theory of René Thom
- the metamaths  of Gregory Chaitin
- Jon Postel's principle of robustness (RFC 1122)
- Randy Bush's and David Meyer's principle of simplicity (RFC 3439)
to lead to what one might call the "Leibnitz Principle": "the 
simplest the premise, the richest the emergence". E.g.: the 
bit/big-bang => the universe.

This means that the target is to find and address the IETF's NTIA 
transition "least common factor". This is what I am interested in. It 
looks like the status quo, it smells like the status quo but it is 
not the status quo.

I think this is nearly completed already (if an inadequate draft does 
not confuse everything – in that case it will be rebuilt outside of 
the IETF). On Sept. 30, 2014, IAB has been recorded in the IANA as 
the .arpa TLD manager. In order to complete the 2000 NTIA prepared 
transition and best settle the IETF position, IAB only has to 
register "iana.arpa" and make it parked at "iana.org" and use it. 
Everything else will follow in due time.

IAB has no army to enforce its positions. It has the .arpa TLD where 
it is sovereign. These are its "Pope's divisions of Stalin".

jfc

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Nov 2014 14:40:32 +0000

Hiya,

On 17/11/14 14:30, Miles Fidelman wrote:
> 
> Yes, there are technical and non-legal solutions, 

So you also agree that those solutions are feasible. Great.

> but why the vehement

It's not vehement, at least on my part. It does seem to be requiring
an awful lot of email, which may give the impression there's vehemence
involved, but really, there isn't. (Dogged would perhaps be fair:-)

It's mostly that there is no need for anything else. That is, we
have a sufficiently good solution in hand should one ever be needed,
so we're done and should just move on.

I've not been convinced that anything else is needed, nor that any
legal or contractual finessing here is sufficiently attractive to be
worth exploring, given that we already have a good enough way
forward.

Cheers,
S.

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 17 Nov 2014 09:53:11 -0500

> So you also agree that those solutions are feasible. Great.

Feasible, but not optimal, or necessarily desirable.

> involved, but really, there isn't. (Dogged would perhaps be fair:-)

Fair enough.  Same here. :-)

> worth exploring, given that we already have a good enough way

And you've made it crystal clear that you don't see a need for anything 
else, perhaps to the point of making it clear that your mind is made 
up.  As is mine, I might add.

As an aside, the best example that comes to mind is back, in the old 
days, when the Michigan Bell decided it didn't want to sell dark fiber 
to the Merit regional network, and de-tariffed their offering.  Yes, 
"the Internet routes around failure" to a degree, but what saved the day 
ultimately was 800 pound gorillas (the automakers) who's enterprise 
networks were threatened that kept bad things from happening.  Today's 
disruptions over peering agreements also come to mind.  Sometimes, maybe 
often, technical solutions just don't cut it

Miles Fidelman

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Nov 2014 08:21:36 -0800

Indeed, the IAOC is chartered under RFC 6220 with handling contractual issues with the Protocol Parameter operator. This was never in scope for the IANAPLAN WG.

> On Nov 16, 2014, at 5:12 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 17 Nov 2014 13:42:05 -0500

At the risk of sounding like a broken record...

This brings us back to:
- the RFP is largely about contractual issues (what replaces the NTIA 
contract), and,
- the requirement for open process
- if this is an IAOC matter, then what is the open process for 
discussing things that are in the IAOC purview

---

From: Jefsey <[email-masked]>
Date: Mon, 17 Nov 2014 20:22:26 +0100

At 19:42 17/11/2014, Miles Fidelman wrote:
>- the RFP is largely about contractual issues (what replaces the 
>NTIA contract), and,

Miles,
this seems odd to have to explain that when dealing with network 
engineers, but what we need is a consensual cultural network among 
the IETF participants about what we want to see achieved. Then things 
will work alone being intellectually "meshed", i.e. understood in the 
same way. Otherwise things will disband, both at the internet 
governance and at the technology planes.

What all this debate shows is the same problem the IETF faces again 
and again. The IETF is to make the internet work better. What does 
"better" means? Does it means directed by ICANN, or Govs, or the 
people's multitude, perfect end to end non-protected transport, 
confidential traffic? Who is accountable to who (for dogmatic but 
also for technical reasons)?

jfc

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 17 Nov 2014 23:56:57 -0500

> agreement of those named.

At least in Internet Drafts or RFCs there is no implication that
someone listed in the acknowledgments section supports the document or
any part of it. IETF policy and I believe copyright law requiring the
listing of anyone who has made a significant contribution, because
that makes the work at least partly of their authorship, unless they
opt out.

I have edited IETF documents and, while my policy may be more liberal
than others, I tend to acknowledge anyone whose comments or
suggestions have resulted in any non-trivial wording change. Such
comments might, for example, have improved the wording of or clarified
some section with which the commenter disagreed. I generally inform
people when adding them to the acknowledgements section so they can
ask to be removed if they want and I always remove people's names if
they ask. In one case that I remember, because I was sure the
commenter had extreme opposition to the document, I checked a couple
of times by email and once in person to confirm that this person
really did want to be listed in the acknowledgements section despite
their opposition to the document.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> Now, if there were to be minority opinions attached, that would be a more
> accurate reflection of the situation.
>
> Miles Fidelman
>
> --

---

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

> This isn't an ethics matter or a conflict of interest matter even - it just defeats
> the purpose of process. The ICG, perhaps ill-advisedly, asked the IETF for its
> response to this questionnaire. 

That is not quite correct, and I think that basic misunderstanding of what is going on here accounts for your overreaction to my previous comment. 

The ICG asked the IETF to convene a process to develop a proposal for the protocols part of the IANA transition. As noted from my quote of the RFP, that process _must_ be open and _must not_ exclude people. The IETF is just the convenor of the process, and of course it is expected that the normal IETF community would have the greatest interest in and play the biggest role in the process. But the ICG is looking for proposals that have consensus amongst the entire group convened. I am not issuing threats, I am simply pointing out that comments you are making, to the effect that people who are engaged in the process but not routine participants in IETF somehow don't count, could be used as evidence that the process was not open. 

--MM

---

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

Andrew:
Nice job here--

> Some of us, it appears, think that this is an extremely delicate matter for the
> protocol parameters registries as well as for other registries.  It appears to
> me that those who think this feel strongly that it is important now to arrange
> the adoption of several provisions.  It appears that those holding this
> position think that the existing arrangements are open to negotiation in
> order to achieve some of these other ends.
> 
> Others of us, it appears, think that the existing arrangements for the protocol
> parameters registries are perfectly adequate, and the only goal here is to do
> every possible thing to ensure that those arrangements don't change an iota
> as a result of the transition.  It appears to me that those who think this feel
> strongly that there are no new provisions to be made, though there might be
> things that currently follow as a result of the NTIA-ICANN agreement; those
> position think that there is nothing more important than avoiding opening
> any existing agreement for any kind of negotiation.

I think that's a pretty good characterization of the positions, actually. Not a cartoon.

> that the closer one is to the first of these, the more one might be
> uncomfortable with some of the changes from -02 to -03.  My own
> impression is that the WG mostly leans toward the second end of the
> spectrum.  If that's correct, then a couple things fall out.

Really, all I am suggesting is that it would not be difficult for the supporters of -03 to make a few changes that would satisfy the supporters of -02, while retaining the fundamentals of their view. Is there a willingness to find agreement, or merely a confidence in your majority status that makes you think you can "win" what is in effect a zero sum power game rather than a game involving persuasion and better ideas?

> 
> First, "How do we understand the transition's significance and implications?"
> Under this view, there is not a great significance, and the implications are
> matters of detail (important detail, but just details all the same).  Second,
> "What can we do to transition the process without screwing it up?"  Under
> this view, the answer is to do as little as possible, because the existing
> arrangements are good and working, and we have always believed that the
> main protection to the protocol parameters registries lay with the IETF's
> established (and sometimes used) ability to manage the publication of its
> registries as it sees fit.
> 
> Best regards,
> 
> A
> 
> --
> Andrew Sullivan
> [email-masked]
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Nov 2014 13:42:27 +0000

On 18/11/14 12:41, Milton L Mueller wrote:
> I am not issuing threats, I am simply pointing out that comments you
> are making, to the effect that people who are engaged in the process
> but not routine participants in IETF somehow don't count,

That's a false statement. Nobody said "don't count." If you claim
that is true, please send a relevant pointer to the list archive.

People, me included, noted the notable difference in opinions
between those who do, and those who do not, commonly handle protocol
parameters. With you being one of the latter.

I also noted that it's typical for us in the IETF to pay more
attention to the opinions of experts compared to novices. Even
our IANA protocol parameter processes themselves recognise this
as valid via the designated expert designation.

I'm also sure that the editors have paid attention to the gigantic
number of emails from you and others referred to as novices
above and that your contributions have influenced the draft.

You're perhaps just in the rough (which is the chairs' call)
and IMO additionally just wrong on this particular topic.

To me, you appear to be attempting to cast doubt on the process
because you yourself may be in the rough. That is a very frequently
attempted tactic that I hope will be as deservedly unsuccessful
as always.

S.

---

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

----- Original Message ----- 
From: "Stephen Farrell" <[email-masked]>
To: "Milton L Mueller" <[email-masked]>; "Peterson, Jon" 
<[email-masked]>; <[email-masked]>; "Alissa Cooper" 
<[email-masked]>
Cc: <[email-masked]>; "Eliot Lear" <[email-masked]>
Sent: Tuesday, November 18, 2014 2:42 PM
Subject: Re: [Ianaplan] Proposed text reflecting IETF91 discussion

> attention to the opinions of experts compared to novices.

Which raises the question "expert in which field?"

You, and others, take the view that the relevant expertise for this 
discussion is expertise in the definition and operation of protocol 
parameters.

I take the view that the relevant expertise for this discussion is expertise 
in legal and contractual matters.

---

From: Jefsey <[email-masked]>
Date: Tue, 18 Nov 2014 15:00:35 +0100

At 14:53 18/11/2014, Richard Hill wrote:
>discussion is expertise in the definition and operation of protocol parameters.
>
>I take the view that the relevant expertise for this discussion is 
>expertise in legal and contractual matters.

May I just add that IMHO the relevant expertise is in trying to use 
the IETF deliverable. This deliverable is the non-secure-internet. 
The IAB has required a new one: we are equaly novice in knowing what 
this "non NTIA/NSA only sponsored" new secure internet will require 
IRT to names, numbers, currently missing compacted documentation, and 
parameters.
jfc

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Nov 2014 14:02:23 +0000

On 18/11/14 13:53, Richard Hill wrote:
> <[email-masked]> To: "Milton L Mueller" <[email-masked]>;
> "Peterson, Jon" <[email-masked]>; <[email-masked]>;
> "Alissa Cooper" <[email-masked]> Cc: <[email-masked]>; "Eliot
> Lear" <[email-masked]> Sent: Tuesday, November 18, 2014 2:42 PM 

The above is correct. The non-legal approach wins in this case I
think because for this specific topic (iana.org and marks) the
non-legal point is that we can work around the legalities.

If you want to make the case that we cannot, then you will be
contradicting what you said yesterday.

S.

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 18 Nov 2014 09:30:15 -0500

> parameters. With you being one of the latter.

And, I think it's fair to say that some have been rather dismissive of 
those opinions, framed as "if you did IETF work on protocol parameters 
you'd understand."

> as valid via the designated expert designation.

I'd also like to point out, that at least one of us (myself), while not 
attending IETF working groups, HAS worked participated in IETF work (as 
an engineer, at BBN, working on things like security protocols that were 
part of IETF processes).  While that was admittedly a while back, I 
remain involved in development projects, architect systems, and 
administer a gaggle of systems - and in that regard, not infrequently 
find myself consulting the various protocol parameter registers on 
iana.org (and standards.ieee.org for that matter).

As a USER of the protocol registry, I consider that a directly relevant 
perspective on the issues at hand - and can state categorically that I, 
for one, would find it disruptive to suddenly find that regularly 
consulted data sources have suddenly moved, and to start finding broken 
links in reference sources, and so forth.

Beyond that, you're also dismissing the expertise of folks with 
extensive experience in policy, legal, contractual, regulatory and 
standards activities - areas that are extremely relevant to the NTIA 
transition, but outside the normal scope of the protocol parameters activity
Miles Fidelman

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Nov 2014 14:33:04 +0000

Top posting: I'm "dismissing" nothing. I'm arguing for what
I think is the case. Maybe people need to get over not being
agreed with;-)

S.

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 18 Nov 2014 09:33:22 -0500

> contradicting what you said yesterday.

How about making the case that having a non-legal work around is 
sufficient, and optimal?

That we CAN work around the legalities is not (IMHO) sufficient cause 
for saying we SHOULD work around the legalities.

Miles Fidelman

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 18 Nov 2014 14:50:26 +0000

> [… on acknowledgements…]

For fairness in advertisement: an explicit disclaimer can be added. See e.g.:
https://tools.ietf.org/html/draft-iab-iana-framework-02#section-7

(I am the last to mention anybody in the acknowledgement section against their will.)

—Olaf

— — — — — —
www.isoc.org
[email-masked]

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 18 Nov 2014 18:01:09 +0100

Hello all,

Sorry, I should know better but I couldn't keep my mouth shut anymore,
see reply inline.

> in legal and contractual matters.

Here's my view on the above statement. Not sure if I'm a novice or
not, but I've been lurking around in some darker corners of IETF for
quite some year. Just never had a chance to attend a meetings yet.

Based on all the emails I do belive we all do understand both the big
picture with regards to IANA, and the more concrete subject with
regard to the Protocol registry of IANA where IETF publish it's data.
We just disagree what is The Right Way for IETF.

Short version - the experts in this case are technical people dealing
with IANA registry function regularly. Active IETF members.

The reason for this is easy, IETF as a community deals with technical
things related to protocols specification. The rest are outsourced,
like arranging meetings, official position of different kinds, running the
registry (IANA as it's currently called) etc etc. We just give guiding on
what they can do on different topics. In this case what are IETF's
stand on the IANA function and the transition.

That combined with that any IETF working groups that I'm aware of work
under a charter that is their guide on what they can and can not do.
The way I read our charter the discussion on legal and contractual stuff
are clearly outside ours.

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

With that said, I think the last draft are acceptable, it's not perfect and
don't address everything, but with our charter as guide it is good.

Sure the name IANA and the domain name IANA.org do matter as I
wrote in another mail, and it would be great if they both was
owned/handled somewhere else than with our current IANA operator.
Good idea to separate those two functions, handling the name and
doing the function. But it's not a huge problem or showstopper for
IETF, we can make a choice to publish our data elsewhere.
Best we can do now are to provide a clear statement on the stability
of the IANA registry and the data there, a clear statement that it is
IETF (mostly) generated that, they are just to add the data we ask
them to do. And that we have I believe.
The finer print to get the job done, maybe involving legal and contractual
work, well that's for IAB or/and IAOC as said above.

--

---

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

Hi Milton & Andrew,

> I think that's a pretty good characterization of the positions, actually. Not a cartoon.

In fact when I read Andrew's note my first thought was that if those are
the poles, they're really not that far apart.  This has been my view
from the outset: that largely speaking, everyone has the same set of end
goals (they're even stated in the draft and not a single word of them
has needed to change) but we differ somewhat on how to achieve them and
whether we can be effective in certain instances.

> Really, all I am suggesting is that it would not be difficult for the supporters of -03 to make a few changes that would satisfy the supporters of -02, while retaining the fundamentals of their vie…

We should always strive for the largest possible set of individuals who
can agree on an approach.  I see Leslie has put a note out that offers
what may be a compromise.

Eliot

---

From: Seth Johnson <[email-masked]>
Date: Tue, 18 Nov 2014 13:00:56 -0500

Well, I tried this, but the other things are too important (and they
relate to this too), at least for the next two days.  I'll be able to
be provide a constructive input at that point.  Sorry.  I did try,
until 2am this morning.  :-)

Seth

---

From: Steve Crocker <[email-masked]>
Date: Thu, 13 Nov 2014 17:47:47 +0000

Folks,

Thanks,

Steve Crocker

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Nov 2014 18:17:44 -0800

+1. 

The IAOC has access to legal counsel and pays real money for the service.  At those rates, having a minimal list of requirements is valuable.  Attempting to work out the details of a legal agreement within a WG comprised of non-lawyers is not.