Subject: [Ianaplan] Review of draft-ietf-ianaplan-icg-response-01

From: Alissa Cooper <[email-masked]>
Date: Fri, 24 Oct 2014 16:35:53 -0700

All,

I’ve reviewed draft-ietf-ianaplan-icg-response-01 and my review comments are below. Many thanks to Eliot and others for your work on this.

Alissa

=== Substantive comments ===

== Response to Section I:

"The IETF uses the IANA protocol parameter registries to implement such registries.”

I don’t understand what the above sentence means.

=

"The IANA protocol parameter registry operator maintains the protocol
   parameters registry for the IETF in accordance with all relevant IETF
   policies, in accordance with the Memorandum of Understanding"

This is the first place where the MoU is mentioned, and it is simply called the MoU, which may not be descriptive enough. I would suggest 

s/the Memorandum of Understanding/a Memorandum of Understanding established between the IETF and ICANN/

and adding a citation to the MoU.

=

"The protocol parameter registries are the product of IETF work.”

This seems like an under-specified answer. For example, the IP address space registries could certainly be considered to be the product of IETF work. But I did not think it was the intent to cover them in this transition plan document. I apologize if there has been discussion of this on the list that I missed, but I feel like the answer to this question is specifically our opportunity to explain exactly what is covered by this particular transition plan, and “the product of IETF work” is a rather vague answer.

=

"We will continue to coordinate with ICANN regarding those changes."

In all of the bullets listed in this part of the response, I’m curious if we really mean “IANA functions operator” where we are presently using “ICANN."

=

Why is the recently implemented audit not mentioned in response to the question about a description of the oversight mechanism?

== Response to Section II:

"IETF Response: all policy sources relating to the protocol parameters registry have been specified in II.A."

This is not really answering the question posed in the RFP. The question in the RFP is whether there are some policy sources described in answering Section II.A that are not covered by the oversight mechanisms to be described in response to Section II.B. I would suggest:

“IETF Response: All policy sources relating to the protocol parameters registries are affected.”

== Response to Section III:

"To address a desire by some members of 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."

First, I think the bit about “some members of the community” is unnecessary. This document with either have rough consensus or it won’t. Second, I think the asks to the IAOC should all follow the same standard, which is articulated in the prior paragraph — engaging the relevant parties to make [fill-in-the-blank] happen. So for this sentence, my suggested edit is:

“The IAOC is asked to engage with the IANA functions operator regarding jurisdiction and
   any necessary dispute resolution mechanisms that are mutually
   acceptable to the parties."

We should leave it up to the IAOC to decide how to effectuate this.

=

"To address concerns regarding appropriate contingencies to transition to another operator, IAOC is asked to conclude a supplemental agreement that- 1. captures provisions C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract]; and"

Similar to my comment above, I think this should align with the other bits about the IAOC, i.e.,

"To address concerns regarding appropriate contingencies to transition to another operator, the IAOC is asked to engage with the IANA functions operator regarding: 1. maintaining the IANA functions operator's obligations established under provisions C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract]; and”

=

"requires the transfer of any associated marks and identifiers to a subsequent operator."

I continue to be against the inclusion of this provision in the transition plan. It implicitly requires there to only ever be one operator in the future, and it is not in the IETF’s interest to force that to be the case. That may have been in NTIA’s interests, but we have different needs from NTIA. 

== Response to Section IV:

"What is necessary as part of transition is the completion of supplemental agreement(s) discussed in the previous section of this RFP.”

Per my comments above, I don’t think we should specify the form of the output of the IAOC’s work. My suggestion:

"What is necessary as part of transition is the completion of the IAOC’s engagements discussed in the previous section of this RFP to the satisfaction of the IAOC.”

=== Nits ===

In general, I think we should use the term “protocol parameters registries” in the plural rather than the singular, and use it consistently throughout the document.

Abstract:
s/This document contains the a draft response to a request/This document contains a response to a request/

s/names and addresses/domain names and numbering resources/

Section 1:
s/protocol registries function/protocol parameters registries function/

Section 2:
s/globally available registry/globally available registries/

s/assoicated/associated/

