Subject: [Ianaplan] I-D Action: draft-ietf-ianaplan-icg-response-01.txt

From: [email-masked]
Date: Thu, 16 Oct 2014 09:25:06 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Planning for the IANA/NTIA Transition Working Group of the IETF.

        Title           : Draft Response to the Internet Coordination Group Request for Proposals on IANA
        Authors         : Eliot Lear
                          Russ Housley
	Filename        : draft-ietf-ianaplan-icg-response-01.txt
	Pages           : 27
	Date            : 2014-10-16

Abstract:
   This document contains the a draft response to a request for
   proposals from the IANA Stewardship Transition Coordination Group
   regarding the protocol parameters registries.  It is meant to be
   included in an aggregate proposal that also includes contributions
   covering names and addresses that will be submitted from their
   respective operational communities.  The IETF community is invited to
   comment and propose changes to this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ianaplan-icg-response-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Oct 2014 19:01:03 +0200

Hi everyone,

Of course feel free to use the "diff" tool on www.ietf.org to review all
the changes, but here is a brief summary:

  * Based on comments from Alissa I've removed the front material, and
    inserted the entire RFC into an Appendix.  Similarly, the entire
    charter is also now an appendix.
  * Based on comments from the working group, there is modified text
    regarding jurisdiction.  It is important when you read the question
    about jurisdiction that you also look at proposed changes in Section
    III of the RFP.
  * Proposed changes of the RFP now includes a request of the IAOC to
    pursue a supplemental agreement to address the following issues:
      o jurisdiction – based on discussion in the working group;
      o transitional issues as relates to the contract, as suggested by
        John Curran;
      o handling of names and marks, as suggested by Milton Mueller (the
        compromise case); and
      o clarity on the public domain nature of the IANA database
  * Transitional issues now contains a statement that the supplemental
    agreement(s) should be concluded, as suggested by Miles Fidelman.

I would like to note two omissions which I intend to correct in the next
version.  Based on the above, acknowledgment should be given to Alissa
and Miles.  This is not done yet, and for that I apologize.

Eliot

On 10/16/14, 6:25 PM, [email-masked] wrote:
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan
>
>

---

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 17 Oct 2014 09:32:48 +0200

Hi Eliot,

I don't see any of my suggestions incorporated or discussed.

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

Andrei

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Oct 2014 10:07:22 +0200

Hi Andrei:

Thanks for catching these.  Let's take them one at a time:

> IETF Response:
> >    The protocol parameter registries are the product of IETF work.
> >    Administration of the protocol parameter registries is the service
> >    that is provide to the IETF.
> > 
>
> I wonder if we should be more specific here, especially regarding the
> overlapping registries and services:
>
> "IETF Response:
>
> The protocol parameter registries are the product of IETF work. These
> include the Internet numbers registries for which the IETF defines the
> overall structure and maintains specific sub-registries (such as
> Special-Purpose IP Address Registries [RFC6890], IPv4 Multicast Address
> Space Registry [RFC5771] and IPv6 Multicast Address Space Registry
> [RFC3307]) as indicated in their registration procedure.
>
> Administration of the protocol parameter registries is the service that
> is provide (sic, should be "provided") to the IETF."

Apart from the grammar fix, I don't agree that this is an appropriate
change.  You have singled out a small number of registries, when in fact
there are hundreds.  The ones you have singled out are discussed below,
with two exceptions (see below).

> >       The IETF has established registries with IANA for special IPv4 and
> >       IPv6 assignments.  These are specified in [RFC6890].  The IETF
> >       coordinates such assignments with the RIRs.
> > 
>
> The IETF defines the overall structure of the internet number registries
> and maintains sub-registries for special IPv4 and IPv6 assignments.
> These are specified in [RFC3307, RFC5771 and RFC6890].  The IETF
> coordinates such assignments with the RIRs.

I prefer your text because you have captured the appropriate
references.  Barring objections I will add it to the next version.

> >    o  IETF standards changes may have impact on operations of RIRs and
> >       service providers.  A recent example is the expansion of the BGP
> >       community field from 16 to 32 bits.[RFC6793]  It is important to
> >       note that this change occurred out of operational necessity, and
> >       it demonstrated strong alignment between the RIRs and the IETF.
>
> I think it should refer to four-octet ASNs, so:
>
>    o  IETF standards changes may have impact on operations of RIRs and
> service providers.  A recent example is the extensions to BGP to carry
> the Autonomous System numbers as four-octet entities [RFC6793]. It is
> important to note that this change occurred out of operational
> necessity, and it demonstrated strong alignment between the RIRs and the
> IETF.

I prefer your text because you have more properly referred to the change
that occurred.  Barring objections I will add it to the next version.

Thanks again for catching my omissions.

Eliot

---

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 17 Oct 2014 10:18:39 +0200

Thank you Eliot,

> with two exceptions (see below).

I think I might have not been clear enough (my mistake). What I wanted
to say that apart from registries commonly viewed as protocol parameter
registries, e.g. http://www.iana.org/protocols, the Internet numbers
registries are also under the IETF purview (e.g. compare with
http://www.ietf.org/assignments/).

Would the following resolve the issue:

"The protocol parameter registries are the product of IETF work. These
*also* include the Internet numbers registries..."?

Or are you pointing to a different issue?

Thanks,

Andrei

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Oct 2014 10:23:30 +0200

> *also* include the Internet numbers registries..."?

I understand what you are saying.  I am somewhat concerned that we not
have another debate about who is in charge of unicast addresses in
particular.  I don't think there is an issue with this between the RIRs
and the IETF at the moment, and would not want to create one.

But maybe I am shadow boxing?

Eliot

---

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 17 Oct 2014 10:31:57 +0200

> But maybe I am shadow boxing?

Well, parts of the global numbers registry are clearly under the IETF
authority. We are not saying that IETF delegated other parts to other
parties, but do say that the IETF defined the overall structure.

I don't think this will be seen as the IETF hegemony, but it is an
important stick in the ground IMO. But indeed, we may want to check the
views of the numbers community informally (e.g. with a newly created
CRISP team), and not discover a clash at the ICG level.

Andrei

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 17 Oct 2014 11:47:47 +0200

Dear Eliot,

Thanks for this.  I just have one suggestion, which is I think purely editorial.

In III, under "IETF Response", it starts with:

"No changes are required, ..."

But then some changes are listed.  So I think that it would be more accurate to start with:

"No major changes are required, ..."  or something like that.

Best,
Richard
 
-----Original Message-----
From: Ianaplan [mailto:[email-masked]]On Behalf Of Eliot Lear
Sent: jeudi, 16. octobre 2014 19:01
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Ianaplan] I-D Action: draft-ietf-ianaplan-icg-response-01.txt

Hi everyone,

Of course feel free to use the "diff" tool on www.ietf.org to review all the changes, but here is a brief summary:

Based on comments from Alissa I've removed the front material, and inserted the entire RFC into an Appendix.  Similarly, the entire charter is also now an appendix. 
Based on comments from the working group, there is modified text regarding jurisdiction.  It is important when you read the question about jurisdiction that you also look at proposed changes in Section III of the RFP. 
Proposed changes of the RFP now includes a request of the IAOC to pursue a supplemental agreement to address the following issues: 
jurisdiction – based on discussion in the working group; 
transitional issues as relates to the contract, as suggested by John Curran; 
handling of names and marks, as suggested by Milton Mueller (the compromise case); and

clarity on the public domain nature of the IANA database 
Transitional issues now contains a statement that the supplemental agreement(s) should be concluded, as suggested by Miles Fidelman. 
I would like to note two omissions which I intend to correct in the next version.  Based on the above, acknowledgment should be given to Alissa and Miles.  This is not done yet, and for that I apologize.

Eliot

Abstract:

---

From: John Curran <[email-masked]>
Date: Fri, 17 Oct 2014 05:48:35 -0700

> and the IETF at the moment, and would not want to create one.

Whether the special purpose (e.g. multicast) registries are mentioned does
not seem as important as having RFC 7020 and RFC 7249 directly referenced.  

A statement to the effect that policy authority for general purpose (i.e the 
non-technical/specialized) portions of the IPv4, IPv6, and ASN spaces have 
been delegated to the Internet number registry system (as noted in RFCs 7020
and 7249) and this includes responsibility for arranging IANA operator services 
for the delegated portions of the identifier spaces.

/John

