Subject: Re: [Ianaplan] Summary/refinement of scenarios discussed so far (was Constructive redirect -- focusing discussions)

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Tue, 23 Sep 2014 16:40:24 -0400

Reading John Curran's latest message to the list, I realized that 1/ the 
original message I'd composed to summarize scenario discussion never 
made it past my outbox ( *blush*), and 2/ I'd gotten his point a bit wrong.

With apologies and updates, here's a suggested summary/refinement of 
scenarios discussed so far:

Thanks to Eliot and others for discussing the possible scenarios to examine!

My read/summary of where we have gotten in refining what the scenarios 
are so far is as follows (please suggest corrections and any additional 
scenarios we should yet look at):

1/  Everyday IETF IANA protocol parameter registry activities, 
post-transition.

Discussion on the list highlighted that we are pretty comfortable with 
the level of documentation/agreements for handling this onging (see 
quote [1] below), with two exception cases to be examined:

     + what happens if the 3 IANA functions are separated to different 
operators  (see quote [2] below)

     + what happens if the IETF creates another names- or numbers-like 
protocol parameter (i.e., that might leverage existing frameworks of 
RIRs, but which should require open, bottom-up policy development going 
forward) -- whether or not the functions are separated to different 
operators (see quote [3] below)

2/ Pear-shaped future -- the IAB determines that a new contractor is 
needed, works with the IAOC and IASA to establish criteria for selection 
of a new contractor, and then informs ICANN so that a notice period 
begins.  A transition then takes place where the function moves to the 
new  contractor, and is no longer performed by ICANN. (see quote [4] below)

3/ Rejection -- ICANN bows out of the business of providing IANA 
protocol parameter registry functions (see quote [5] below).

And the question is not whether these are likely or desirable futures, 
but rather:  are there pieces missing from the suite of IETF 
documentation to handle the different angles of these possibilities?

Leslie.

[1] [Eliot Lear]
 >> 1/ Everyday IETF IANA protocol parameter registry activities,
 >> post-transition.
 > Let's call this State 1.
 >
 > Good looks like it does today. That's the good news   IETF policies
 > will continue to govern the policies by which codepoints are managed.
 > In the case of an operator change, things continue to function in just
 > this manner.  There is no confusion as to where a developer should go to
 > get a codepoint assignment or where a developer should go to find the
 > most current list of assignments.

[2] [John Curran]
 > If that _is_ the case, then would the IETF(/IAB/IAOC) contract with 