s/operates an open and transparent manner/operates in an open and transparent manner/

s/in RFCs in [RFC6220] and [RFC5226]/in [RFC6220] and [RFC5226]/

s/[RFC7282]/[RFC7282]./

s/an someone/someone/

s/IETF Response: the protocol parameters registries./IETF Response: The protocol parameters registries./

s/No changes are required, as over the years/No changes are required. Over the years/

s/intellectual property rights; the IAOC/intellectual property rights, the IAOC/

s/issuees/issues/

s/{We will have an open discussion, make changes based on that discussion, and then conduct a Last Call to confirm that there is rough consensus for the proposal.}//

---

From: Eliot Lear <[email-masked]>
Date: Sat, 25 Oct 2014 08:35:41 +0200

Hi Alissa,

Thanks for your thorough review.  Please see below regarding proposed
disposition of your comments.

On 10/25/14, 1:35 AM, Alissa Cooper wrote:
> All,
>
> I’ve reviewed draft-ietf-ianaplan-icg-response-01 and my review
> comments are below. Many thanks to Eliot and others for your work on this.
>
> Alissa
>
>

Yes, I caught this as well.  My proposal is as follows:

>        The IETF uses the IANA
>         protocol parameter registries to store this information  in a
>         public location.

> This is the first place where the MoU is mentioned, and it is simply
> called the MoU, which may not be descriptive enough. I would suggest 
>

Propose to change as suggested above unless there are objections.

> This seems like an under-specified answer. For example, the IP address
> space registries could certainly be considered to be the product of
> IETF work. But I did not think it was the intent to cover them in this
> transition plan document. I apologize if there has been discussion of
> this on the list that I missed, but I feel like the answer to this
> question is specifically our opportunity to explain exactly what is
> covered by this particular transition plan, and “the product of IETF
> work” is a rather vague answer.

That is covered in the earlier text to which you suggested an edit, and
we are attempting to be concise.  The clear point we wish to bring
forth, and this has been discussed, is that the protocol parameter
registries are really an integral part of IETF standards.

> In all of the bullets listed in this part of the response, I’m curious
> if we really mean “IANA functions operator” where we are presently
> using “ICANN."

In this case, the GNSO, ccNSO, SSAC, and perhaps the ICANN board all may
have an interest.  In fact we have a liaison manager who sits on the
board for technical advice.

>
> =
>
> Why is the recently implemented audit not mentioned in response to the
> question about a description of the oversight mechanism?

Happy to include, and would invite proposed text.

> "IETF Response: all policy sources relating to the protocol
> parameters registry have been specified in II.A."
>
> This is not really answering the question posed in the RFP. The
> question in the RFP is whether there are some policy sources described
> in answering Section II.A that are not covered by the oversight
> mechanisms to be described in response to Section II.B. I would suggest:
>

I have no objection to the change.
> First, I think the bit about “some members of the community” is
> unnecessary. This document with either have rough consensus or it
> won’t. Second, I think the asks to the IAOC should all follow the same
> standard, which is articulated in the prior paragraph — engaging the
> relevant parties to make [fill-in-the-blank] happen. So for this
> sentence, my suggested edit is:
>