Disclaimer: my views alone - a position on this matter has not been set
            by the ARIN community or Board to the best of my knowledge.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Oct 2014 15:42:37 +0200

Hi Andrei,

> parties, but do say that the IETF defined the overall structure.

The text from your earlier email I agree with, and it's already in my
copy of the updated -02, unless someone has a concern.
> CRISP team), and not discover a clash at the ICG level.

I think that's an excellent idea.

Eliot

---

From: Seth Johnson <[email-masked]>
Date: Fri, 17 Oct 2014 11:02:47 -0400

Hi Eliot: One general thrust of this is that the current arrangements
provide all of the accountability functions necessary for all of the
policy sources.  The system of agreements, policies, and oversight
mechanisms between the IETF, ICANN, and IAB provides a dynamic that
serves this purpose.

Policy sources other than the RFCs and the system developed between
the IETF and the operator could affect that system.

The way it addresses roles in the process is also not well specified.
You want to articulate the setup in a way that allows those roles, and
expectations and requirements, to be represented fully enough to
assure the integrity of the process as it undergoes change.

I will offer edits over the weekend on this.  I like the way your
approach and Miles's come together.  But it kind of responds to the
RFP in an idiosyncratic way -- and that's good in a manner of
thinking, as it reflects the uniqueness of the IETF approach to
things.

(Incidentally, I thought I ought to note that I think, though it's not
articulated here, that the IAD/IAOC system is elegant and brilliant.
Not saying it should be reflected here, but I\it makes it much easier
to articulate a response that's consistent with the way the IETF and
ISOC do things.)

Seth

   First and foremost, IANA protocol parameter registry updates will
   continue to function day-to-day

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Oct 2014 17:43:34 +1300

I generally support the changes in this version.

I suggest that at the point where the IAOC is defined, it would be
helpful to also mention the IETF Trust. Something like:

The members of the IAOC are also the trustees of the IETF Trust, whose
main purpose is to hold certain intellectual property for the benefit of
the IETF as a whole.

(I realise that there is no further mention of the Trust in the
document, but it seems very likely to come up in subsequent
discussions.)

Regards
   Brian Carpenter

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 18 Oct 2014 06:44:50 +0200

I support that suggestion.

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Brian E
> Carpenter
> Sent: samedi, 18. octobre 2014 06:44
> To: [email-masked]

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 19 Oct 2014 12:26:53 -0400

To elaborate just a bit..

>> main purpose is to hold certain intellectual property for the benefit of

Perhaps the place to mention this is in Section 0 (Proposal Type) - by 
elaborating on the statement that this proposal "represents the view of 
the IAB and the IETF" - by adding IAOC and IETF to the list, maybe 
others as well (e.g., ISOC).

What I suggest is that the very first paragraph provide background as to 
the IETF, its role, its function (specifically re. protocol parameters), 
and the various component entities that together comprise the IETF as 
the term is generally used.

Something like this, perhaps (note that I've quoted quite a bit from the 
IETF web site - the lawyers probably need to clarify some points, as 
indicated below):

-----
The IETF (Internet Engineering Task Force) is the voluntary 
international standards body responsible for Internet Technical 
Standards, specifically including Internet protocol parameters. 
Architectural Oversight is provided by the Internet Architecture Board 
(IAB).  Both the IAB and IESG are chartered by the Internet Society.  
The authority of the IETF, in these matters, is recognized implicitly 
and explicitly by both US and international law and treaty that differs 
matters of technical standards to duly constituted voluntary standards 
organizations <perhaps the lawyers can provide a good citation here>.  
For legal and contractual purposes, the IETF acts through the <IETF 
Secretariat, the IAOC, and the IETF Trust --- need somebody to define 
these, and their roles, explicitly>.  For purposes of this document, we 
use the term IETF to refer to the combination of these entities.

Coordination of protocol parameters is performed, as directed by IETF, 
is performed by The Internet Assigned Numbers Authority (IANA) 
<http://www.ietf.org/glossary.html#IANA>, which is chartered by by the 
Internet Society (ISOC) to act as the clearinghouse to assign and 
coordinate the use of numerous Internet protocol parameters.  The IANA 
function is currently performed by ICANN, under the provisions of the 
IANA Functions Contract between NTIA (US Government) and ICANN, and an 
MoU executed between the IETF and ICANN.
-----

>> document, but it seems very likely to come up in subsequent

Miles Fidelman

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

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 19 Oct 2014 13:26:03 -0400

> 	Filename        : draft-ietf-ianaplan-icg-response-01.txt

A few comments on the draft:

RE. SECTION 0. (PROPOSAL TYPE)  (As sent in a previous email, re. 
Richard Hill's comment about defining the IETF Trust):

I suggest that two background paragraphs be inserted at the very 
beginning of Section 0. (Proposal Type) to set context and scope, define 
players, and so forth.  This is a first cut, based largely on language 
pulled from the IETF web site.  I've noted a couple of areas where 
clarification by lawyers would be appropriate:

-----
and explicitly by both US and international law and treaty that defer 

Coordination of protocol parameters is performed, as directed by IETF, 
is performed by The Internet Assigned Numbers Authority (IANA), which is 
chartered by by the Internet Society (ISOC) to act as the clearinghouse 
to assign and coordinate the use of numerous Internet protocol 
parameters.  The IANA function is currently performed by ICANN, under 
the provisions of the IANA Functions Contract between NTIA (US 
Government) and ICANN (par. C.2.9.1), and an MoU executed between the 
IETF and ICANN.
-----

RE. SECTION II. (EXISTING, PRE-TRANSITION ARRANGEMENT) SUBSECTION A. 
(POLICY SOURCES)

I'd suggest including a variant of the above language as a lead-in:

Coordination of protocol parameters is performed, in support of a the 
IETF, is performed by The Internet Assigned Numbers Authority (IANA), 
which is chartered by by the Internet Society (ISOC) to act as the 
clearinghouse to assign and coordinate the use of numerous Internet 
protocol parameters.  The IANA function is currently performed by ICANN, 
under contract to the US NTIA, which sets overarching policy for the 
function.  Detailed policy for the protocol parameters function is set 
by the IETF in accord with an MoU executed between the IETF and ICANN.

RE. SECTION II. (EXISTING, PRE-TRANSITION ARRANGEMENT) SUBSECTION B. 
(OVERSIGHT AND ACCOUNTABILITY)
RE. PARAGRAPHS ON >> Policy Sources:

I'd suggest another variant as a lead-in:

Currently, overarching oversight and accountability for all IANA 
functions is provided via terms of the the NTIA-ICANN IANA Functions 
Contract.  In practice, oversight and accountability, as regards the 
protocol parameters functions, is governed by the MoU between IETF and 
ICANN.

RE. PARAGRAPHS ON >> "entity or entities that provide oversight:"

Notable for it's omission:  IPROC (IETF Protocol Registries Oversight 
Committee) - as described in detail on the IETF web site 
(http://www.ietf.org/iana/iproc.html) - or is the web site out of date?  
If that's current - it really should be included in our response.

RE. PARAGRAPHS ON >> mechanisms:

Suggested lead-in:

Day-to-day mechanisms for oversight, accountability, and recourse are 
discussed below.  The ultimate, overarching recourse mechanisms are 
cancellation or non-renewal of either the NTIA IANA Functions Contract 
(by NTIA) and/or of the IETF-ICANN MoU by IETF.

RE. SECTION III (PROPOSED POST-TRANSITION OVERSIGHT AND ACCOUNTABILITY 
ARRANGEMENT)

There seems to be a mismatch between starting out with No changes are 
required, ..."  and then going on with several groups of paragraphs, 
each starting with to "To address issues raised by the IETF community" 
and going on to suggest that the IAOC negotiate supplemental agreements 
regarding:
- intellectual property rights
- additional dispute resolution
- transition (with reference to NTIA contract clauses C.7.3 and I.61, 
and "transfer of any associated marks and identifiers to a subsequent 
operator")

Rather than starting with "No changes are required," it would probably 
be more accurate and appropriate to state "No major changes are 
required, however, the IETF community has raised several concerns that 
should be addressed by supplemental agreements to the IETF-ICANN MoU, 
prior to a transition to post-NTIA regime."

Personally, I would also like to see something that makes  it crystal 
clear that, post NTIA, if either IETF or ICANN exercise their 
prerogative to non-renew or cancel the MoU, all authority, 
responsibility, intellectual property, marks and identifiers, etc. 
revert to IETF.  (Which, I think, would be the case if NTIA were to 
cancel or non-renew the current contract - probably something for the 
lawyers to weigh in on.)  Maybe even lead with an explicit statement 
that, "In a post-transition environment, all authority for the protocol 
parameters function will become vested in the IETF, governed by the MoU 
and supplemental agreements in place between IETF and the IANA Functions 
Operator (currently ICANN).  In the event of non-renewal or cancellation 
of these agreements, by either party, all suthority, responsibility, 
intellectual property, marks and identifiers, etc., as regards Internet 
protocol parameters revert to the IETF."

RE. SECTION IV (TRANSITION IMPLICATIONS)

Again, I don't think that "No structural changes are required." is an 
accurate statement.

i. We are recommending supplemental agreements in several areas.
ii. Those structural agreements at least allow for (anticipate?) 
structural changes - such as transition IANA functions to a different 
contractor - which, if only one set of functions were transferred, would 
definitely involve structural changes.

Perhaps more accurate would be "No immediate structural changes are 
required.  However we recommend several changes to contractual 
agreements be implemented prior to a transition (see Section III)." And 
perhaps go on to mention that, under certain circumstances, structural 
changes might occur down the road.

Respectfully,

Miles Fidelman
Speaking for myself, as a (way-too-long-standing) member of the Internet 
Community

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 19 Oct 2014 23:52:52 +0100

> MoU executed between the IETF and ICANN.

YUK.

Should any such background be desirable, it would IMO be crazy
for it to be written by someone who has not been involved in
the technical work of the IETF. (Which I conclude from the text
above is the case here, be interesting if I'm wrong about that:-)
And definitely not by lawyers who haven't been technically
involved in the real work of the IETF.

In case that wasn't definitive: YUK, YUK, YUK:-)

Sorry if my tone there seems dismissive but the text above is
truly multi-dimensionally horrible.

S.

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 19 Oct 2014 19:29:40 -0400

> truly multi-dimensionally horrible.
First off, I've been involved in technical work at the edges of IETF - 
back to my days at BBN doing things like management system architectures 
for very large networks, and work on security standards.  I've also been 
quite involved in policy issues, particularly in the arena of municipal 
networks.

Secondly, just for the record - it is absolutely crazy for engineers to 
think that a governance/legal/contractual document should be written 
without the involvement of policy, legal, and contractual folks.  
Organizational design and contracting are their own disciplines. (One 
man's opinion of course).

Miles Fidelman

---

From: S Moonesamy <[email-masked]>
Date: Sun, 19 Oct 2014 16:49:40 -0700

Hi Andrei,
>parties, but do say that the IETF defined the overall structure.

This is from a recent RFC:

   "Per the delineation of responsibility for Internet address policy
    issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions
    regarding the evolution of the Internet Numbers Registry System
    structure, policy, and processes are to take place within the ICANN
    framework and will respect ICANN's core values".

The last time the IETF said something about IP address assignments 
some RIRs ignored the recommendations.  I do not think that it is in 
the interest of the IETF to be entangled in some number issues.

Regards,
S. Moonesamy

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Oct 2014 06:47:49 +0200

Hi Miles,

Thank you for your comments.

Below I respond to your detailed comments in similar detail.  In
summary, I propose to suggest one of your proposals regarding Section 3,
and I will raise one issue with the IAB.  As I write below, I am
attempting to keep the RFP response in the form that was requested, and
as concise as is reasonably possible.

On 10/19/14, 7:26 PM, Miles Fidelman wrote:
>>          Title           : Draft Response to the Internet
>> Coordination Group Request for Proposals on IANA
>>          Authors         : Eliot Lear
>>                            Russ Housley
> beginning of Section 0. (Proposal Type) to set context and scope,
> define players, and so forth.  This is a first cut, based largely on
> language pulled from the IETF web site.  I've noted a couple of areas
> where clarification by lawyers would be appropriate:
>
> -----

I actually started with some of that text in Section 0.  The reason it
came out is that the first two sentences are found elsewhere.  The
remainder of that paragraph is in somewhat in error.  Please see Section
2 of RFC 2850, which states:

>    The IAB is chartered both as a committee of the IETF and as an
>    advisory body of the Internet Society.

The last sentence is not responsive to the RFP.

> these, and their roles, explicitly>.  For purposes of this document,
> we use the term IETF to refer to the combination of these entities.

Suggesting so, actually adds confusion.  The IETF expresses its views
through the rough consensus process, as judged by the IESG.  There are
multiple RFCs that make this clear and there is text in the appropriate
section of the response as well.  One point to keep clear: the ICG
requested that responses be organized in a particular way.

> is performed by The Internet Assigned Numbers Authority (IANA), which
> is chartered by by the Internet Society (ISOC) to act as the
> protocol parameters.  

Again, this is inaccurate.  The IAB is responsible for the selection of
the IANA functions operator for protocol parameters.

> The IANA function is currently performed by ICANN, under the
> provisions of the IANA Functions Contract between NTIA (US Government)
> and ICANN (par. C.2.9.1), and an MoU executed between the IETF and ICANN.

Similar text is already in the document.
> protocol parameters.  The IANA function is currently performed by
> ICANN, under contract to the US NTIA, which sets overarching policy
> for the function.  Detailed policy for the protocol parameters
> function is set by the IETF in accord with an MoU executed between the
> IETF and ICANN.

Same issues as above.

> protocol parameters functions, is governed by the MoU between IETF and

I would prefer not to modify the text as it stands.  Our current
position is that we seek to clarify our existing authority.

> (http://www.ietf.org/iana/iproc.html) - or is the web site out of
> date?  If that's current - it really should be included in our response.

This is an intended omission ;-)  IPROC is not *formally* chartered by
anyone, and that web site is inaccurate (even though it's on the IETF
web page).  The group in question was and is intended to be more of a
Monday lunch club.  However, since you raised it here, I will take as an
action to bring to the board's attention that something is done to make
IPROC more clear on our own web sites.

> (by NTIA) and/or of the IETF-ICANN MoU by IETF.

The issue with your lead-ins is that they vary from the form that was
requested by the ICG.  I would prefer to be succinct in our response,
and to avoid repetition (it cannot be entirely avoided).

> and going on to suggest that the IAOC negotiate supplemental
> agreements regarding:

I agree with the above text.  Unless anyone has any objections I will
insert it into -02.

> that, "In a post-transition environment, all authority for the
> protocol parameters function will become vested in the IETF, governed
> by the MoU and supplemental agreements in place between IETF and the
> IANA Functions Operator (currently ICANN).  In the event of
> non-renewal or cancellation of these agreements, by either party, all
> suthority, responsibility, intellectual property, marks and
> identifiers, etc., as regards Internet protocol parameters revert to
> the IETF."

The text that was placed into -02 was compromise text.  That compromise
text serves a clear purpose, which is to say that the next operator
(assuming there ever is a next operator) needs to have sufficient
authority to take on the task they are charged with, and further that
the IETF community needs those marks and trademarks not just because we
do, but because they are associated with the IANA functions.  The above
text is overly broad.  A separate agreement is currently in the works to
clarify the disposition of the contents of the IANA database.

> contractor - which, if only one set of functions were transferred,
> would definitely involve structural changes.
>
> agreements be implemented prior to a transition (see Section III)."
> And perhaps go on to mention that, under certain circumstances,
> structural changes might occur down the road.

I believe I've addressed the point you raised by including an earlier
suggestion of yours.  We are not seeking structural changes.  We are
seeking a supplement that clarifies our authority in a few specific areas.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Oct 2014 11:41:55 +0100

Hi Miles,

> quite involved in policy issues, particularly in the arena of municipal

Sure. The bluntness in my mail is not directed at you though,
but at your text. There are a bunch of historic sensitivities
here that it'd just be a bad plan to trample upon. And since
quite a few of 'em make no sense whatsoever, though others do,
its almost certain that someone coming to this without
sufficient context will do just that;-) Hence, its reasonable
to only consider authors with sufficient context for this.

For example, saying that the IETF is "responsible for Internet
Technical Standards" without any qualification is a huge, major,
gigantic, blooper. (To be clear: I don't think your text is a
good enough starting point as it has too many problems such as
this, someone who knows this stuff and cares would need to
start afresh, so I don't propose that we should go though the
above text in detail.)

> without the involvement of policy, legal, and contractual folks. 

Yes, I agree. Note that I said it'd be crazy for some kinds of
folks to hold the pen, I said nothing about involvement in the
process. And I think the general principle applies that we should
expect that those crafting text are subject matter experts, which
is a goal in the IETF. And on this topic, I wouldn't count myself
amongst the set of folks who ought write such text - I've mostly
not cared enough about this topic to know enough.

> man's opinion of course).

Yes, I recall many fine re-organisations whilst I worked in industry;-)

Cheers,
S.

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 20 Oct 2014 13:17:32 +0200

Please see below.

Thanks and best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Stephen
> Farrell
> Sent: lundi, 20. octobre 2014 12:42
> To: Miles Fidelman; [email-masked]

SNIP

> gigantic, blooper.

RFC 2031 states "The Internet Engineering Task Force (IETF) is the body that
is    responsible for the development and maintenance of the Internet
Standards."

Of course we all understand (or at least I hope that we all understand) that
such statements must be taken in context, and don't imply that the IETF does
everything all by itself.

SNIP

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Oct 2014 12:23:58 +0100

> is    responsible for the development and maintenance of the Internet

I doubt we'd use exactly those words from 1996 today TBH.

> everything all by itself.

Right, and IMO folks crafting text need to know the context,
whilst writing.

S.

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 20 Oct 2014 09:01:50 -0400

Eliot,

Thanks for the response.

Several general comments on your comments - re. the theory behind the 
comments:
- I thought I WAS responding to the way the RFP was organized (fyi - 
proposal writing is what I seem to spend 90% of my day job doing). But 
that, of course is a matter of opinion.
- The main idea was to add enough context to each section to provide 
some clarity and context.  IMHO, too many references to other documents 
make for lack of clarity. Sometimes adding just a few words, and some 
repetition, are useful and necessary.
- In governance/contractual documents, staking out turf is kind of 
important - since things end up getting negotiated away down the line.

Bottom line is that I think you reflected the substantive comments, and 
cut the ones that are more editorial/contextual - so I'm happy.

A few comments, below..

Eliot Lear wrote:
> summary, I propose to suggest one of your proposals regarding Section 
> 3, and I will raise one issue with the IAB.  As I write below, I am 
> attempting to keep the RFP response in the form that was requested, 
> and as concise as is reasonably possible.
>
>> Architectural Oversight is provided by the Internet Architecture 
>> Board (IAB).  Both the IAB and IESG are chartered by the Internet 
>> Society.  The authority of the IETF, in these matters, is recognized 
>> implicitly and explicitly by both US and international law and treaty 
>> that defer matters of technical standards to duly constituted 
>> voluntary standards organizations <perhaps the lawyers can provide a 
>> good citation here>. 
>
> remainder of that paragraph is in somewhat in error.  Please see 
> Section 2 of RFC 2850, which states:
>

Main reason to lead with that is to start out saying exactly who the 
proposal is from.  Re. last sentence, that came from 
http://www.ietf.org/about/ (which also mentions IESG).

Basic point is that "you can't tell the players without a scorecard" - 
and it's way too indirect pointing to a gaggle of RFPs.  Again, a matter 
of editorial opinion, though.

> multiple RFCs that make this clear and there is text in the 
> appropriate section of the response as well.  One point to keep clear: 
> the ICG requested that responses be organized in a particular way.

But again, this is a document that focuses on governance and contracts.  
>From a legal point of view, the IETF doesn't exist except through 
various entities that can sign contracts.

Re. the organization.  Again, a matter of opinion, but the section on  
"what type of proposal is this" kind of is the opening to state exactly 
what community is being represented, and elaborate enough to provide 
contractual clarity.  Especially since the rest of the document is 
littered with references to various entities that, from an outside view, 
are all part of IETF and/or the "protocol parameters" community.  As an 
outside reader (ultimately, NTIA), I'd find this all very unclear.

>
>>
>> Coordination of protocol parameters is performed, as directed by 
> Again, this is inaccurate.  The IAB is responsible for the selection 
> of the IANA functions operator for protocol parameters.

And this is where clarity and background starts to be very important.  
IAB, IETF, "protocol parameters community," ... who are we talking 
about?  Who's actually responding to the proposal? What are the 
organizational relationships.  IMHO, that needs to be exceptionally 
clear in our response - especially, since the response is supposed to be 
from the protocol parameters community as a whole (as I understand the 
process).

And... actually, right now, NTIA is responsible for selecting the IANA 
functions operator for all functions - we're proposing that IAB be 
responsible, though that's not all that clear.  And since the IAB isn't 
a legal entity that can issue a contract, that needs to be clarified as 
well - that the IAB represents the protocol parameters community, and 
who and how the IANA functions contract is put in place/managed/edited.  
(A lot of that detail is in the proposal, but I think it comes back to 
"you can't tell the players without a scorecard" - who's doing what, to 
whom is, IMHO, way too nebulous, and is cross-referenced to too many 
other documents.)

>> provisions of the IANA Functions Contract between NTIA (US 
>> function is set by the IETF in accord with an MoU executed between 
>> the IETF and ICANN.
>
> Same issues as above.
>
>>
>>
>> protocol parameters functions, is governed by the MoU between IETF 
>> and ICANN.
>

IMHO, as a reader, the document, as it stands, does NOT clarify our 
existing authority (or who "our" refers to, to a level of specificity 
necessary for contractual matters).

Also, since the focus is what happens when the NTIA contract goes away - 
we ALSO need to identify what authority that now resides with NTIA, that 
we depend on, and/or overlaps our authority, and, in particular, that we 
propose to assume.  If nothing else, IMHO, the primary point of the 
proposal is to make it crystal clear that "we" end up with the authority 
to contract for the IANA protocol parameter functions, and to manage 
that contract - and to define who "we" are when it comes to contractual 
documents.

> Monday lunch club.  However, since you raised it here, I will take as 
> an action to bring to the board's attention that something is done to 
> make IPROC more clear on our own web sites.

Two alternate approaches suggest themselves:
1. Eliminate all references entirely.  As long as something named the 
"IETF Protocol Registries Oversight Committee)" exists, in some form, it 
sure SOUNDS like the folks providing oversight.
2. Talk about it as part of the discussion of how oversight is provided 
now - as a way to strengthen the point that "we already provide oversight."

>> cancellation or non-renewal of either the NTIA IANA Functions 
>> Contract (by NTIA) and/or of the IETF-ICANN MoU by IETF.
>
>> RE. SECTION III (PROPOSED POST-TRANSITION OVERSIGHT AND 
>> ACCOUNTABILITY ARRANGEMENT)
>>
>> each starting with to "To address issues raised by the IETF 
>> community" and going on to suggest that the IAOC negotiate 
>> supplemental agreements regarding:
>> Rather than starting with "No changes are required," it would 
>> probably be more accurate and appropriate to state "No major changes 
>> are required, however, the IETF community has raised several concerns 
>> that should be addressed by supplemental agreements to the IETF-ICANN 
>> MoU, prior to a transition to post-NTIA regime."
>

And, of course, this is the important item. :-)

> The text that was placed into -02 was compromise text.  That 
> compromise text serves a clear purpose, which is to say that the next 
> operator (assuming there ever is a next operator) needs to have 
> sufficient authority to take on the task they are charged with, and 
> further that the IETF community needs those marks and trademarks not 
> just because we do, but because they are associated with the IANA 
> functions.  The above text is overly broad.  A separate agreement is 
> currently in the works to clarify the disposition of the contents of 
> the IANA database.

Arguably, in a document intended to establish and clarify authority, 
better to be overly broad as one goes into negotiations.  IMHO, of course.

> seeking a supplement that clarifies our authority in a few specific areas.

Again IMHO - new contracts ARE structural changes, particularly if:
- we believe that they should be in place before the NTIA contract goes 
away
- the new situation enables changes in organizational and operational 
relationships (c.f., previous discussion re. what happens if IANA 
functions were to be split, down the line, among multiple contractors)

Maybe there's no need to mention "structural changes" at all.  The main 
transition implications are that:
- "we" assume specific authority to contract for and manage the protocol 
parameter related IANA functions (specifically we assume any 
responsibilities, in this area, that NTIA currently has)
- there are several supplementary agreements that have to be in place 
before the transition occurs

Respectfully,

Miles Fidelman

---

From: S Moonesamy <[email-masked]>
Date: Mon, 20 Oct 2014 05:20:27 -0700

Hi John,

I was referring to http://www.rfc-editor.org/rfc/rfc6177.txt

Regards,
S. Moonesamy

---

From: John Curran <[email-masked]>
Date: Mon, 20 Oct 2014 10:58:42 -0400

On Oct 19, 2014, at 7:49 PM, S Moonesamy <[email-masked]> wrote:
>> ...
>> The last time the IETF said something about IP address assignments some RIRs ignored the recommendations. 
> 
> Please provide a reference for the above statement.

> I was referring to http://www.rfc-editor.org/rfc/rfc6177.txt

"Some RIRs ignored the recommendations" is an incorrect statement.

"Ignore" would imply a refusal to notice or acknowledge, whereas 
RFC 6177 most certainly notices the prior IETF advice (RFC 3177) 
in this area, and represents engagement within the IETF community 
to achieve a more operationally relevant outcome.

In general, neither the IETF nor the RIRs "ignore" one another; 
if you actually meant that sometimes the IETF makes recommendations 
about general-purpose IP address assignments and those in the RIR
community respond that such policy is better set by them, then I 
fully understand and agree.

With respect to the IANAplan document, I believe that mentioning 
the special purpose (e.g. multicast) registries is not as important 
as having RFC 7020 and RFC 7249 directly referenced, i.e. what is 
needed is a statement in the document to the effect that:

"Policy authority for general purpose (i.e the non-technical/specialized) 
 portions of the IPv4, IPv6, and ASN spaces have been delegated to the 
 Internet number registry system, as noted in RFCs 7020 and 7249, and 
 this includes responsibility for arranging IANA operator services for 
 the delegated portions of these identifier spaces."

/John

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 20 Oct 2014 15:15:19 +0000

With the exception, of course, of legacy IPv4 holders. 

> been delegated to the Internet number registry system (as noted in RFCs
> 7020 and 7249) and this includes responsibility for arranging IANA operator
> services for the delegated portions of the identifier spaces.
>

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 20 Oct 2014 15:27:13 +0000

Rather than starting with "No changes are required," it would probably be more accurate and appropriate to state "No major changes are required, however, the IETF community has raised several concerns that should be addressed by supplemental agreements to the IETF-ICANN MoU, prior to a transition to post-NTIA regime."

I agree with the above text.  Unless anyone has any objections I will insert it into -02.

MM: I support the change.

Personally, I would also like to see something that makes  it crystal clear that, post NTIA, if either IETF or ICANN exercise their prerogative to non-renew or cancel the MoU, all authority, responsibility, intellectual property, marks and identifiers, etc. revert to IETF.  (Which, I think, would be the case if NTIA were to cancel or non-renew the current contract - probably something for the lawyers to weigh in on.)  Maybe even lead with an explicit statement that, "In a post-transition environment, all authority for the protocol parameters function will become vested in the IETF, governed by the MoU and supplemental agreements in place between IETF and the IANA Functions Operator (currently ICANN).  In the event of non-renewal or cancellation of these agreements, by either party, all suthority, responsibility, intellectual property, marks and identifiers, etc., as regards Internet protocol parameters revert to the IETF."

The text that was placed into -02 was compromise text.  That compromise text serves a clear purpose, which is to say that the next operator (assuming there ever is a next operator) needs to have sufficient authority to take on the task they are charged with, and further that the IETF community needs those marks and trademarks not just because we do, but because they are associated with the IANA functions.  The above text is overly broad.  A separate agreement is currently in the works to clarify the disposition of the contents of the IANA database.

MM: As noted before, the weaker compromise text is acceptable to me if consensus on that is required to move forward. However, I still have trouble understanding what is holding this group back from a slightly stronger statement.

e.g., if you believe Miles’ version is “overly broad” would this be an acceptable version of it:
“In the event of non-renewal or cancellation of these agreements by either party, all intellectual property, marks and identifiers as regards Internet protocol parameters revert to the IETF."

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/>

---

From: John Curran <[email-masked]>
Date: Mon, 20 Oct 2014 11:32:54 -0400

On Oct 20, 2014, at 10:58 AM, John Curran <[email-masked]> wrote:
> ... what is 

As it turns out, there is some active discussion in the ARIN community 
on this same topic (i.e. IANA services for the numbers area) so I should 
be more complete in the range of possible options in this area regarding 
what could go in the IANAplan document.

One way or another, there needs to be IANA operator services provided for
the entire IPv4, IPv6, and ASN identifier spaces.  This obviously can be
arranged entirely by the IETF, arranged for the IETF for all except some
portion of these spaces (such as the general-purpose ranges that have been
delegated to the RIR community and who would arrange IANA services for those
portions), or IANA services could arranged for these entire spaces by the 
RIR community (noting that some data regarding the technical/specialized 
reservation entries would need to be picked up from the IETF)

There is also the question of whether the IANA operator for these segments
of the IP and ASN spaces (general purpose vs reserved) must be the same
operator, should be the same operator, or that it doesn't matter at all.

Both of the above topics are worthy of discussion both here in the in 
RIR community.

FYI,
/John

Disclaimer: my views alone.

---

From: John Curran <[email-masked]>
Date: Mon, 20 Oct 2014 11:50:55 -0400

> With the exception, of course, of legacy IPv4 holders. 

Interesting assertion - you probably want to elaborate on it for clarity;
e.g. do feel that there is no policy applicable to these entries at all,
or that they are under policy authority of the IETF, but not the RIRs, etc.
Also, it would be good to specify where you feel IANA services for these
should be provided, as well as related registry services (such as Whois
and reverse DNS)  Depending on the specific model you propose, it could 
have a material impact on IETF's IANA contracting (presuming community
support for your viewpoint.)

FYI,
/John

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 20 Oct 2014 16:03:55 +0000

> Interesting assertion - you probably want to elaborate on it for clarity; e.g. do
> feel that there is no policy applicable to these entries at all, or that they are
> under policy authority of the IETF, but not the RIRs, etc.

The former. Legacy holders predate the contractual policy regime of the RIRs and thus it is legally impossible to assert contractual authority over them. It is very similar to the ccTLD situation; ICANN wanted to subject them to its contractual regime but as de facto holders of assigned resources it could not enforce its claims without taking away, or threatening to take away, the assignments. This of course was not really a viable option, given all the de facto established usage rights and the political and legal disruptions such a move would cause. So ICANN had to negotiate an arrangement with ccTLDs rather than imposing one on them. 

> should be provided, as well as related registry services (such as Whois and
> reverse DNS)  

Most IANA services are not terribly relevant for legacy, given that IPv4 is depleted at the IANA level. Regarding Whois, RIPE has already answered this question one way, elevating registry accuracy above all other values and thus formally recognizing legacy holders' de facto control of resources and allowing them to transfer them at will while accurately reflecting any changes in their whois. ARIN has answered it another way, refusing to recognize changes in legacy holdings that it does not authorize, thereby creating a less accurate Whois. 

I think reverse DNS would not be a problem if RIRs recognize legacy holders. 

> Depending on the specific model you propose, it could have a
> material impact on IETF's IANA contracting (presuming community support
> for your viewpoint.)