the new IANA
 > registry operator include provisions (T&C's or SoW) that the operator 
work with
 > any IANA registry operators selected by other delegated registry 
authorities
 > (ICANN, RIRs) so as to insure seamless publication of each IANA 
registry space?
 > Such a requirement may mean the IETF's IANA registry operator putting 
information
 > towards other IANA registry operators or picking up same for its own 
publication,
 > depending on the particularly registry.

[3] [John Curran]
 > This new protocol (NewIP) has its own unique IDs that must be made widely
 > available for the protocol to be adopted and thus successful, and it 
is also
 > anticipated that these will be issued via a variety of schemes, e.g. 
to new
 > equipment makers, to hobbyists who request blocks, to governments who 
wish
 > to coordinate things in their country, etc.
[snip]
 > Once the IETF decides what responsibilities it should have to the 
communities
 > who are using publicly visible Internet identifier spaces, and 
decides on an
 > approach for fulfilling these responsibilities going forward, the 
result may
 > also prove helpful in determining what relationships (if any) the 
IETF needs
 > with ICANN, the RIRs, and related parties doing Internet registry 
operations;
 > that should be expected, as it is the same questions, only with 
respect to the
 > publicly-visible identifier spaces that have already been deployed.

[4] [Eliot Lear]
 >> 2/ Non-everyday occurrences:  dissatisfaction with existing operator
 >> -- making the change, impact afterwards; selection of alternate
 >> operator for one or more registries;  competitive assignments
 >> (squatting) on individual registries or registry values.
 >
 > How to get back to Good:
 >
 > In the case where we have reached what earlier called the pair shaped
 > future, the IAB determines that a new contractor is needed, works with
 > the IAOC and IASA to establish criteria for selection of a new
 > contractor, and then informs ICANN so that a notice period begins.  A
 > transition then takes place where the function moves to the new
 > contractor, and is no longer performed by ICANN.
 >

[5] [Eliot Lear]
 > In the case where ICANN determines that they can no longer support the
 > function for one reason or another, they provide us notice, hopefully
 > unofficially at first, and then we go find a new contractor, as
 > described above, with the transition occurring, as described above.  In
 > the end, we return to State (1).

On 9/16/14 12:43 PM, Leslie Daigle (TCE) wrote:
> Thanks to Eliot and others for discussing the possible scenarios to
> examine!
>
> My read/summary of where we have gotten in refining what the scenarios
> are so far is as follows (please suggest corrections and any additional
> scenarios we should yet look at):
>
> 1/  Everyday IETF IANA protocol parameter registry activities,
> post-transition.
>
> Discussion on the list highlighted that we are pretty comfortable with
> the level of documentation/agreements for handling this onging (see
> quote [1] below), with two exception cases to be examined:
>
>      + what happens if the 3 IANA functions are separated to different
> operators  (see quote [2] below)
>
>      + what happens if the IETF creates another names- or numbers-like
> protocol parameter (i.e., that should leverage existing frameworks of
> RIRs, etc) -- whether or not the functions are separated to different
> operators (see quote [3] below)
>
> 2/ Pear-shaped future -- the IAB determines that a new contractor is
> needed, works with the IAOC and IASA to establish criteria for selection
> of a new contractor, and then informs ICANN so that a notice period
> begins.  A transition then takes place where the function moves to the
> new  contractor, and is no longer performed by ICANN. (see quote [4] below)
>
> 3/ Rejection -- ICANN bows out of the business of providing IANA
> protocol parameter registry functions (see quote [5] below).
>
>
>
> And the question is not whether these are likely or desirable futures,
> but rather:  are there pieces missing from the suite of IETF
> documentation to handle the different angles of these possibilities?
>
> Leslie.
>
>
> [1] [Eliot Lear]
>>> 1/ Everyday IETF IANA protocol parameter registry activities,
>>> post-transition.
>> Let's call this State 1.
>>
>> Good looks like it does today. That's the good news   IETF policies
>> will continue to govern the policies by which codepoints are managed.
>> In the case of an operator change, things continue to function in just
>> this manner.  There is no confusion as to where a developer should go to
>> get a codepoint assignment or where a developer should go to find the
>> most current list of assignments.
>
>
> [2] [John Curran]
>> If that _is_ the case, then would the IETF(/IAB/IAOC) contract with
>> the new IANA
>> registry operator include provisions (T&C's or SoW) that the operator
>> work with
>> any IANA registry operators selected by other delegated registry
>> authorities
>> (ICANN, RIRs) so as to insure seamless publication of each IANA
>> registry space?
>> Such a requirement may mean the IETF's IANA registry operator putting
>> information
>> towards other IANA registry operators or picking up same for its own
>> publication,
>> depending on the particularly registry.
>
>
> [3] [John Curran]
>> This new protocol (NewIP) has its own unique IDs that must be made widely
>> available for the protocol to be adopted and thus successful, and it
>> is also
>> anticipated that these will be issued via a variety of schemes, e.g.
>> to new
>> equipment makers, to hobbyists who request blocks, to governments who
>> wish
>> to coordinate things in their country, etc.
> [snip]
>> Once the IETF decides what responsibilities it should have to the
>> communities
>> who are using publicly visible Internet identifier spaces, and decides
>> on an
>> approach for fulfilling these responsibilities going forward, the
>> result may
>> also prove helpful in determining what relationships (if any) the IETF
>> needs
>> with ICANN, the RIRs, and related parties doing Internet registry
>> operations;
>> that should be expected, as it is the same questions, only with
>> respect to the
>> publicly-visible identifier spaces that have already been deployed.
>
> [4] [Eliot Lear]
>  >> 2/ Non-everyday occurrences:  dissatisfaction with existing operator
>  >> -- making the change, impact afterwards; selection of alternate
>  >> operator for one or more registries;  competitive assignments
>  >> (squatting) on individual registries or registry values.
>  >
>  > How to get back to Good:
>  >
>  > In the case where we have reached what earlier called the pair shaped
>  > future, the IAB determines that a new contractor is needed, works with
>  > the IAOC and IASA to establish criteria for selection of a new
>  > contractor, and then informs ICANN so that a notice period begins.  A
>  > transition then takes place where the function moves to the new
>  > contractor, and is no longer performed by ICANN.
>  >
>
> [5] [Eliot Lear]
>  > In the case where ICANN determines that they can no longer support the
>  > function for one reason or another, they provide us notice, hopefully
>  > unofficially at first, and then we go find a new contractor, as
>  > described above, with the transition occurring, as described above.  In
>  > the end, we return to State (1).

-- 

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

---

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Sep 2014 14:55:22 -0700

At 13:40 23-09-2014, Leslie Daigle (TCE) wrote:
>My read/summary of where we have gotten in refining what the 
>scenarios are so far is as follows (please suggest corrections and 
>any additional scenarios we should yet look at):
>
>Discussion on the list highlighted that we are pretty comfortable 
>with the level of documentation/agreements for handling this onging 
>(see quote [1] below), with two exception cases to be examined:
>
>     + what happens if the 3 IANA functions are separated to 
> different operators  (see quote [2] below)

There are four functions covered by the NTIA/IANA Contract.

 From the Charter:

  "The IANAPLAN working group is chartered to produce an IETF consensus
   document that describes the expected interaction between the IETF and
   the operator of IETF protocol parameters registries."

My current understanding is the above does not cover the IANA 
functions which are supposed to be discussed by the other two 
"operational communities".  The Charter goes on to say that:

   "Should proposals made by other communities regarding the transition
    of other IANA functions affect the IETF protocol parameter registries
    or the IETF, the WG may also review and comment on them."

I have not seen any proposal from other communities.

Could the WG Chairs clarify whether discussions of "names" and 
"numbers" are within the scope of the Charter?

According to RFC 2418:

   "The agenda should contain at least:

    - The items for discussion;
    - The estimated time necessary per item; and
    - A clear indication of what documents the participants will need to
      read before the session in order to be well prepared."

 From the announcement ( 
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13248.html ):

   "The main agenda item is the first deliverable of the working group,
    where an individual draft will be discussed and reviewed to be
    adopted by the working group."

I assume that the individual draft which the announcement refers to 
is one written by Eliot and Russ.  There is no mention of that in the 
announcement.  I do not think that the announcement is in line with RFC 2418.

Regards,
S. Moonesamy

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 23 Sep 2014 19:57:27 -0400

Le 2014-09-23 à 17:55, S Moonesamy <[email-masked]> a écrit :
> 
> I assume that the individual draft which the announcement refers to is one written by Eliot and Russ.  There is no mention of that in the announcement.

Currently, to my knowledge, there is only one draft addressing the charter deliverable, and it is : http://www.ietf.org/id/draft-lear-iana-icg-response-01.txt.
If there are other drafts, then we will look at them.

Regards, Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 23 Sep 2014 20:00:39 -0400

Le 2014-09-23 à 17:55, S Moonesamy <[email-masked]> a écrit :
> 
> My current understanding is the above does not cover the IANA functions which are supposed to be discussed by the other two "operational communities".  The Charter goes on to say that:
> 

neither do I.

> 
> Could the WG Chairs clarify whether discussions of "names" and "numbers" are within the scope of the Charter?

that is not what is written above. What is written above in the charter is clear. 
>   or the IETF, the WG may also review and comment on them."

to my knowledge, there is no such proposal yet. When they will be ready, we will review them.

Marc.

---

From: "Richard Hill" <[email-masked]>
Date: Wed, 24 Sep 2014 09:10:21 +0200

Dear Leslie,

Thank you for this.

Regarding 1/, there is some disagreement regarding comfort with the level of
document/agreements if the NITA/ICANN IANA Functions contract is allowed to
expire.  Some are of the view that that IANA Functions contract has no
significance or effect, so whether it expires or not is of no consequence.
Others are of the view that the IETF/ICANN MoU and/or the ICANN Bylaws
should be reviewed and possibly modified if the IANA Functions contract
expires.

Thus this issue touches on your last question "are there pieces missing from
the suite of IETF documentation?"

Elliot's list of open issues correctly captures, as far as I can tell, the
detail of the open items, see:

  https://github.com/elear/IANA-Transition/issues

Best,
Richard

> -----Original Message-----
> From: Ianaplan [mailto:[email-masked]]On Behalf Of Leslie
> Daigle (TCE)
> Sent: mardi, 23. septembre 2014 22:40
> To: [email-masked]
> Subject: Re: [Ianaplan] Summary/refinement of scenarios discussed so far
> (was Constructive redirect -- focusing discussions)
>
>
>
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan
>

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Wed, 24 Sep 2014 09:48:15 -0400

Hi,

Let me try to be clearer on the text:

On 9/23/14 5:55 PM, S Moonesamy wrote:
>> are so far is as follows (please suggest corrections and any
>> additional scenarios we should yet look at):
>>
> My current understanding is the above does not cover the IANA functions
> which are supposed to be discussed by the other two "operational
> communities".  The Charter goes on to say that:
>

No.

The context of the discussions I was summarizing and, indeed, the text 
written, were focused on what happens to the protocol parameter registry 
in the hypothetical case of a separation of operators.

We're only talking about the protocol parameters registries here.

Thanks,
Leslie.

> I assume that the individual draft which the announcement refers to is
> one written by Eliot and Russ.  There is no mention of that in the

-- 

"Reality:
      Yours to discover."
                                 -- ThinkingCat
[email-masked]

--

---

From: John Curran <[email-masked]>
Date: Wed, 24 Sep 2014 10:18:45 -0400

On Sep 24, 2014, at 9:48 AM, Leslie Daigle (TCE) <[email-masked]> wrote:
> ...
> The context of the discussions I was summarizing and, indeed, the text written, were focused on what happens to the protocol parameter registry in the hypothetical case of a separation of operators.
> 

Leslie -

I think that makes perfect sense, and I concur with the commonly accepted
meaning that you intend...  

However, it is worth noting that the DNS root zone, the IP address spaces, 
and ASN spaces are literally also protocol parameter fields established by 
IETF protocol specifications, and also do constitute IANA registries.  Some
portions of these parameter spaces have been delegated policy authority to
other bodies (ICANN, RIRs) but the IETF still makes entries in these same
spaces for technical/specialized reservations.

It might be helpful to clarify if these parameter spaces are included in the 
scope (in which case ICANN and the RIRs simply provide general purpose entries 
or policy to the same IANA operator designated by the IETF), or whether these 
spaces are fully delegated along with policy authority (in which case ICANN 
and the RIRs must direct their respective IANA operators to accept technical 
policy from the IETF for specialized/reserved entries.)  This presumes, of 
course, that each parameter space is not split in publication, i.e. that 
each are published in one location by a single definitive IANA operator.

FYI,
/John

Disclaimer: my views alone.

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Sep 2014 06:53:58 -0700

Hi Leslie,

[snip]

>The context of the discussions I was summarizing and, indeed, the 
>text written, were focused on what happens to the protocol parameter 
>registry in the hypothetical case of a separation of operators.
>

Thanks for making it clearer (and thanks to Marc for the quick response).

Regards,
S. Moonesamy

---

From: Jefsey <[email-masked]>
Date: Wed, 24 Sep 2014 18:11:54 +0200

Subramanian,

I will use your mail to summarize the WG current achievements while 
waiting for the Chairs' decision regarding my request to the IESG for 
an appropriate review of our charter that is needed to permit a 
complete and responsible multistakeholder based IETF response to the 
NTIA March 14, 2014 questions posed to ICANN.

A. Other communities
     ==============

>ready, we will review them.

This calls for two remarks :

1.  To my knowledge the charter does not specify two communities.

I want to make clear that I belong the Internet Users Community and I 
speak as one of its member, i.e. as an "IETF Customer" as we are 
sometimes inadequately qualified in some texts. The interests of my 
community were traditionnally supposed to be conveniently represented 
by the US procurement process and the quality of its obtained 
deliveries guaranteed by the expertise of its Contracting Officers.

As part of this US procurement process the US NTIA currently 
contracts with ICANN to carry out the Internet Assigned Numbers 
Authority (IANA) functions and has a Cooperative Agreement with 
Verisign under which it performs related root zone management 
functions. The NTIA's responsibility includes the procedural role of 
administering changes to the authoritative root zone file – the 
database containing the lists of names and addresses of all top-level 
domains – as well as serving as the historic steward of the DNS 
"ICANN/NTIA" Class "IN".

1.1. On March 14, 2014, to support and enhance the multistakeholder 
model of Internet policymaking and governance, the U.S. Commerce 
Department's National Telecommunications and Information 
Administration (NTIA) announced its intent to transition key Internet 
domain name functions to the global multistakeholder community. As 
the first step, NTIA has asked the Internet Corporation for Assigned 
Names and Numbers (ICANN) to convene global stakeholders to develop a 
proposal to transition the current role played by NTIA in the 
coordination of the Internet's domain name system (DNS). 
Transitioning NTIA out of its role marks the final phase of the 
privatization of the DNS as outlined by the U.S. Government in 1997.

1.2. NTIA has informed ICANN that it expects that in the development 
of the proposal, ICANN will work collaboratively with the directly 
affected parties, including the Internet Engineering Task Force 
(IETF), the Internet Architecture Board (IAB), the Internet Society 
(ISOC), the Regional Internet Registries (RIRs), top level domain 
name operators, VeriSign, and other interested global stakeholders. 
This point seems to have been singularly misunderstood by ICANN 
increasing some global stakeholders distrust already expressed in 
Dubai, on Dec 14, 2012:

- ICANN seems to confuse the development of a proposal to transition 
the current role played by NTIA in the coordination of the Internet's 
domain name system "ICANN/NTIA" Class "IN" with a take-over of the 
entire NTIA responsibilities.
- and, in so doing, not to consider the concerns of the "interested 
global stakeholders" presently relying on the sovereign authority, 
requirements and expertise of the US procurement process as if it was 
going to disappear.

2. The Chair states that "there is no such proposal yet. When they 
will be ready, we will review them".

This is an important change from the Charter and only says that the 
WG may review and comment them.

B. Other communities
     ==============

>At 15:48 24/09/2014, Leslie Daigle (TCE) wrote:

This "status-quo" position is clearly stated by the chairs. It 
opposes every possibility of innovation or the discussion of special 
cases resulting from IUse, Name and Numbers communities where names, 
numbers and parameters could be entangled.

C. First deliverable
     ============

>is one written by Eliot and Russ.  There is no mention of that in 
>the announcement.  I do not think that the announcement is in line 
>with RFC 2418.

At 01:57 24/09/2014, Marc Blanchet wrote:
>Currently, to my knowledge, there is only one draft addressing the 
>charter deliverable, and it is : 
>http://www.ietf.org/id/draft-lear-iana-icg-response-01.txt.

This means that this draft is the main agenda item.

This draft is in two sections.

- "Section 1 contains an introduction that is sourced solely within the IETF".
- "Section 2 contains the questionnaire that was written by the ICG 
and a formal response by the IETF."

I note that Section 2 presents a formal response by the IETF most 
probably based upon an IETF doctrine which should be sourced in 
Section 1, but is not.

It therefore means that we need to build up an IETF doctrine, based 
upon a WG Charter considering the IETF responsibility to the internet 
and its multiple global stakeholders begining with (IMHO) with the 
Internet Users. This charter MUST differentiate the parameters free 
availability and their publication of reference.

This draft states that "Because of the nature of the agreement, 
questions of jurisdiction are immaterial". This is in opposition with 
the IETF Trust which was formed on December 15, 2005, for, among 
other things, the purpose of acquiring, holding, maintaining and 
licensing certain existing and future intellectual property used in 
connection with the Internet standards process and its 
administration. Accordingly, pursuant to RFC 5378, Contributors to 
the IETF Standards Process grant the IETF Trust certain licenses with 
respect to their IETF Contributions, the IETF Trust grants in its 
turn to others, among other channels through the registry operators 
such as IANA. Some IETF works or derivative works from IETF works may 
be constrained according to the jurisdiction.

D. The Milestones
      ===========

The Milestones are therefore :

- to review the Charter with the IESG
- to build a consensual IETF doctrine regarding
--- the NTIA request concerning the transition of its DNS 
"ICANN/NTIA" class "IN" resposibilities to ICANN.
--- the consequences for the Internet and its global 
multistakeholders and communities (RFC 6852) of the NTIA's IANA transition.
- respond to the questions of the ICG regarding the DNS "ICANN/NTIA" 
class "IN" resposibilities to ICANN.
- respond adequately to the question of the ICG and other global 
multistakeholders and communities irt. the consequences of the NTIA's 
IANA transition

Due to the importance of these issues and the need for considerable 
considrations and universal consensus, a confirmation by Lawrence 
Strickling is necessary: is the date of Sept 30, 2015 the date for 
the DNS "ICANN.NTIA" Class "IN" root file management or for the whole 
IANA functions transition?

jfc

---

From: S Moonesamy <[email-masked]>
Date: Wed, 24 Sep 2014 10:58:10 -0700

Hello,

I trimmed the Cc.

>1.  To my knowledge the charter does not specify two communities.

Strictly speaking , the above is correct.

>I want to make clear that I belong the Internet Users Community and 
>I speak as one of its member, i.e. as an "IETF Customer" as we are 
>community were traditionnally supposed to be conveniently 
>represented by the US procurement process and the quality of its 
>obtained deliveries guaranteed by the expertise of its Contracting Officers.

Ok.

>WG may review and comment them.

The WG Charter is at 
https://datatracker.ietf.org/wg/ianaplan/charter/  I do not view that 
sentence from the WG Chair as a change.

>numbers and parameters could be entangled.

My view is that the WG Chair clarified what the discussion was about 
in response to what I asked.  I did not ask about "status-quo".

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Sep 2014 08:55:46 +1200

> each are published in one location by a single definitive IANA operator.

RFC 2860 doesn't seem to me to be at all unclear on this in the case
of TLDs and IP addresses. You do need to read all the words though:

   4.3. Two particular assigned spaces present policy issues in addition
   to the technical considerations specified by the IETF: the assignment
   of domain names, and the assignment of IP address blocks. These
   policy issues are outside the scope of this MOU.

   Note that (a) assignments of domain names for technical uses (such as
   domain names for inverse DNS lookup), (b) assignments of specialised
   address blocks (such as multicast or anycast blocks), and (c)
   experimental assignments are not considered to be policy issues, and
   shall remain subject to the provisions of this Section 4.  (For
   purposes of this MOU, the term "assignments" includes allocations.)

That doesn't actually exempt technical considerations at all. It only
exempts "policy" aspects from IETF direction.

The MoU is silent on ASNs, so formally IANA has to do exactly what
the IETF tells it.  I think there's a pretty strong consensus that
the "policy" aspects of ASNs are best treated in accord with the
RIR community, though. Anything else would be stupid.

    Brian

---

From: John Curran <[email-masked]>
Date: Wed, 24 Sep 2014 17:24:16 -0400

> exempts "policy" aspects from IETF direction.

Acknowledged... I have said the same on many occasions.

> RIR community, though. Anything else would be stupid.

So is the publication of all IANA registries (including IP address spaces) 
provided for in the current MoU?  Or do the RIRs need to contract for "an 
IANA operator" to publish their portion of the address space?  From your 
statement above, I would think that the RIRs only have to provide the 
relevant global policy for the general-purpose portion to the IETF's IANA, 
and then that IANA operator would follow that policy so long as it did not 
conflict (effectively, the IETF arranges for an IANA operator, but both 
IETF and the RIR community provide the necessary policy for its operation.)  
If that is correct, it implies a slightly larger scope of issues (to be
planned for during an IANA operator change) than Leslie suggested.

FYI,
/John

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 24 Sep 2014 19:13:44 -0400

> spaces for technical/specialized reservations.

I think we need to treat the number and name cases distinctly, because
the actual rules in each case are in fact different.  I am more
familiar with the names case, so I'll start with the easy one.

RFC 6761 established rules for how the IETF establishes special use
for DNS names.  An important part of the specification is that a
proposed reservation has to answer questions in 7 categories.  As the text says,

   The specification also MUST state, in each of the seven "Domain Name
   Reservation Considerations" categories below, what special treatment,
   if any, is to be applied.  If in all seven categories the answer is
   "none", then possibly no special treatment is required and requesting
   reservation of a Special-Use Domain Name may not be appropriate.

Given that such reservations have to have either standards action or
IESG approval, I think it's going to be pretty hard to get a
reservation "in the root zone" by the IETF special-use registry.

Instead, the special-use registry really reserves names from _being_
in the root zone.  This is therefore not actually the IETF treading on
a space managed by ICANN -- the actual root zone -- but instead a way
of the IETF identifying what should or should not possibly be a
candidate for the root zone.  This is because, in the name space, a
name may or may not exist.  (This is indeed the very point of the Name
Error or NXDOMAIN, RCODE==3 answer of the DNS protocol.)

Now, things are a little different in the IP address space, because
there's an important sense in which the address space is "gapless".
Because of the strictly hierachical nature of addressing, any given
address is contained inside some range; and because ranges are what is
delegated, it isn't strictly the case that a given address is excluded
from the range.  But all of this flows from how routing works in the
first place, and that is strictly a function of network protocols in
the first place.  Since the IETF is the place where those protocols
are defined, it makes sense that the IETF can reserve parts of the
number space exactly as it can define other types of behaviour.
Therefore, in _that_ sense the IETF is not making an entry "in a
space" that is delegated elsewhere, but is instead defining the nature
of the delegation as a matter of protocol.  Therefore,
 
> spaces 

this "these spaces" claim is not actually correct: the IETF ois not
making an entry inside a space delegated to someone else or making
policy inside someone else's space, but is instead drawing the
boundaries where different policy actors reside.

At least, that's my view.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John Curran <[email-masked]>
Date: Wed, 24 Sep 2014 19:22:14 -0400

> boundaries where different policy actors reside.

Understood.  My question was different... Does the IETF take responsibility
for arranging for IANA registry services for all of the IANA registries (a
contract which would say, just as RFC 2860, that there are other sources of
policy for some spaces), or do the RIRs and ICANN need to also contract for 
IANA services for their respective portions of these spaces?

Thanks!
/John

---

From: JFC Morfin <[email-masked]>
Date: Thu, 25 Sep 2014 01:36:58 +0200

At 19:58 24/09/2014, S Moonesamy wrote:
>https://datatracker.ietf.org/wg/ianaplan/charter/  I do not view 
>that sentence from the WG Chair as a change.

As explained I used your mail because it listed the pending points. 
My evaluations are mine. They do not claim to be yours.

The charter says "may", the chair says "will". The charter says 
"communities", it is now agreed there are not only two communities.
It therefore means that a I_D presented by the IUse community will be 
discussed.

This is a step in the good direction.

>>opposes every possibility of innovation or the discussion of 
>>special cases resulting from IUse, Name and Numbers communities 
>>where names, numbers and parameters could be entangled.
>

Again my evaluations are mine and do not claim to be yours.

I did ask a review of the charter. The co-chair responded the WG 
would follow a "status-quo" line unless directed otherwise by the IESG.

Members of my community therefore call for this WG to discuss a 
Charter review with the IESG in order to make it consistent with the 
context of our reality, as we believe it differs from the ICANN 
virtuality. This is an effort toward a concerted dialog and in order 
to avoid the complication of an appeal against a far too restrcitive 
Charter, in the post WCIT international political context and the 
observed insidious NTIA question creep from DNS class "IN" root file 
oversight to IANA functions.

jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Sep 2014 12:06:23 +1200

> IANA services for their respective portions of these spaces?

Now that's a good question. I'm thinking that if a parameter space
was created by IETF action (or by the IETF's predecessors, since there
are things here that date back before 1986) then logically the IETF should
contract for the *existence* of the whole registry, even if some parts
of the registry are no longer populated under IETF technical direction.
But I don't think the IETF should be held responsible for the *contents*
of those parts of the registry. (IANAL, so I will not attempt to discuss
how this should be expressed in formal language.)

    Brian

---

From: JFC Morfin <[email-masked]>
Date: Thu, 25 Sep 2014 03:11:23 +0200

>IANA services for their respective portions of these spaces?

Dear John and Andrew,

All this makes interesting "details", but let be pragmatic - these 
are ***past*** concerns.

Why do you think the NTIA buddies are leaving the sinking ship (i.e. 
the SS "Status-Quo")? The NTIA has tried an electro shock wake-up. 
Either we collectively respond or we fork.

- What about ION and ULA wanting to become sovereign? What about the 
Rosetta yearly budget in a few years?
- What about the Chinese DNS? What about keywords? What about the 
35.000 DNS classes?
- What about NDN (http://named-data.net)?

Open cooperation with the new commers or rigid competition among 
retiring class mates?
Guess who will win if status-quo prevails: I*club or stakeholders/IUsers?

If you genuinely feel I am bandying troll's ideas around, I accept 
the possibility. However, just explain me why you do think I and 
users should not worry and why an open, stable and universal IANA 
"status-quo" will 100% prevail.

jfc

---

From: Seun Ojedeji <[email-masked]>
Date: Thu, 25 Sep 2014 05:52:26 +0100

This response to John's critical question hits me as a jackpot! Hopefully
we'd then focus on such contract content

Cheers!

sent from Google nexus 4
kindly excuse brevity and typos.
On 25 Sep 2014 01:06, "Brian E Carpenter" <[email-masked]>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 25 Sep 2014 07:29:33 -0700

Hello,
>My evaluations are mine. They do not claim to be yours.

I understood that as it was made clear in the first paragraph.

>would follow a "status-quo" line unless directed otherwise by the IESG.

There are some assumptions [2] in the Charter.  I assume that you are 
referring to those assumptions as the "status-quo" line.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/ianaplan/current/msg00411.html
2. A thing that is accepted as true or as certain to happen, without proof.

---

From: Jefsey <[email-masked]>
Date: Thu, 25 Sep 2014 20:01:09 +0200

At 16:29 25/09/2014, S Moonesamy wrote:
>There are some assumptions [2] in the Charter.  I assume that you 
>are referring to those assumptions as the "status-quo" line.

No. I refer to the clear response of the co-Chair, Leslie Daigle.
The best way to be wrong is to assume rather than ask :-);
however, assuming that something is assumed may be worse.
jfc

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 25 Sep 2014 16:38:46 -0700

Hi John,

>IANA services for their respective portions of these spaces?

I would actually spin this question around a little, in light of the
existence of the IETF-ICANN MOU. If the RIRs are concerned that the MOU
would interfere with their ability to change operators in the future, then
I think they should raise those concerns (although I would argue that the
time to deal with that would be the point at which the RIRs want to change
operators, which I presume is not now). If that is not a concern, or not a
concern to be dealt with in the context of the transition and assuming the
RIRs want to continue using the same operator they use now, I’m not sure
there is anything further on this topic that needs discussion in IANAPLAN.

Alissa

---

From: John Curran <[email-masked]>
Date: Thu, 25 Sep 2014 20:39:06 -0400

On Sep 25, 2014, at 7:38 PM, Alissa Cooper <[email-masked]> wrote:

>> Understood.  My question was different... Does the IETF take
>> responsibility for arranging for IANA registry services for all of the IANA registries (a
>> contract which would say, just as RFC 2860, that there are other sources
>> of policy for some spaces), or do the RIRs and ICANN need to also contract
>> for IANA services for their respective portions of these spaces?
> 
> I think they should raise those concerns 

I have no idea if there are such concerns; to my knowledge, the IANA
stewardship transition planning discussions in the RIRs is only now 
underway (starting with the recent APNIC meeting), so the outcomes 
and/or concerns that might emerge are indeterminate at this time.

> ... (although I would argue that the

If the IETF feels that it is contracting for IANA registry services 
for all of the IETF parameters spaces (including IPv4, IPv6, and ASNs), 
that would be important to know.  IF the output of the IANAplan process 
doesn't assume such, that would also worth documenting clearly. Sharing
such assumptions will hopefully make the resulting proposals easier for
the ICG to successfully collate into a single plan.

The present existence of the NTIA contract implies joint binding of 
the IANA registry services, hence why this has not been an issue.
Absent such a contract (which is the environment that IANAplan must
address by definition), it should not be left unspecified or we risk
proceeding with different assumptions that could conflict at some point 
in the far future, with rather adverse consequences to the IANA services
as a result.

/John

---

From: Jefsey <[email-masked]>
Date: Fri, 26 Sep 2014 10:22:12 +0200

>the IANA registry services, hence why this has not been an issue.

John,
we are not discussing the past or present contractual situation and 
technology.
We have to invent a permanent functionnal architectonic framework.
Past and presents are only experiences of how things may work and 
where risks are possible.

This WG should only consider:

- what is the demand?
- where is the offer?
- how the offer is to be best addressed in considering the demand and 
offer needs?
- what are the resulting precautionary constraints on the operator(s)?

Our proposition is to be resillient if things turn berserk or simply 
if the Internet evoluates as an hybrid SDN.
jfc

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Sep 2014 10:28:57 +0200

Hi John,

My personal views...

> the ICG to successfully collate into a single plan.

I believe that the flow is like this:

 1. Assignment of registries by the IAB/IETF to RIRs, ICANN, etc.
 2. RIRs and ICANN may choose how those registries are operated.

The IETF retains policy policy for all other registries.  We do not
retain policy authority for unicast ip addresses or DNS names with the
exception that approaches taken by the RIRs and ICANN must be
technically consistent with the Internet architecture, which will evolve
(I hope).  The IETF and IAB retain responsibility for that.

Given what I've written, what do you believe is necessary?

Eliot

---

From: John Curran <[email-masked]>
Date: Fri, 26 Sep 2014 08:10:39 -0400

On Sep 26, 2014, at 4:28 AM, Eliot Lear <[email-masked]> wrote:
> Assignment of registries by the IAB/IETF to RIRs, ICANN, etc.
> RIRs and ICANN may choose how those registries are operated.
> The IETF retains policy policy for all other registries.  We do not retain policy authority for unicast ip addresses or DNS names with the exception that approaches taken by the RIRs and ICANN must be technically consistent with the Internet architecture, which will evolve (I hope).  The IETF and IAB retain responsibility for that.

Eliot -
 
   If what you have written can be made readily apparent (either via an updated RFC 2860,
   RFC 6220, or draft-iab-iana-framework++), that should suffice at a high-level for improving
   understanding of the various roles.

   Note that these identifier spaces span multiple registries (for example, the IPv6 space 
   has reservations based on technical architecture of the protocol, as well as space that 
   is "IETF Reserved", Global Unicast space, and delegations from Global Unicast to RIRs 
   per RFC 1881 and RIR Global IPv6 Allocation policy which has been provided to IANA)
   Publication of the entire "IPv6 address space" currently spans the full range of possible
   IPv6 identifier space, and is actually reflected in multiple IANA registries - 
      <http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml>
      <http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml>
      <http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml>
      <http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml>
   All of these are IPv6 identifier space, and there are times when they have to be treated
   as a single space (e.g. the coordination for reverse DNS support per RFC 5855.)

   When you indicate that "RIRs and ICANN choose how those registries are operated",
   do you mean with respect to the entire identifier space? (with appropriate liaison back
   with the IETF for technical reservations, etc.), or do you mean simply the delegated
   portion of the identifier space? (which is implies that the IETF contracts for the overall
   identifier space publication and that IANA operator coordinates with any RIR/ICANN
   delegated registry operator(s) as needed.)   I believe that either approach to delegated 
   registries can be made to work, but the choice is obviously impactful to the statement
   of work for the IANA operator(s) and any and therefore the SLA's, escalation procedures 
   and parties involved in the accountability mechanisms.  For example, if it is the entire 
   identifier space for which the RIRs/ICANN arranges for the IANA publication (with 
   appropriate liaison back to IETF for reserved entries), then one might expect that such
   an delegated IANA registry operator to have some accountability to the IETF in addition 
   to the party which contracted it, since it is publishing more that simply the delegated 
   portion of the identifier space...

Thanks!
/John

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Sep 2014 14:39:13 +0200

Again, my view alone.  I do not yet see what text should change in any
of the documents you mentioned, but perhaps you do?

On 9/26/14, 2:10 PM, John Curran wrote:

>    portion of the identifier space?

To me it is the latter, although we could quibble about the word
"delegated".  The importance of this point cannot be understated.  If
new uses of the IP address space are to be defined, that should happen
in the IETF based on IETF policies. 

> (which is implies that the IETF contracts for the overall

See above.

Eliot

---

From: John Curran <[email-masked]>
Date: Fri, 26 Sep 2014 10:27:33 -0400

Eliot - 

I believe there should be clearer text somewhere specifying what a 
"delegation of policy authority for a portion of an identifier space" 
actually means, what needs to be specified to make such a delegation, 
given that the delegated policy authority must maintain a portion of 
the IETF's public registry for a given identifier space. For example, 
should such a delegation include:

 - Identification of the delegated space?
 - Identification of the party serving as policy authority?
 - Duration and conditions (if any) on the policy delegation?
 - Any policy constrains (other than technical) that the IETF
   requires (as part of the agreement of the delegation)?
 - Any operational/reporting/SLA mechanisms regarding registry
   administration/publication that the IETF expects of the
   delegated policy authority or its IANA registry contractor?

As it is, we've got a set of ah-hoc documents covering some of these
aspects in a very uneven manner, and while none of that particularly
matters while it is all under a single IANA operator (and a single 
NTIA contracting umbrella), we are looking at responsible stewardship 
of the entire IANA registry system under different circumstances in
the future.

> in the IETF based on IETF policies. 

If it is the latter (parties delegated as policy authorities for 
portions of Internet identifier space arrange for appropriate IANA 
registry publication services for that portion), then that presumes
that the IETF takes responsibility for overall publication of the 
identifier space, e.g. the IETF arranges for its IANA operator to 
basically perform per RFC 2860 for all IETF IANA registry spaces, 
except from those specific portions for which policy authority has 
been delegated to another party.

Those other parties (ICANN, RIRs) have to arrange for IANA registry
publication services (hopefully from the same IANA operator, but not
necessarily)  Does the IETF have requirements of accountability on
those IANA registry operators who are administrating these delegated
spaces per the delegated registry policy authorities?  For example,
can the publication of a delegated registry be closed? (not generally 
available to the public, but only certain authorized parties) Can a 
delegated policy authority charge for visibility into their portion 
of the identifier space, if they so choose? Is it entirely up to the 
delegated registry policy authority how such is handled?  

If there are any assumptions or constraints on parties delegated as
portion of Internet identifier spaces, or those they contract as IANA 
registry operators, then now is probably the time for such to be plainly
documented, since any implied mechanisms per RFC 2860 or the NTIA IANA 
contract may not be applicable post any IANA transition.  If it appears
there are no assumptions to be documented at this time, then that is 
also fine, but we should recognize that there may be situations in the 
future (with mismatched expectations across a given identifier space) 
that, absent such documentation, will not resolve as easily as today 
should the IANA registry system become more distributed in nature.

FYI,
/John

---

From: John Curran <[email-masked]>
Date: Fri, 26 Sep 2014 14:17:59 -0400

Also, for sake of clarity, I do not believe that the IETF must define 
a formal framework for how to delegate policy authority for portions 
of registry space; I am simply noting that having a framework for doing 
so would make determining the IANA-related aspects much easier.

/John

---

From: Milton L Mueller <[email-masked]>
Date: Tue, 30 Sep 2014 20:55:55 +0000

> scope (in which case ICANN and the RIRs simply provide general purpose
> entries or policy to the same IANA operator designated by the IETF), or
> whether these spaces are fully delegated along with policy authority (in
> which case ICANN and the RIRs must direct their respective IANA operators
> to accept technical policy from the IETF for specialized/reserved entries.)
> This presumes, of course, that each parameter space is not split in
> publication, i.e. that each are published in one location by a single definitive
> IANA operator.

John: I have trouble understanding what you mean by "published in one location by a single definitive IANA operator." The DNS root zone file is published by Verisign, which is neither the same location nor the same entity as ICANN's IANA subsidiary. So I think we are clearly dealing with the second of your either/or options:  

" these spaces are fully delegated along with policy authority (in which case ICANN and the RIRs must direct their respective IANA operators to accept technical policy from the IETF for specialized/reserved entries.)"

...and we have been since 1991.

---

From: John Curran <[email-masked]>
Date: Tue, 30 Sep 2014 19:13:50 -0400

On Sep 30, 2014, at 4:55 PM, Milton L Mueller <[email-masked]> wrote:
> John: I have trouble understanding what you mean by "published in one location by a single definitive IANA operator." The DNS root zone file is published by Verisign, which is neither the same location nor the same entity as ICANN's IANA subsidiary.

The DNS root zone is published as a single zone, i.e. a single identifier space,
even though entries are present in that zone due to different policy bodies...
e.g. it contains .arpa per the direction of the IETF, and most other entries 
would be acknowledged to be there per the authority that the DNS community 
recognizes via ICANN.

In the present case of DNS root zone, it is true that the IANA operator 
is not the same party as the one doing the publication.  That was not 
my point, and I should have foreseen such confusion due to that unique
aspect of present DNS publication.

My actual point was that there are not two partial sources of DNS zones, 
one from the IETF with those entries it placed within and a second root 
zone coming from ICANN; there is simply a single zone which the IANA 
operator recognizes contains entries from both. 

> So I think we are clearly dealing with the second of your either/or options:  
> 

Milton - One can argue that it is either way, but that's independent of the 
fact that publication in the DNS case takes place via third party. 

Use this phrasing (without "published") instead - 

"This presumes, of course, that each parameter space is not split via multiple
IANA operators i.e. that each identify space is administered in one location 
by a single definitive IANA operator, as opposed to multiple contracted IANA 
operators which sometimes have only responsibility for a portion of a parameter 
space and hence have to inter-coordinate"

The easiest way to see the two alternatives is simply to look at the failure 
conditions and  see what contract is triggered...  If there were a third-party 
IANA operator contracted by IETF, ICANN, and the RIRs, and it somehow failed to 
correctly include .ARPA in the DNS root zone, would that be an potential service 
level condition for IETF to IANA operator contract or the ICANN to IANA operator
contract?  If the IANA operator is contracted to administer the entire root zone 
by ICANN and is just accepted reserved entries from the IETF, then this failure 
to perform is a ICANN management-IANA operator management discussion (which I'm 
certain the IETF would be made aware of in short order... :-) 

Alternatively, the IETF has contracted for publication of not only its various
technical parameter registries but also for the reserved entries in spaces that 
have otherwise been delegated.  In this case, an omission of ".arpa" is a service 
level condition for that IETF to IANA operator contract.  The downside of the latter 
approach is that the IANA operator has much higher coordination responsibilities
for registry spaces administered due to multiple IANA service contracts that only 
collectively span the entire registry space.

FYI,
/John