I have removed "some members of".
>
> =
>
> "To address concerns regarding appropriate contingencies to
> transition to another operator, IAOC is asked to conclude a
> supplemental agreement that- 1. captures provisions C.7.3 and I.61 of
> the current IANA functions contract between ICANN and the NTIA
> [NTIA-Contract
> <http://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-01#ref-NTIA-Contract>];
> and"
>
> "To address concerns regarding appropriate contingencies to
> transition to another operator, the IAOC is asked to engage with the
> IANA functions operator regarding: 1. maintaining the IANA functions
> operator's obligations established under provisions C.7.3 and I.61 of
> the current IANA functions contract between ICANN and the NTIA
> [NTIA-Contract
> <http://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-01#ref-NTIA-Contract>];
> and”

I have no problem with the wording change above.
> I continue to be against the inclusion of this provision in the
> transition plan. It implicitly requires there to only ever be one
> operator in the future, and it is not in the IETF’s interest to force
> that to be the case. That may have been in NTIA’s interests, but we
> have different needs from NTIA. 
>

Based on what you wrote above I had previously misunderstood your
concern.  I propose a small change for this response with the
expectation that we will engage others in the process of further
developing a consolidated response:

"requires the transfer of any associated marks and identifiers
tosubsequent operators."

Clearly there will need to be additional discussion with the RIRs in
particular about iana.org.

> "What is necessary as part of transition is the completion
> of supplemental agreement(s) discussed in the previous section of
> this RFP.”
>
> Per my comments above, I don’t think we should specify the form of the
> output of the IAOC’s work. My suggestion:
>
> "What is necessary as part of transition is the completion of the
> IAOC’s engagements discussed in the previous section of this RFP to
> the satisfaction of the IAOC.”
>

I do not believe this is sufficiently clear for our intent to be
understood and prefer the original text.
> === Nits ===

Thanks for catching them.  I've only left in the ones for which there is
something to add.
>
> In general, I think we should use the term “protocol parameters
> registries” in the plural rather than the singular, and use it
> consistently throughout the document.
>
I've made this change.  Please review in the next version as there were
a lot of edits.

> s/No changes are required, as over the years/No changes are required.

This text has changed.

Eliot

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 25 Oct 2014 12:27:23 +0200

Many thanks to both Alissa and Eliot for this.

I largely (not not entirely) agree with Alissa's comments, and I almost entirely  agree with Eliot's proposed dispostions.

Here is where I differ from what Eliot has proposed.

Re "We will contintue to coordinate with ICANN regarding those changes", I would propose  "We will continue to coordinate with the IANA functions operator (at present ICANN) regarding those changes", or something along those lines.

Thanks again and best,
Richard
  -----Original Message-----
  From: Ianaplan [mailto:[email-masked]]On Behalf Of Eliot Lear
  Sent: samedi, 25. octobre 2014 08:36
  To: Alissa Cooper; [email-masked]
  Subject: Re: [Ianaplan] Review of draft-ietf-ianaplan-icg-response-01

  Hi Alissa,

  Thanks for your thorough review.  Please see below regarding proposed disposition of your comments.

    All,

    Alissa

           The IETF uses the IANA

    =

    =

  That is covered in the earlier text to which you suggested an edit, and we are attempting to be concise.  The clear point we wish to bring forth, and this has been discussed, is that the protocol parameter registries are really an integral part of IETF standards.

    =

  In this case, the GNSO, ccNSO, SSAC, and perhaps the ICANN board all may have an interest.  In fact we have a liaison manager who sits on the board for technical advice.

    =

    =

    =

  Based on what you wrote above I had previously misunderstood your concern.  I propose a small change for this response with the expectation that we will engage others in the process of further developing a consolidated response:

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

  Clearly there will need to be additional discussion with the RIRs in particular about iana.org.

  I do not believe this is sufficiently clear for our intent to be understood and prefer the original text.

    === Nits ===

  Thanks for catching them.  I've only left in the ones for which there is something to add.

  I've made this change.  Please review in the next version as there were a lot of edits.

  This text has changed.

  Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sat, 25 Oct 2014 12:47:37 +0200

Hi Richard,

On 10/25/14, 12:27 PM, Richard Hill wrote:
> I largely (not not entirely) agree with Alissa's comments, and I
> almost entirely  agree with Eliot's proposed dispostions.
>  
> Re "We will contintue to coordinate with ICANN regarding those
> changes", I would propose  "We will continue to coordinate with the
> IANA functions operator (at present ICANN) regarding those changes",
> or something along those lines.
>

Perhaps we need a different approach, if people feel strongly about that
particular phrase in this response, because in this context we are
talking about the DNS protocol, and that requires a lot of coordination
when we make changes, and perhaps it's not just with ICANN or the IANA
functions operator.  So...

I suggest then:

          The IETF specifies the DNS protocol.  From time to time
          there have been and will be updates to that protocol.    As we
          make changes we will broadly consult the operational
          community about the impact of those changes, as we have
          done in the past.

Eliot

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 25 Oct 2014 12:52:57 +0200

OK for me.

Thanks and best,
Richard
  -----Original Message-----
  From: Ianaplan [mailto:[email-masked]]On Behalf Of Eliot Lear
  Sent: samedi, 25. octobre 2014 12:48
  To: [email-masked]; Alissa Cooper; [email-masked]
  Subject: Re: [Ianaplan] Review of draft-ietf-ianaplan-icg-response-01

  Hi Richard,

  Perhaps we need a different approach, if people feel strongly about that particular phrase in this response, because in this context we are talking about the DNS protocol, and that requires a lot of coordination when we make changes, and perhaps it's not just with ICANN or the IANA functions operator.  So...

  I suggest then:

  Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 26 Oct 2014 16:36:18 +0100

Hi again, Alissa,

On 10/25/14, 8:35 AM, Eliot Lear wrote:
>
>> =
>>
>> Why is the recently implemented audit not mentioned in response to
>> the question about a description of the oversight mechanism?
>

Actually, here is what I propose, next to the annual supplement discussion:

        In accordance with these supplements, an  annual
        review is performed to ensure that protocol parameter
        requests are being processed according to the established
        policies.

Eliot

---

From: Milton L Mueller <[email-masked]>
Date: Sun, 26 Oct 2014 16:38:51 +0000

"To address concerns regarding appropriate contingencies to transition to another operator, IAOC is asked to conclude a supplemental agreement that- 1. captures provisions C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract<http://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-01#ref-NTIA-Contract>]; and"

"To address concerns regarding appropriate contingencies to transition to another operator, the IAOC is asked to engage with the IANA functions operator regarding: 1. maintaining the IANA functions operator's obligations established under provisions C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract<http://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-01#ref-NTIA-Contract>]; and”

I do. Replacing “conclude a supplemental agreement …” with “engage with the IANA functions operator regarding…” replaces very specific wording and requirements with very vague and noncommital stuff. I don’t know what it means to “engage with.” I don’t know what the outcome of such an “engagement” would be.

A compromise version of this wording might read:

To address concerns regarding appropriate contingencies to transition to another operator, IAOC is asked to conclude a supplemental agreement that – 1. Maintains the IANA functions operator's obligations established under provisions C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract<http://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-01#ref-NTIA-Contract>]; and

Milton L Mueller
Laura J. and L. Douglas Meredith Professor
Syracuse University School of Information Studies
http://faculty.ischool.syr.edu/mueller/
Internet Governance Project
http://internetgovernance.org<http://internetgovernance.org/>

=

=== Nits ===

This text has changed.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sun, 26 Oct 2014 19:30:27 +0100

On 10/26/14, 5:38 PM, Milton L Mueller wrote:
>     supplemental agreement that- 1. captures provisions C.7.3 and
>     I.61 of the current IANA functions contract between ICANN and the
>     NTIA [NTIA-Contract
>     transition to another operator, the IAOC is asked to engage with
>     the IANA functions operator regarding: 1. maintaining the IANA
>     functions operator's obligations established under provisions
>     C.7.3 and I.61 of the current IANA functions contract between
>     ICANN and the NTIA [NTIA-Contract
> I do. Replacing “conclude a supplemental agreement …” with “engage
> with the IANA functions operator regarding…” replaces very specific
> wording and requirements with very vague and noncommital stuff. I
> don’t know what it means to “engage with.” I don’t know what the
> outcome of such an “engagement” would be.
>
>  
>
> To address concerns regarding appropriate contingencies to
> supplemental agreement that – 1. Maintains the IANA functions
> and

This is what will be in the next version (I had not made the edit).  I
missed the Alissa's proposed edit, as it happens (not sure how I missed
it), and apologize for confusion.  The issue for me here is precisely
what you describe.  However, I would be open to changes to this text if
they can be made in such a way that maintains our interests with
additional flexibility.  I believe that would also address a comment
from Jon Peterson.  I just don't have the right wording to do that.

Eliot

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 26 Oct 2014 14:57:59 -0400

Eliot Lear wrote:
> missed the Alissa's proposed edit, as it happens (not sure how I 
> missed it), and apologize for confusion.  The issue for me here is 
> precisely what you describe.  However, I would be open to changes to 
> this text if they can be made in such a way that maintains our 
> interests with additional flexibility.  I believe that would also 
> address a comment from Jon Peterson.  I just don't have the right 
> wording to do that.
>

I would also urge more specific and binding language, rather than vague 
language.  Let's make sure this is done before the NTIA contract goes away.

Also, note that, as far as the process is concerned - IAOC and IETF are 
the same entity (IAOC is the entity that reflects IETF when it comes to 
contracts).  Language like "the IAOC is asked" is cumbersome, since for 
legal and contractual purposes, that's the IETF asking the IETF to do 
something.  It's more accurate to say that "the IETF proposes that, 
before a transition occurs, that supplemental agreements be put in 
place.... with the IOAC acting as the legal and contracting 
representative of the IETF."

Something I've said before, that bears repetition: The final IETF 
proposal should include IAB, IAOC, considerations, as well those of any 
other entities that are part of IETF from view of the outside world.  
How to coordinate that is an open question - clearly that goes beyond 
the scope of the WG charter.

Miles Fidelman

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

---

From: Eliot Lear <[email-masked]>
Date: Sun, 26 Oct 2014 22:30:50 +0100

Hi Miles,

On 10/26/14, 7:57 PM, Miles Fidelman wrote:
>
> Also, note that, as far as the process is concerned - IAOC and IETF
> are the same entity (IAOC is the entity that reflects IETF when it
> comes to contracts).  Language like "the IAOC is asked" is cumbersome,
> since for legal and contractual purposes, that's the IETF asking the
> IETF to do something.  It's more accurate to say that "the IETF
> proposes that, before a transition occurs, that supplemental
> agreements be put in place.... with the IOAC acting as the legal and
> contracting representative of the IETF."
>

What we are writing right now is a proposal, not contract language.  We
are expressing both our desire and our intent.  As you point out, the
IAOC would handle the specific language.

Eliot

---

From: Andrei Robachevsky <[email-masked]>
Date: Sun, 26 Oct 2014 23:21:16 +0100

On 25 October 2014 01:35, Alissa Cooper <[email-masked]> wrote:

> space registries could certainly be considered to be the product of IETF
> work. But I did not think it was the intent to cover them in this
> transition plan document. I apologize if there has been discussion of this
> on the list that I missed, but I feel like the answer to this question is
> specifically our opportunity to explain exactly what is covered by this
> particular transition plan, and “the product of IETF work” is a rather
> vague answer.
>
>
> Alissa, I agree that it is under-specified.

There was some prior discussion of the point about the IP address space and
I thought that a general agreement was that the IETF created the numbering
space and identified part of it (global unicast) for allocation via the
Internet Number Registry System. Which to me means that it indeed should be
considered as a protocol parameter registry. And IMO should be explicitly
specified here, not just in the "overlap" section.

Andrei

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Oct 2014 13:08:20 +1300

On 27/10/2014 11:21, Andrei Robachevsky wrote:
> considered as a protocol parameter registry. 

This is unambiguously true for the IPv6 address regitstry.

It is less clear for the IPv4 address registry, which predated the
existence of the IETF; therefore the language would have to be
quite nuanced.

The same goes for the the null label of the DNS root, which
goes back at least to 1983 (RFC 882).

> And IMO should be explicitly

I think we are on shaky ground if we do that, except for IPv6.

    Brian

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 26 Oct 2014 22:02:05 -0400

> IAOC would handle the specific language.

IMHO:
- proposals are usually couched in contractual language, particularly when
- the subject is one of governance and contracts

Re. IAOC - since it really is one and the same as IETF (from an outside 
perspective) - how will IAOC considerations be merged with the proposal 
that comes out of the WG?  Somehow, separate proposals from IAOC, IAB, 
and IETF don't seem to be in the spirit of what's being asked for.

Cheers,

Miles

---

From: JFC Morfin <[email-masked]>
Date: Mon, 27 Oct 2014 19:02:23 +0100

the IETFAt 19:57 26/10/2014, Miles Fidelman wrote:
>How to coordinate that is an open question - clearly that goes 
>beyond the scope of the WG charter.

Should all this not be discussed at the PSO as per RFC 2691, the IETF 
has established to that end (ICANN/IETF protocol parameters issues)?
jfc

---

From: John Curran <[email-masked]>
Date: Mon, 27 Oct 2014 21:47:12 -0200

On Oct 27, 2014, at 4:02 PM, JFC Morfin <[email-masked]> wrote:
> ...
> Should all this not be discussed at the PSO as per RFC 2691, the IETF has established to that end (ICANN/IETF protocol parameters issues)?

<http://www.iab.org/documents/correspondence-reports-documents/docs2003/icann-pso-notice/>

FYI,
/John

---

From: Jefsey <[email-masked]>
Date: Tue, 28 Oct 2014 16:51:39 +0100

At 00:47 28/10/2014, John Curran wrote:
> > Should all this not be discussed at the PSO as per RFC 2691, the 
> IETF has established to that end (ICANN/IETF protocol parameters issues)?
>

John,
Thank you to help me making the point: I did not find back this notice.

1) as it was explained to Richad Hill recently, the IETF has its own 
ways. An RFC is to be obsoleted by an RFC. The notice is only signed 
by the IETF Chair, as is RFC 6852, which is also signed by the IAB, 
the ISOC, the W3C and the IEEE Chairs and is IAB Stream. Either RFC 
6852 is to be considered, or it is not, nor the resignation you 
quote, and the PSO is the proper place. My point is certainly that 
the uncompleted (lack of accountability) RFC 6852 framework applies.

2) This RFC involves the ITU, the W3C and any SDO who could wish to 
adhere, meet the criteria, and be accepted. This examplifies the 
ICANN attitude with peers.