Would be interested to hear more about this. Though perhaps more appropriate on the CRISP list?

---

From: Andrei Robachevsky <[email-masked]>
Date: Mon, 20 Oct 2014 18:18:24 +0200

>> the delegated portions of these identifier spaces."

John, I am not sure what points do the RFCs you mentioned support? Both
of them are incomplete wrt specifying what falls under the IETF
authority (e.g. multicast). A question of "delegation" is not really
discussed there, too. I thought it might be a better approach to carve
out what is in the IETF realm and for which the IETF takes responsibility.

What RFC7020 says, however, and which may have implications for this
discussion, is:

"The foregoing does not alter the IETF's continued responsibility for
   the non-policy aspects of Internet addressing such as the
   architectural definition of IP address and AS number spaces and
   specification of associated technical goals and constraints in their
   application, assignment of specialized address blocks, and
   experimental technical assignments as documented in RFC 2860.  In
   addition, in the cases where the IETF sets technical recommendations
   for protocols, practices, or services that are directly related to IP
   address space or AS numbers, such recommendations must be taken into
   consideration in Internet Numbers Registry System policy discussions
   regardless of venue."

But while historically and formally correct, I'd like to see a more
clear delineation between the protocol parameters and numbers in this
document.

[...]
> operator, should be the same operator, or that it doesn't matter at all.