3) More importantly, I suggest everyone to carefully note that if the 
IETF has removed itself from the PSO it is NOT by its own decision, 
but due to the UNILATERAL decision of ICANN to remove the PSO from 
its own organization. From this experience why would IETF trust any 
agreement with ICANN, even agreed and signed with/by other major SDOs 
(such ITU and W3C)?

In French we say "chat échaudé craint l'eau froide" and in latin 
"errare humanum est, diabolicum perseverare".

jfc

---

From: John Curran <[email-masked]>
Date: Tue, 28 Oct 2014 16:23:19 -0300

On Oct 28, 2014, at 12:51 PM, Jefsey <[email-masked]> wrote:
> ...
> 3) More importantly, I suggest everyone to carefully note that if the IETF has removed itself from the PSO it is NOT by its own decision, but due to the UNILATERAL decision of ICANN to remove the PSO from its own organization. From this experience why would IETF trust any agreement with ICANN, even agreed and signed with/by other major SDOs (such ITU and W3C)?

<http://www.iab.org/documents/correspondence-reports-documents/docs2002/icann-response/>
       ' The IAB is in general agreement with this recommendation (that "The Protocol Supporting Organization should be dissolved."), as the IAB sees no merit in the continuation of the PSO, as currently chartered. '

/John

---

From: JFC Morfin <[email-masked]>
Date: Wed, 29 Oct 2014 02:30:48 +0100

At 20:23 28/10/2014, John Curran wrote:
> > 3) More importantly, I suggest everyone to carefully note that if 
> the IETF has removed itself from the PSO it is NOT by its own 
> decision, but due to the UNILATERAL decision of ICANN to remove the 
> PSO from its own organization. From this experience why would IETF 
> trust any agreement with ICANN, even agreed and signed with/by 
> other major SDOs (such ITU and W3C)?
>
>        ' The IAB is in general agreement with this recommendation 
> (that "The Protocol Supporting Organization should be dissolved."), 
> as the IAB sees no merit in the continuation of the PSO, as 
> currently chartered. '

John,
Thank you! May I suggest you read a little further than the polite 
diplomatic language. The author is our co-Chair and she writes (12 
years ago - things have not changed? Why would they change once ICANN 
is sovereign?).

"IETF Protocol Parameters

"The report references a statement of ICANN's mission which includes 
the role of coordination of the allocation and assignment of Protocol 
port and parameter numbers, as distinct from domain names and IP 
addresses and Autonomous System numbers.

"The IAB notes that this role is undertaken for the IETF as part of 
the process of implementation of "IANA Considerations" in Internet 
Standards-track protocol specifications (IETF protocols), as 
specified in the MoU documented in RFC2860, and is distinct from the 
ICANN role in the management of domain names and unicast IP 
addresses. This IETF protocol parameter coordination role is an 
integral component of the IETF's Internet Standards function. For 
this reason the IAB disputes the assertion in the ICANN mission 
statement that this particular role forms an integral part of ICANN's mission.