IMO, if delineation of areas of responsibility in respect to the number
registries is clear in the final combined proposal, these questions do
not have to be answered here (and there). So whatever statement we
include in our response it is important that it is matched by a
corresponding statement in the CRISP Team proposal.

Andrei

---

From: John Curran <[email-masked]>
Date: Mon, 20 Oct 2014 16:25:14 +0000

> The former. Legacy holders predate the contractual policy regime of the RIRs and thus it is legally impossible to assert contractual authority over them. It is very similar to the ccTLD situation;…

As a note, an interesting assertion.

> Most IANA services are not terribly relevant for legacy, given that IPv4 is depleted at the IANA level. Regarding Whois, RIPE has already answered this question one way, elevating registry accuracy…

Your characterization regarding "accuracy" notwithstanding, it is correct
that ARIN does consider all registrations in the region are subject to the
community-developed policy and operates the registry accordingly.  We fully 
recognize the rights of legacy holders to update their Whois entries, receive 
reverse DNS services, etc.; we provide these registration services to legacy 
resource holders without charge or any requirement for legal agreement so 
that those IPv4 legacy address holders who wish to use their resources in 
peace my do so, and have no issues maintaining accuracy of their registration 
data.  It is true that those that wish to transfer their resources do need 
to comply with the community-developed policy; this prevents things such as
IPv4 blocks being deaggregated into individual /32's (and parties being rather
disappointed when they try to route the result)