"The IAB is deeply concerned that the role of the management of 
protocol parameter assignments for IETF Internet-Standard protocols 
is being confounded within the deeper issues concerning the role of 
ICANN with respect to the operation of the domain name system and 
with respect to unicast IP address assignment.

"This situation is not acceptable to the IAB. The IAB is evaluating 
the best path forward to maintain the IETF's protocol parameter coordination."

The more it changes, the more it is the same?
Best
jfc

---

From: John Curran <[email-masked]>
Date: Tue, 28 Oct 2014 22:33:57 -0300

On Oct 28, 2014, at 10:01 PM, JFC Morfin (LERDA) <[email-masked]> wrote:
> Thank you! May I suggest you read a little further than the polite diplomatic language. 

Your earlier suggestion (that "all this be discussed at the PSO") was 
invalid, as the PSO has not existed for the last 10 years or so.

Your assertion which followed ("the IETF has removed itself from the PSO 
it is NOT by its own decision, but due to the UNILATERAL decision of ICANN 
to remove the PSO from its own organization") was also incorrect, as is
plainly shown by ICANN evolution and reform committee making a proposal 
for elimination of the PSO, and the IAB indicating concurrence with same.

Finally, your most recent assertion ("The more it changes, the more it is 
the same?") based on the IAB response letter is also flawed, since ICANN's 
understanding that it performs protocol parameter assignments per the IETF's 
authority became quite clear upon receipt of the IAB feedback, and this is
evidenced even now by its own documentation surrounding the IANA Stewardship 
transition, 
e.g. <https://www.icann.org/en/system/files/files/functions-transfer-faqs-14mar14-en.pdf>
   "  * This announcement does not call into question the role of ICANN, IETF, and
    the RIRs in the IANA Functions. These bodies continue to hold policy authority 
    for the protocol parameters, IP addresses, and name spaces, including 
    responsibility to ensure the faithful registry administration by ICANN 
     according to those policies."

Note - you do not have to have any first-hand experience in these matters to 
provide thoughtful analysis, however, it is necessary to research the actual 
events prior to commentary if you wish to be taken seriously.

Thanks,
/John

Disclaimer: my views alone.

---

From: JFC Morfin <[email-masked]>
Date: Wed, 29 Oct 2014 03:13:48 +0100

At 02:33 29/10/2014, John Curran wrote:
>provide thoughtful analysis,

John,
I certainly agree with you on the ultimate result.

This is not my point. My point is on who is initiating the change, 
how it proceeds, for whose convenience, and how it is dicussed.

>however, it is necessary to research the actual
>events

The way you introduced the documents, probably looking each time at 
the next step to show me wrong ...

>  prior to commentary if you wish to be taken seriously.

... actually shows me right to those who do not consider the past 
environment as going to be perpetuated. Something you seem to bet. In 
such a case I would certainly be wrong.

The point is that the technical environment is going to change due to 
the "MYCANN plugs-in".
Not so much the one I advocate: the others.

My ICANN/ICP-3 conformant MPI project is only a way for the Libre and 
the various RFC 6852 communities to be able to understand, 
experiment, possibly enhance, and counter the introduction of various 
State rogue MPIs. Do you really believe that any serious Gov is going 
to bet its national cyberspace and entire economy on non-US 
oversigthen ICANN's fancies?

There is the real world, and the I*core's one. This later world was 
credible as long as it was under NTIA oversight.
As a  Dan Tapscott/Lynn StAmour "Global Solution Network" subject to 
FCC rulings; I am sorry, it is not credible anymore to a Governement 
and to any serious operator. I know this is not something you 
wish/like to be told, but you know this is true.

We will soon see what Putin and Xi Dada think about it.

jfc