> I think reverse DNS would not be a problem if RIRs recognize legacy holders. 

See above.

> Would be interested to hear more about this. Though perhaps more appropriate on the CRISP list?

Unless you feel it is a topic for the IETF to take a position in, it would 
likely be more appropriate for one of the Internet numbering community mailing 
lists regarding IANA Stewardship Transition planning.

FYI,
/John

John Curran
President and CEO
ARIN

---

From: John Curran <[email-masked]>
Date: Mon, 20 Oct 2014 13:01:57 -0400

On Oct 20, 2014, at 12:18 PM, Andrei Robachevsky <[email-masked]> wrote:
> authority (e.g. multicast).

Andrei -

I thought that RFC 7249 was fairly clear on this aspect; do you think
it needs to changed or updated? - 

From [RFC 7249]
"
   Three IANA registries are associated with the Internet Numbers
   Registry System: "Autonomous System (AS) Numbers", "IANA IPv4 Address
   Space Registry", and "IPv6 Global Unicast Address Assignments".
   However, in each case, there are special-purpose values, and those
   special-purpose values are outside the Internet Numbers Registry
   System.
...
   The allocation and registration functions for all non-reserved AS
   numbers are handled by the Internet Numbers Registry System in
   accordance with policies developed by the Regional Internet
   Registries (RIRs) in accordance with their processes.
   Some special-purpose AS numbers have been reserved.  Section 3 of
   this document establishes an IANA registry for special-purpose AS
   Numbers that have already been reserved.  
...
   The allocation and registration functions for all non-reserved,
   globally unique unicast IPv4 addresses are handled by the Internet
   Numbers Registry System in accordance with policies developed by the
   RIRs in accordance with their processes.
   Reservations of special-purpose IPv4 addresses can be found in the
   IANA registry [IANA-IPv4-Reg].
...
   The vast bulk of the IPv6 address space (approximately 7/8ths of the
   whole address space) is reserved by the IETF [RFC4291], with the
   expectation that further assignment of globally unique unicast
   address space will be made from this reserved space in accordance
   with future needs.
   The allocation and registration functions for all non-reserved
   globally unique unicast IPv6 addresses are handled by the Internet
   Numbers Registry System in accordance with policies developed by the
   RIRs in accordance with their processes.
   Reservations of special-purpose IPv6 addresses can be found in the
   IANA registry [IANA-IPv6-Reg]. 
"

> A question of "delegation" is not really

See above regarding "carving out what is in the IETF realm".. there 
is text that references the relevant special purpose IANA registries.

Delegation within the IANA identifier system is covered at length in the IANA 
framework document - <https://tools.ietf.org/html/draft-iab-iana-framework-02>
This is still a draft document and probably needs to get more discussion
and review so that publication in the near future can be accomplished.

> corresponding statement in the CRISP Team proposal.

I'm uncertain if that is the case; more specifically, it is possible 
that the authority for given portion of any identifier space to be 
perfectly clear, and still not know if there is a requirement that, 
for various technical/operational reasons, that is desirable any given 
identifier space to be published by one party, i.e. that there is one 
IANA operator handling the entire IPv4 or IPv6 space, even if getting
entries from multiple authorities.

Even if the responsibility to contract/arrange for IANA services is 
clearly documented to held by the IETF, RIRs, and ICANN respectively, 
it would be good for the IETF to be very clear what it has for 
expectations (if any) as to whether those parties must or should 
contract to the same party for IANA operations.  If the answer is 
that this is not required, then we need to understand what is the 
coordination & oversight processes that make such possible, i.e. does 
the IETF accept such responsibility to make sure that IANA services
work fine or does it fall to the delegated registry authority to make 
sure their IANA contractor works with the IETF's IANA contractor to
accomplish such?

FYI,
/John

---

From: David Conrad <[email-masked]>
Date: Mon, 20 Oct 2014 10:19:47 -0700

John,

On Oct 20, 2014, at 9:25 AM, John Curran <[email-masked]> wrote:
> It is true that those that wish to transfer their resources do need 

Cart before horse.  I suspect network operators around the world choose not to deaggregate due to the assumption that some/many/most folk filter around the /24 mark, not because a few address policy wonks in the North American region came up with a policy.

Regards,
-drc
(speaking for myself only)

---

From: Andrei Robachevsky <[email-masked]>
Date: Mon, 20 Oct 2014 19:21:05 +0200

John,

[...]
>    IANA registry [IANA-IPv4-Reg].

For instance, [IANA-IPv4-Reg] points to RFC 5736, 6890 (IANA IPv4
Special-Purpose Address Registry) and doesn't include the IPv4 Multicast
Address Space Registry (3307, 5771).

[IANA-IPv6-Reg] is equally incomplete.

Thanks,

Andrei

---

From: John Curran <[email-masked]>
Date: Mon, 20 Oct 2014 13:29:48 -0400

> Cart before horse.  I suspect network operators around the world choose not to deaggregate due to the assumption that some/many/most folk filter around the /24 mark, not because a few address polic…

David - 
 
  I fully agree with you -  one would hope that network operators 
  choose to route that which operational sense, and that the RIR
  policies are not the only meaningful back-pressure on routing
  table growth.  Of course, given the number of folks that build
  their filters based on tables of RIR maximum block allocation 
  size, it is fairly hard to determine causality...

  Either way, the topic seems somewhat orthogonal to planning 
  for IANA stewardship transition (at least to the extent that 
  the present relationships being maintained in such a change.)

/John

---

From: Jefsey <[email-masked]>
Date: Mon, 20 Oct 2014 19:36:50 +0200

At 17:32 20/10/2014, John Curran wrote:
>This obviously can be arranged
>- entirely by the IETF,
>- arranged for the IETF for all except some portion of these spaces 
>(such as the general-purpose ranges that have been delegated to the 
>RIR community and who would arrange IANA services for those portions),
>-  or IANA services could [be?] arranged for these entire spaces by 
>the  RIR community (noting that some data regarding the 
>technical/specialized reservation entries would need to be picked up 
>from the IETF)

What about SixXS?
jfc

---

From: John Curran <[email-masked]>
Date: Mon, 20 Oct 2014 13:46:11 -0400

> [IANA-IPv6-Reg] is equally incomplete.

I believe that's because the delegation text only refers 
to the _unicast_ space in IPv4 and IPv6.  I not aware of
any delegations to RIR community of non-unicast portions
from either IPv4 or IPv6 protocol identifier spaces.

/John

---

From: Andrei Robachevsky <[email-masked]>
Date: Mon, 20 Oct 2014 19:53:45 +0200

> from either IPv4 or IPv6 protocol identifier spaces.

That is correct. I believe we are talking about the delineation in the
Internet Number Registries, which include anycast and multicast. And RFC
7249 doesn't specifically mention unicast in the IETF related text.

Best,

Andrei

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Oct 2014 20:26:05 +0200

Hi Milton,

On 10/20/14, 5:27 PM, Milton L Mueller wrote:

> “In the event of non-renewal or cancellation of these agreements by
> either party, all intellectual property, marks and identifiers as
> regards Internet protocol parameters revert to the IETF."
>
>  
>

There is the niggling issue of iana.org that this gets us to.  It really
is sufficient for me that this activity be transferred to the next
operator, and not to us.  That also leaves us with what I think our
stated preference is that the functions stay together, when that is
practicable.  On the other hand, so long as the other communities don't
have an objection I can live with the above text, but would like to hear
from others.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Oct 2014 20:40:35 +0200

> from either IPv4 or IPv6 protocol identifier spaces.

Coming back to the draft (you remember the draft?), are you proposing a
clarification that states this?  I had thought that Andrei's text was
sufficient...

Eliot

---

From: John Curran <[email-masked]>
Date: Mon, 20 Oct 2014 14:46:53 -0400

On Oct 20, 2014, at 1:53 PM, Andrei Robachevsky <[email-masked]> wrote:
> Internet Number Registries, which include anycast and multicast. 

Andrei - 
  
  Not "Internet Number Registries", as in all numbers used in IETF 
  IP protocols, but simply the Internet Number Registry System, i.e. 
  a specific piece of globally unique Internet Protocol (IP) address 
  space and autonomous system (AS) numbers which are administered
  by the Internet Regional Registries 

  Per Abstracts of RFC 7020 and RFC 7249 - 
  
  "This document provides information about the current Internet Numbers
   Registry System used in the distribution of globally unique Internet
   Protocol (IP) address space and autonomous system (AS) numbers.

   This document also provides information about the processes for
   further evolution of the Internet Numbers Registry System.
   ... 
   This companion document (RFC 7249) identifies the IANA registries 
   that are part of the Internet Numbers Registry System at this time. "

 There is no reason to reference anycast or multicast in these documents,  
 and with respect to IANA Stewardship Transition planning, RFC 7249 does
 clearly enumerate the resource that have been delegated; this includes
 the specified global IP unicast space save for any of the referenced 
 IANA-reserved registries.  

/John

---

From: S Moonesamy <[email-masked]>
Date: Mon, 20 Oct 2014 11:29:31 -0700

Hi John,
>fully understand and agree.

I'll put it this way:  I respect the wishes of the community which 
considers itself relevant when it comes to policy.  I don't think 
that the IETF has much of a say in such matters unless it does not 
mind being ignored.

>  the delegated portions of these identifier spaces."

 From RFC 2860:

   "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."

 From 7020:

    framework and will respect ICANN's core values."

There isn't any mention of IANA operator services with respect to the 
IETF in the above.

I do not think that it is a good idea for the IETF to state that all 
(unicast) IP addresses are under the jurisdiction of the United 
States or that they all fall under the Internet numbers registry 
system.  My preference is for statements about (unicast) numbers to 
come from the appropriate entity (or community).  Otherwise, it will 
look like those who represent the IETF are the governors of the internet.

Regards,
S. Moonesamy

---

From: John Curran <[email-masked]>
Date: Mon, 20 Oct 2014 14:54:29 -0400

> On Oct 20, 2014, at 2:29 PM, S Moonesamy <[email-masked]> wrote:
> ...
> I do not think that it is a good idea for the IETF to state that all (unicast) IP addresses are under the jurisdiction of the United States or that they all fall under the Internet numbers registry system.  My preference is for statements about (unicast) numbers to come from the appropriate entity (or community).  ...

Strange...  You realize that the IETF saying that the delegated unicast 
address space falls under the Internet numbers registry system (per RFC 
7020) is equivalent to stating that it's handled by the Regional Internet
Registries?

/John

---

From: John Curran <[email-masked]>
Date: Mon, 20 Oct 2014 15:11:26 -0400

> clarification that states this?  I had thought that Andrei's text was

The draft can note that the IETF is only responsible (with respect to 
IP address space) for a list of certain reserved IETF sub-registries 
(inc multicast), or it can simply state that IETF is responsible for 
all parameter space save for that delegated to the Internet Number 
Registry System as documented in RFC 7020 / RFC 7249.  

It's mostly a editorial/stylistic matter, so long as attention to 
the detail is provided either way. For example, RFC 7249 points 
directly to the actual IANA IPv4 special purpose address registry 
<http://www.iana.org/assignments/iana-ipv4-special-registry> and thus 
avoids duplication, but one can argue that including that detail in the 
IANAplan document may be justified in this case for avoidance of doubt.

/John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Oct 2014 08:22:49 +1300

>   size, it is fairly hard to determine causality...

Surely the underlying causality, which trumps everything else, is
the cost of router technology, which forces operators to filter at a
certain level of aggressivity. Of course this varies over time, but
it will always be the real determining factor. This physical reality
is reflected indirectly in operator practices, RIR guidelines,
and even IAB or IETF utterances, but very little in IANA activity.

>   the present relationships being maintained in such a change.)

+1

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Oct 2014 08:26:25 +1300

> have an objection I can live with the above text, but would like to hear

I think that text lacks a few words to make it clear that the IPR would
revert to the IETF (Trust) *for the benefit of the community as a whole*.

   Brian

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 20 Oct 2014 20:05:56 +0000

> the IPR would

That addition would be fine by me.
--MM

---

From: S Moonesamy <[email-masked]>
Date: Mon, 20 Oct 2014 12:51:14 -0700

Hi John,
>7020) is equivalent to stating that it's handled by the Regional Internet

The short answer is yes.

That RFC does not say anything about legacy IPv4 address space.  As 
such the IETF did not say anything about that type of address space.

Regards,
S. Moonesamy

---

From: John Curran <[email-masked]>
Date: Mon, 20 Oct 2014 17:23:19 -0400

On Oct 20, 2014, at 3:51 PM, S Moonesamy <[email-masked]> wrote:
> 
> That RFC does not say anything about legacy IPv4 address space.  As such the IETF did not say anything about that type of address space.

Agreed. The term "legacy address space" and "legacy address space holder"
are neither in the NTIA IANA Functions contract nor do they occur in the 
documentation of Internet number registry system; they are terms that do
arise in discussion within the RIR community.  However, the IPv4 unicast
address space itself (regardless of pedigree) falls within "allocated and 
unallocated IPv4 address space", i.e. within the present scope of the NTIA 
IANA Functions contract statement of work, and hence it is rather likely 
that any plan for transition of the stewardship of the IANA functions is
going to cover the entire IPv4 address space (even if lacking references 
to legacy/non-legacy/provider-assigned/provider-independent, etc.)  

If you feel that there are particularly IP address communities that need to 
be more active in the IANA stewardship discussion, e.g. provider-assigned IP 
users or legacy holders or dynamically-assigned IP address residential users, 
then please encourage them to get involved in the IETF & RIR community IANA 
stewardship transition planning discussions.

Thanks!
/John

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 21 Oct 2014 11:44:39 +0200

Please see below.

Thanks and best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of John
> Curran
> Sent: lundi, 20. octobre 2014 19:02
> To: Andrei Robachevsky
> Cc: [email-masked]
> Subject: Re: [Ianaplan] General purpose number registries & policy
> engagement

SNIP

>contract to the same party for IANA operations.  

I agree.

>If the answer is 

I agree.

---

From: JFC Morfin <[email-masked]>
Date: Tue, 21 Oct 2014 13:56:32 +0200

>clarification that states this?  I had thought that Andrei's text was

Elliot,

I wish I could help you now with the draft. Since it is out of my 
credibility window I wait for the last call to have a complete view 
of the "status-quo" strategy it will consistently propose and see if 
we might conciliate or if I should introduce another I_D. 
Accountability is not only a problem for ICANN, it also is for the 
RIRs and IETF. RFC 6852 has acknowledged that the IETF accountability 
to its global community was to be considered, and that the IETF could 
be/was in coopetition with other SDOs. E.g. W3C/WhatWG

I am concerned by the IETF disinterest in the technical adaptations 
to the accountability requirements. The first requirement being, IMHO 
to consider its own accountability to be trusted?

jfc

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 21 Oct 2014 08:47:08 -0400

Also agree.

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Tue, 21 Oct 2014 09:46:57 -0400

As an observation:

>> clarification that states this?  I had thought that Andrei's text was

IMO, there is more than an editorial/stylistic difference between these 

> Registry System as documented in RFC 7020 / RFC 7249.

And I agree that the draft could pick one of them.

Leslie.

-- 

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

---

From: John Curran <[email-masked]>
Date: Tue, 21 Oct 2014 10:02:34 -0400

On Oct 21, 2014, at 9:46 AM, Leslie Daigle (TCE) <[email-masked]> wrote:
> ...
> IMO, there is more than an editorial/stylistic difference between these two statements:

Good to know...  I did not see that much of a difference, but there 
easily could be some significant nuances to the meaning of each.

> And I agree that the draft could pick one of them.

If you feel there is a significant difference between the two approaches, 
can you outline your preferred approach, and/or what you see as the relative
merits of each?

Thanks!
/John

---

From: "Leslie Daigle (TCE)" <[email-masked]>
Date: Tue, 21 Oct 2014 10:29:43 -0400

I think, for someone who is not as well-versed in the current 
understandings and expectations between the RIRs and the IETF as you 
are, the difference in the two statements is who determines the fate of 
any address space not in identified specialized sub-registries.

The first statement says that all address space that is not listed as an 
IETF sub-registry is general address space for allocation via the 
Internet Number Registry System.

The second says that the IETF will identify what space is up for 
allocation via the Internet Number Registry System.   It leaves open the 
question of whether (portions of) that space might become 
special-purpose, handed to the Internet Number Registry System in the 
future, or what.

It is, of course, irrelevant for IPv4.

Leslie.

--

---

From: Jefsey <[email-masked]>
Date: Tue, 21 Oct 2014 17:17:50 +0200

At 16:29 21/10/2014, Leslie Daigle (TCE) wrote:
>are, the difference in the two statements is who determines the fate 
>of any address space not in identified specialized sub-registries.
>
>The first statement says that all address space that is not listed 
>as an IETF sub-registry is general address space for allocation via 
>the Internet Number Registry System.
>
>allocation via the Internet Number Registry System.   It leaves open 
>the question of whether (portions of) that space might become 
>special-purpose, handed to the Internet Number Registry System in 
>the future, or what.

The question is to know if IPv6 addresses are common goods (organized 
by the IETF and managed by ICANN), an ITEF Trust or an ICANN 
property. In order to push forn an IPvITU International Number 
Registry Sysem being created in order to adress specific sovereign 
requirements and the fact that the NTIA has only indicated its intent 
to transfer DNS responsibilities to ICANN, the second understanding 
seems advisable since it does not create any de facto monopoly and 
retrains the capacity for the IETF to allocate IPv6 addressing space 
portions along new demands.

jfc

---

From: David Conrad <[email-masked]>
Date: Tue, 21 Oct 2014 08:15:21 -0700

Hi,

On Oct 21, 2014, at 7:29 AM, Leslie Daigle (TCE) <[email-masked]> wrote:
> I think, for someone who is not as well-versed in the current understandings and expectations between the RIRs and the IETF as you are, the difference in the two statements is who determines the fate of any address space not in identified specialized sub-registries.
> 
> The first statement says that all address space that is not listed as an IETF sub-registry is general address space for allocation via the Internet Number Registry System.
> 
> The second says that the IETF will identify what space is up for allocation via the Internet Number Registry System.   It leaves open the question of whether (portions of) that space might become special-purpose, handed to the Internet Number Registry System in the future, or what.

FWIW, I agree with Leslie and believe the second statement is preferable.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Oct 2014 07:56:40 +1300

> FWIW, I agree with Leslie and believe the second statement is preferable.

Agreed. A standard creates a numbering space, so logically it is the creator
of the standard that should determine which parts of the numbering space
remain under the creator's control and which parts are delegated elsewhere.

   Brian

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 21 Oct 2014 16:24:53 -0400

> remain under the creator's control and which parts are delegated elsewhere.

+1. In fact this is one of the basic principles that keep the rest of the system coherent.

Suzanne

---

From: Jefsey <[email-masked]>
Date: Wed, 22 Oct 2014 18:14:06 +0200

At 22:24 21/10/2014, Suzanne Woolf wrote:
>In fact this is one of the basic principles that keep the rest of 
>the system coherent.

What actually keeps the system "coherent" (I would say "closed") is 
that the ISPs chose that their routers support TCP/IP + accept the 
RIR addressing plan. Obviously, this is for marketing and political 
reasons (these people are nationally incorporated corporations). In 
addition, any political decision to do otherwise or innovation that 
would permit them to do more (support other technologies, other 
addressing plans) might meet license (BCP 78) problems and IANA use 
political/compatibility issues. This protects "status-quo" of the 
unachieved architecture

Under that circumstance, the IETF Trust ownership is an advisable 
do-no-better makeshift until BCP78 is replaced by a CC BY SA licence 
or a chinese wall big work simplifies the way to use the world 
digital infrastructure in publishing a Free Wolrd Digital Reference 
Book with Catenet, Internet, Interplus, Brainware layers parts and 
online acess to updated tables.

Things take time. 30 years of strategic status quo ...
jfc

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Oct 2014 10:45:01 +0200

Hi,

As Leslie pointed out, there were possible two statements made.  I
believe I have heard at least some support for the following statement,
which I would mention in the section of overlap, because we are
discussing overlap.  To address the matter succinctly, however, may be a
bit of a challenge.  I think it's a good idea to make clear to others
*why* it's important to view IP addresses as a type of protocol
parameter.  So... here is what Russ and I propose, to add to the overlap
discussion:

   The IETF is responsible for policy relating to the entire IP address
   space and AS number space.  Through IANA, the IETF delegates
   unicast IP addresses and AS numbers to the RIR system [RFC7020,RFC7249].

   Special address allocation, such a multicast and anycast addresses,
   often require coordination.  Another example of IP addresses that are
   not administered by the RIR system is Unique Local Addresses (ULAs)
   [RFC4193], where local networks employ a prefix that is not intended
   to be routed on the public Internet.  In all cases, these special
   assignments are listed in the IANA registries.

Eliot

On 10/21/14, 4:29 PM, Leslie Daigle (TCE) wrote:
> The first statement says that all address space that is not listed as
> an IETF sub-registry is general address space for allocation via the

---

From: Andrei Robachevsky <[email-masked]>
Date: Thu, 23 Oct 2014 11:08:31 +0200

Hi,

I think this should appear as an answer to the question "What registries
are involved in providing the service or activity", and maybe
re-iterated in the overlap and other sections as appropriate.

When we say that the IETF is responsible for policy relating to the
entire IP address space and AS number space, do we also imply that IETF
is responsible for ensuring proper provisioning of these top-level
registries (e.g. the oprator and the SLAs)? I think John asked a similar
question.

Andrei

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Oct 2014 14:13:30 +0200

> registries (e.g. the oprator and the SLAs)? I think John asked a similar

Yes, at the time of their creation.

Eliot

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 23 Oct 2014 10:17:49 -0400

Le 2014-10-23 à 04:45, Eliot Lear <[email-masked]> a écrit :

> Hi,
> 
> As Leslie pointed out, there were possible two statements made.  I believe I have heard at least some support for the following statement, which I would mention in the section of overlap, because we are discussing overlap.  To address the matter succinctly, however, may be a bit of a challenge.  I think it's a good idea to make clear to others why it's important to view IP addresses as a type of protocol parameter.  So... here is what Russ and I propose, to add to the overlap discussion:

looks good to me. minor suggestions below.

>    unicast IP addresses and AS numbers to the RIR system [RFC7020,RFC7249].

unicast IP addresses ranges and AS numbers ranges ...

>    assignments are listed in the IANA registries.

I would add: "New special address allocations are added, from time to time, related to the evolution of the standards."

Marc.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Oct 2014 16:37:45 +0200

Ok.  My intent is to respin the draft one more time.  That should happen
tomorrow.

Eliot

On 10/23/14, 4:17 PM, Marc Blanchet wrote:
>
> Le 2014-10-23 à 04:45, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> a écrit :
>
>> Hi,
>>
>> believe I have heard at least some support for the following
>> statement, which I would mention in the section of overlap, because
>> we are discussing overlap.  To address the matter succinctly,
>> however, may be a bit of a challenge.  I think it's a good idea to
>> make clear to others *why* it's important to view IP addresses as a
>> type of protocol parameter.  So... here is what Russ and I propose,
>> to add to the overlap discussion:
>

> I would add: "New special address allocations are added, from time to
> time, related to the evolution of the standards."
>
> Marc.
>
>>
>> Eliot
>>
>> [email-masked] <mailto:[email-masked]>