Subject: Please review draft-housley-rfc2050bis-00.txt

From: Russ Housley <[email-masked]>
Date: Sat, 16 Mar 2013 18:13:18 -0400

A new, I-D, draft-housley-rfc2050bis-00.txt, has been posted.  I am writing to ask for your review.

Russ

= = = = = = = = = =

Filename:	 draft-housley-rfc2050bis-00.txt
Title:		 The Internet Numbers Registry System
Creation date:	 2013-03-14
Group:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-housley-rfc2050bis-00.txt
Status:          http://datatracker.ietf.org/doc/draft-housley-rfc2050bis

Abstract:
  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 document replaces RFC 2050.

  This document does not propose any changes to the Internet Numbers
  Registry System.

---

From: David Farmer <[email-masked]>
Date: Mon, 18 Mar 2013 17:51:15 -0500

1) In Section 1, goal #2, "Hierarchical Allocation", I believe a 
reference the definition in RFC 5226 - Section 4.1.  Well-Known IANA 
Policy Definitions, should be considered.

2) I also wonder if another appropriate goal would be explicitly 
defining the ASN and IP address registries using RFC 5226 language 
including the formal linkage to ICANN and the RIRs as the mechanism for 
IANA to implementing the Hierarchical Allocation of these registries. 
See: RFC 5226, section 4.3. "Updating IANA Guidelines for Existing 
Registries"

The intention wouldn't be to override RFC 2860, ICANN Policy, or IR 
global policy, but to provide and explicit formal technical definition 
for these registries that really have only been implicitly defined to 
date as far as I can tell.  There are any number of other registries 
that are far less important overall, that have excellent formal 
technical definitions that comply with RFC 5226 or its predecessors. 
However, these our most important registries have no such formal 
technical definitions, I think its really time to fix this situation.

That said, to the greatest extent possible we need a formal technical 
definition compliant with RFC 5226 of the as-is-state, not of the 
want-it-to-be-state.  Or, if I'm incorrect and there are formal 
technical definitions for these registries that comply with RFC 5226, or 
its predecessors, then they should be referenced in this document.

3) The last paragraph of Section 3, "Internet Numbers Registry Technical 
Considerations"  Says;

    As the Internet and the Internet Numbers Registry System continue to
    evolve, it may be necessary for the Internet community to examine
    these and related technical and operational considerations and how
    best to meet them.

I wonder if it wouldn't be appropriate to at least provide some 
suggestions for how this is to be accomplished.  Maybe request that 
future RFCs related to these technical and operational considerations 
include an applicability statement as to the Internet Numbers Registry 
System, either in a separate section or maybe as a sub-section of the 
IANA Considerations.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Mar 2013 11:23:57 +0100

While I appreciate the minimalist approach, can we please get one
*phrase* each on what is being referenced, so that people might have
some reason to actually read the reference:

>     Internet Registries [ASOMOU] and documented in [ICANNv4],
>       [ICANNv6], and [ICANNASN].

Also, I note that the NRO is not mentioned at all.  Perhaps the NRO is
merely meant to support RIR activities, but no mention at all?

---

From: Russ Housley <[email-masked]>
Date: Tue, 19 Mar 2013 15:48:44 -0400

David:

> 1) In Section 1, goal #2, "Hierarchical Allocation", I believe a reference the definition in RFC 5226 - Section 4.1.  Well-Known IANA Policy Definitions, should be considered.

We could do so, but I do not believe that the few word in RFC 5226 on hierarchical allocation improve the understanding of IP address allocation being discussed here.

> 2) I also wonder if another appropriate goal would be explicitly defining the ASN and IP address registries using RFC 5226 language including the formal linkage to ICANN and the RIRs as the mechanism for IANA to implementing the Hierarchical Allocation of these registries. See: RFC 5226, section 4.3. "Updating IANA Guidelines for Existing Registries"
> 
> The intention wouldn't be to override RFC 2860, ICANN Policy, or IR global policy, but to provide and explicit formal technical definition for these registries that really have only been implicitly defined to date as far as I can tell.  There are any number of other registries that are far less important overall, that have excellent formal technical definitions that comply with RFC 5226 or its predecessors. However, these our most important registries have no such formal technical definitions, I think its really time to fix this situation.
> 
> That said, to the greatest extent possible we need a formal technical definition compliant with RFC 5226 of the as-is-state, not of the want-it-to-be-state.  Or, if I'm incorrect and there are formal technical definitions for these registries that comply with RFC 5226, or its predecessors, then they should be referenced in this document.

The top of the IPv6 Address Registry says:

 The IPv6 address management function was formally delegated to
 IANA in December 1995 [RFC1881]. The registration procedure
 was confirmed with the IETF Chair in March 2010.

RFC 1881 is short, but it seems to say the things that need to be said.

> 3) The last paragraph of Section 3, "Internet Numbers Registry Technical Considerations"  Says;
> 
> I wonder if it wouldn't be appropriate to at least provide some suggestions for how this is to be accomplished.  Maybe request that future RFCs related to these technical and operational considerations include an applicability statement as to the Internet Numbers Registry System, either in a separate section or maybe as a sub-section of the IANA Considerations.

This evolution is discussed in Section 4.  Maybe a forward pointer is needed.  Did you not find Section 4 sufficient?

Russ

---

From: David Farmer <[email-masked]>
Date: Tue, 19 Mar 2013 22:30:26 -0500

> We could do so, but I do not believe that the few word in RFC 5226 on hierarchical allocation improve the understanding of IP address allocation being discussed here.

OK.

> RFC 1881 is short, but it seems to say the things that need to be said.

Figured it existed for IPv6, but I didn't think of looking for the 
reference in the IANA registry.  I really like what RFC1881 says, and it 
should be referenced in the Draft.

But, looking at the IPv4 registry, it references RFC1466, which was 
obsoleted by 2050, which this proposes to obsolete, and the ASN registry 
references RFC1930.  Both of these are pretty murky as a formal 
technical definition for these two registries.  RFC6793 is referenced in 
the ASN registry for the 32 bit portion, but is just says it is 
expanding the registry to 32 bits.  I think the difference between 
RFC1881 and these other references reenforces my argument about needing 
a formal technical definition for at least the IPV4 and ASN registries 
that is compliant with RFC 5226.

> This evolution is discussed in Section 4.  Maybe a forward pointer is needed.  Did you not find Section 4 sufficient?

I saw that, it says;

    In addition, in the cases where the IETF sets technical
    recommendations for protocols, practices, or services which 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.

This is good, but I read it as saying the IR system, and the RIR's in 
particular, are obligated to consider the technical recommendations of 
the IETF when making policy.  That is only part of the equation.

I was looking for the other side, "the IETF is obligated to maintain 
clear, relevant, and up to date technical recommendations for the IR 
system, including how such recommendations are intended to apply to the 
IR system."

There are situations where RIR policy is consistent with IETF technical 
recommendations that have not been updated in a long time, or at least 
deprecated.  When issues come up they are said to be RIR policy issues, 
not IETF issues.  So, are the RIR's suppose to ignore outdated technical 
recommendations?  Who decided they are outdated?

Put another way, the RIR's need to follow the technical recommendations 
of the IETF, but the IETF needs to provide relevant technical 
recommendations including updating or deprecating them when they are no 
longer valid.  It can't be a one-way street.

Rereading things again, I have another suggestion;

4) Split the Goals of the Internet registry system out of the 
Introduction.  The Intro starts out talking about the document, its 
goals, and what is in scope and out of scope of the document.  Then 
transitions to talking about the goals of the Internet registry system. 
  I think the goals of the Internet registry system should be a separate 
section from the Introduction. And, the Introduction should be expanded 
to better describe the purpose of the document.

Thanks

---

From: John Curran <[email-masked]>
Date: Wed, 20 Mar 2013 13:04:03 -0600

On Mar 19, 2013, at 9:30 PM, David Farmer <[email-masked]> wrote:
> This is good, but I read it as saying the IR system, and the RIR's in particular, are obligated to consider the technical recommendations of the IETF when making policy.  That is only part of the equation.
> 
> I was looking for the other side, "the IETF is obligated to maintain clear, relevant, and up to date technical recommendations for the IR system, including how such recommendations are intended to apply to the IR system."

David - 

  Two points:

  1) Language along the lines of "the IETF is obligated to ..." really 
     isn't going to work, as the point of the RFC2050 revision is to 
     document existing relationships supporting the Internet Numbers
     Registry System, using pointers to existing source documents to
     the greatest extent possible.  Even if there were 100% agreement
     to the concept, it would not be appropriate to establish it via
     this document which is intended for "Informational" publication.

  2) More importantly, who is "the IETF" in such a construct?  Would 
     such a task (of periodically pondering if these recommendations
     need updating) fall to the IAB or IESG?  (I hadn't realized that 
     they needed extra work... ;-)   I believe that when you consider 
     that "we" each individually are the IETF (i.e. all of the folks 
     who participate in the working groups and writing drafts) then 
     it is clear that any "obligation" to update these technical 
     recommendations periodically would fall to those with an interest 
     in keeping them current.  You might even say that's what Russ,
     David, Geoff, and I are finally getting around to doing via this
     draft, at least for one of the key documents.

FYI,
/John

Disclaimers:  My views alone.  If you are reading this email long 
after publication, this email may be out-of-date and I do not commit
to updating its contents. ;-)

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 20 Mar 2013 19:43:02 +0000

Hi, Russ.
Two points:

On Tue, 2013-03-19 at 22:30 -0500, David Farmer wrote:
<snip>
> to better describe the purpose of the document.

I agree fully with this comment.  The first para of s1 needs a rewrite
and a little expansion to match up with the abstract to form a proper
intro.  The goals do belong in a separate section

Also regarding the first para of s4:

This contains some woolly hand-waving weasel words at the end:

> Over the years, the Internet Numbers Registry System has developed
>    mechanisms by which the structures, policies, and processes of the
>    Internet Numbers Registry System itself can evolve to meet the
>    changing demands of the global Internet community.  Further evolution
>    of the Internet Numbers Registry System is expected to occur in an
>    open, transparent, and broad multi-stakeholder manner.
                            ^^^^^^^^^^^^^^^^^^^^^^^
Who are these stakeholders?  Is this (just) the organisations named in
the document (I think that would be ICANN/IANA, IETF, *IRs - a large
number!) or is the community to be consulted? and governments?  So do we
have a view as to how all these people are to be informed that some
evolution is needed?

Regards,
Elwyn

---

From: Arturo Servin <[email-masked]>
Date: Wed, 20 Mar 2013 16:49:36 -0300

I interpret it as anybody.

	ISPs, cctlds, governments, gtlds, IETF, RIRs, ICANN, ISOC, you, me.

/as

---

From: David Farmer <[email-masked]>
Date: Wed, 20 Mar 2013 15:51:28 -0500

>       this document which is intended for "Informational" publication.

"xxx is obligated to ..." wasn't intended as a suggestions for text, but 
like I paraphrased the text from the draft above, and I intended it to 
paraphrase the the text that needs to be added.  The text above quoted 
from the draft "such recommendations must be taken into 
consideration..." and I agree with that.  I'll note the care in how it 
is worded, but it seems to flow only IETF to IR Sys

---

From: David Farmer <[email-masked]>
Date: Wed, 20 Mar 2013 16:25:10 -0500

Whops, that escaped.  Sorry.

Lets start over.

On 3/20/13 15:51 , David Farmer wrote:
>>>>> future RFCs related to these technical and operational
>>>>> considerations include an applicability statement as to the
>>>>> Internet Numbers Registry System, either in a separate section or
>>>>> maybe as a sub-section of the IANA Considerations.
>>>>
>>>> This evolution is discussed in Section 4.  Maybe a forward pointer
>>>> is needed.  Did you not find Section 4 sufficient?
>>>
>>> I saw that, it says;
>>>
>>> particular, are obligated to consider the technical recommendations
>>> of the IETF when making policy.  That is only part of the equation.
>>>
>>> system, including how such recommendations are intended to apply to
>>> the IR system."
>>
>> David -
>>
>>    Two points:
>>

"xxx is obligated to ..." wasn't intended as a suggestions for text, but 
like I paraphrased the text from the draft above, and I intended it to 
paraphrase the the text that needs to be added.  The text above quoted 
from the draft "...such recommendations must be taken into 
consideration..." and I agree with that.  I'll note the care in how it 
is worded, but it seems to flow only from IETF to IR System.

Maybe I'm just being overly sensitive to the "must" in "...such 
recommendations must be taken into consideration...". But, it seems to 
me that this says IR System must defer judgements on technical issues to 
the IETFs technical recommendations, even if they are old, crufty, and 
been left in dust by the march of technology.

>>       draft, at least for one of the key documents.

This is a common problem of community based, we are them they are us, 
type pseudo-organizations.

>> to updating its contents. ;-)

All I ask is you admit you changed you mind, you have the right to do 
that.  But, when the IETF changes it's mind by changing its consensus, 
then it needs to deprecate its old technical recommendations, or make 
sure everyone else is free to ignore the recommendations.

---

From: SM <[email-masked]>
Date: Wed, 20 Mar 2013 15:04:36 -0700

>This contains some woolly hand-waving weasel words at the end:

I looked up the meaning of weasel words and found the following:

   "words and phrases aimed at creating an impression that something specific
    and meaningful has been said, when in fact only a vague or ambiguous claim,
    or even a refutation has been communicated."

I might as well comment quickly about 
draft-housley-rfc2050bis-00.  The draft is a good effort but it might 
need more work in my humble opinion.

The intended status is Informational.  Is there a reason for that?

Why does the document obsolete RFC 2050?  There is no explanation for 
that in the Abstract or the Introduction section.

In Section 2:

    "The Internet Assigned Numbers Authority (IANA) is the traditional
     name for the technical team making and publishing the assignments
     of Internet protocol technical parameters, including Internet
     Protocol (IP) address space."

Is there a reference for that?

    "As a result of a Memorandum of Understanding (MOU)[RFC2860] between
     the IETF, IAB, and ICANN, the  technical work of the Internet
     Assigned Numbers Authority (IANA) is now performed by ICANN."

According to RFC 2860:

   The memo is "exclusively to define the technical work to be carried
   out by the Internet Assigned Numbers Authority on behalf of the
   Internet Engineering Task Force and the Internet Research Task Force."

That does not match the "as a result" text.

   "Today, IANA administers IP address space and AS numbers according
    to global number resource policies as developed per the agreement
    between ICANN and the Regional Internet Registries [ASOMOU] and
    documented in [ICANNv4], [ICANNv6], and [ICANNASN]."

I don't see what the above has to do with structure (see section title).

In Section 3:

   "Reverse DNS: In situations where reverse DNS was used, the
    policies and practices of the Internet Numbers Registry System
    have included consideration of the technical and operational
    requirements posed by reverse DNS zone delegation [RFC3172]."

According to RFC 5855:

   "The choice of operators for all nameservers concerned is beyond the
    scope of this document and is an IANA function that falls under the
    scope of Section 4 of the MoU between the IETF and ICANN [RFC2860]."

Maybe referencing RFC 5855 would be better.  It may be easier not to 
say anything about reverse DNS.

   "Public WHOIS: The policies and practices of the Internet
    Numbers Registry System have included consideration of the
    technical and operational requirements for supporting WHOIS
    services [RFC3013]."

The specification for Whois is RFC 3912.  I vaguely recall that the 
"policy" text in the previous specification was viewed as problematic 
by the IETF.

   "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 [ICANNBL].  These core
    values encourage broad, informed participation reflecting the
    functional, geographic, and cultural diversity of the Internet at all
    levels of policy development and decision-making, as well as the
    delegation of coordination functions and recognition of the policy
    roles of other responsible entities that reflect the interests of
    affected parties.  The discussions regarding Internet Numbers
    Registry evolution must also continue to consider the overall
    Internet address architecture and technical goals referenced in this
    document."

Could someone please translate the above in plain English?  What's 
the IETF angle in all that?

What action is required from IANA in Section 7?

Why should I read RFC 6484 to understand  draft-housley-rfc2050bis-00?

Regards,
-sm

---

From: John Curran <[email-masked]>
Date: Wed, 20 Mar 2013 16:43:16 -0600

On Mar 20, 2013, at 3:25 PM, David Farmer <[email-masked]> wrote:

> "xxx is obligated to ..." wasn't intended as a suggestions for text, but like I paraphrased the text from the draft above, and I intended it to paraphrase the the text that needs to be added.  The text above quoted from the draft "...such recommendations must be taken into consideration..." and I agree with that.  I'll note the care in how it is worded, but it seems to flow only from IETF to IR System.

The IETF defines the protocols, including the parameter fields.  While
the application of the protocols is up to the community, the IETF does
also on occasional state known technical recommendations or constraints
in usage of its technical standards. The original RFC2050 specified such
technical constraints, the RIR/operator community has generally respected 
them over time, and hence they've been included in the revised text.

> Maybe I'm just being overly sensitive to the "must" in "...such recommendations must be taken into consideration...". But, it seems to me that this says IR System must defer judgements on technical issues to the IETFs technical recommendations, even if they are old, crufty, and been left in dust by the march of technology.

We have existence proof that the Internet Number Registry system is quite
capable of determining when circumstances have changed and while generally
considering important advice, e.g. hierarchical assignment, the registries
have indeed evolved policy as necessary and specified by the community. 

Note also that that the actual text does not at all say "defer judgements 
on technical issues to the IETF's technical recommendations", but instead
that those recommendations must be considered in policy discussions:

 "In addition, in the cases where the IETF sets technical recommendations
  for protocols, practices, or services which 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."

I understand that you're seeking assurances that the IETF will dynamically
update any documents that affects the Internet Number Registry System, but
reality is that it takes specific efforts to make that happened (and they
don't always converge with productive output.)  This effort to update RFC2050
is at least a step towards getting better alignment than we have today.

FYI,
/John

Disclaimers: My views alone.   No header fields were harmed in the making
of this email.

---

From: John Curran <[email-masked]>
Date: Wed, 20 Mar 2013 17:38:52 -0600

On Mar 20, 2013, at 4:04 PM, SM <[email-masked]> wrote:
> I might as well comment quickly about draft-housley-rfc2050bis-00.  The draft is a good effort but it might need more work in my humble opinion.
> 

The RFC is not intended to establish anything new, only to recognize
the existing agreements and practices of the IETF in this area.

> Why does the document obsolete RFC 2050?  There is no explanation for that in the Abstract or the Introduction section.

The explanation is in Section 5 (Summary of Changes Since RFC 2050); 
isn't that usual practice for an RFC which replaces another in entirety?

> Maybe referencing RFC 5855 would be better.  It may be easier not to say anything about reverse DNS.

The text in RFC 5855 that you reference is with respect only to the
two top-level reverse domains, i.e. "all nameservers concerned" is 
preceded by:

  "1. IN-ADDR-SERVERS.ARPA to the nameservers listed in Section 2;
   2. IP6-SERVERS.ARPA to the nameservers listed in Section 3."

> Could someone please translate the above in plain English?  What's the IETF angle in all that?

It looks to be plain English to me...  can you be more specific
about what part of the text which is problematic?

> Why should I read RFC 6484 to understand  draft-housley-rfc2050bis-00?

I believe this is a trailing reference that should be deleted at this 
point.

Thanks for the comments!
/John

Disclaimers: My views alone. Use care in opening; contents may have 
             shifted during electronic flight.

---

From: SM <[email-masked]>
Date: Wed, 20 Mar 2013 19:45:38 -0700

Hi John,

This is an individual comment.

>the existing agreements and practices of the IETF in this area.

Ok.  I'll defer to the learned individuals of the IETF in respect to 
the intended status.  It is my understanding that the document also 
aims to replace BCP 12.

>isn't that usual practice for an RFC which replaces another in entirety?

I can only express an individual opinion and not what is usual 
practice for an RFC.  The few drafts I have read usually had an 
explanation in the Introduction section to help the reader.  I don't 
feel strongly about this.  I am more interested in seeing whether the 
IESG will file a DISCUSS about this.

By the way the summary of changes is very short.

>    2. IP6-SERVERS.ARPA to the nameservers listed in Section 3."

I preferred not to quote RFC 5855 in its entity.  My reading of that 
document and the discussions leading to it is that it is up to the 
IAB to provide technical guidance to ICANN about .arpa (re. reverse 
DNS).  I don't see any mention of "Internet Numbers Registry System" 
in RFC 3172 or RFC 5855.

I can only say that in my opinion the omission of the finer details 
does not have any negative consequences for the RIRs.

    framework and will respect ICANN's core values [ICANNBL]."

How does the above affect the IETF, e.g. what process changes 
happened between RFC 2050 and draft-housley-rfc2050bis-00?  Why is it 
even relevant to the IETF?

   "These core values encourage broad, informed participation reflecting
    the functional, geographic, and cultural diversity of the Internet at
    all levels of policy development and decision-making, as well as the
    delegation of coordination functions and recognition of the policy
    roles of other responsible entities that reflect the interests of
    affected parties."

I do not understand what the above means in practice.  The IETF is 
having a lengthy discussion about diversity.  The IETF community 
might learn from ICANN if it shares its experience of how it has 
successfully tackled cultural diversity.

   "The discussions regarding Internet Numbers Registry evolution must
    also continue to consider the overall Internet address architecture
    and technical goals referenced in this document."

After reading  draft-housley-rfc2050bis-00 it is my understanding 
that the Internet Numbers Registry is out of scope for the IETF.  I 
read the above as meaning that the IETF is telling RIRs and ICANN 
that they must also follow technical guidance from the IETF in 
respect to the Internet address archtecture.

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

The above sounds like something from the legal department.  I 
unfortunately cannot hire a lawyer to tell me whether that text 
matches the text in RFC 2860.  I don't see how one can expect 
informed participation when the text to be read might be unclear to 
the people from the rest of the world.

As an off-topic comment, it seems like there hasn't been careful 
review of an IANA policy for ASNs.  The wise members of the IESG 
would have caught the bug.

By the way I read my previous message [1] again and the reply [2] I 
received and I noticed that there wasn't any response to two of the questions.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg78135.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg78141.html

---

From: John Curran <[email-masked]>
Date: Wed, 20 Mar 2013 21:38:01 -0600

On Mar 20, 2013, at 8:45 PM, SM <[email-masked]> wrote:

> Ok.  I'll defer to the learned individuals of the IETF in respect
> to the intended status.  It is my understanding that the document
> also aims to replace BCP 12.

Excellent question; it's my belief that obsoleting RFC2050 would 
do that, but perhaps it would be best to make that point more 
specific in this document?

> does not have any negative consequences for the RIRs.

IN-ADDR maintenance is explicitly in RFC 2050, and has not been
overtaken by events to my knowledge, hence it is included in this 
successor document.

> How does the above affect the IETF, e.g. what process changes happened between RFC 2050 and draft-housley-rfc2050bis-00?  Why is it even relevant to the IETF?

The IETF/IAB signed an MOU with ICANN for performance of certain IANA tasks,
including a framework which recognized that ICANN would be dealing with policy 
issues related to the domain name system and the IP address system.  At the same 
time, the Regional Internet Registries worked with ICANN to perform the community-
based regional and global IP policy development coordinated with ICANN's overall 
framework.  This is clearly a different way of establishing IP address policy than 
described in the current RFC2050, and hence material to the IETF.

> I do not understand what the above means in practice.

There are lots of folks over in the DNS world wondering that same question... ;-)

Seriously, one could write volumes about ICANN, its structure, processes
oversight role, etc., but at the end of the day you'd be creating a fixed
copy of what is an evolving organization.  The IETF does not decide today
when and which new top-level domains are added to the DNS root, that is an
example of a question which requires "broad, informed participation reflecting
the functional, geographic, and cultural diversity of the Internet at all 
levels of policy development and decision-making."

> After reading  draft-housley-rfc2050bis-00 it is my understanding that the Internet Numbers Registry is out of scope for the IETF.  I read the above as meaning that the IETF is telling RIRs and ICANN that they must also follow technical guidance from the IETF in respect to the Internet address archtecture.

The IETF defines the architecture of the Internet Protocol, and this includes
the IP address space.  Regardless of whether policy development has been
delegated to the RIRs under the ICANN framework, the address architecture
is still established by the IETF.

> The above sounds like something from the legal department.  I unfortunately cannot hire a lawyer to tell me whether that text matches the text in RFC 2860.  I don't see how one can expect informed participation when the text to be read might be unclear to the people from the rest of the world.

To my knowledge, it does correctly represent the terms in RFC 2860, 
but I understand that the language is rather dense and may be hard
to parse.  We do not want to repeat the entirety of RFC 2860 here,
but it is useful for readers to know that per that MOU, there is a
has a delineation of responsibilities between the IETF and the 
ICANN/RIR system.

> By the way I read my previous message [1] again and the reply [2] I received and I noticed that there wasn't any response to two of the questions.

Agreed.  I commented on those aspects where my remarks may add value to 
the discussion; there are others on this list with greater experience and
knowledge which may help with other questions you have raised.

Thanks for the feedback - I hope I've helped explain at least some of the 
reasoning behind the language in the draft.
/John

Disclaimer:  My views alone.

---

From: SM <[email-masked]>
Date: Thu, 21 Mar 2013 08:16:41 -0700

Hi John,
>do that, but perhaps it would be best to make that point more

Yes.

>specific in this document?

It may be easier to add text which provides a (simple) explanation 
about why RFC 2050 is obsolete.  The text in Section 5 (possibly with 
changes) could be moved to Section 1.

The draft already has the core of the text.  If Section 1 and Section 
2 are restructured most of the work is done.

>described in the current RFC2050, and hence material to the IETF.

The above is clear and to the point.

>There are lots of folks over in the DNS world wondering that same 

:-)

>levels of policy development and decision-making."

Yes.  That's why I would suggest keeping the draft simple instead of 
getting into ICANN stuff.

>is still established by the IETF.

The above is clear and to the point.  It is good material for the draft.

>has a delineation of responsibilities between the IETF and the

There is already a normative reference to RFC 2860.  Please note that 
I have not spent sufficient time reading the draft and related 
material to suggest whether or how to reference the terms in RFC 2860.

There argument is about the delineation of responsibility.  RFC 2860 
could be side-stepped; i.e. the draft could be turned into an 
understanding between the IETF and RIRs.  Obviously ICANN or any 
other organization can be added to the mix if anyone affiliated with 
the organization posts arguments to this mailing list to explain why 
that should be done.

>knowledge which may help with other questions you have raised.

Ok.  I will try to be patient and wait for people with greater 
experience and knowledge to address those questions.

>reasoning behind the language in the draft.

Thank you for the clear explanations and providing the reasoning.

Regards,
-sm

---

From: Russ Housley <[email-masked]>
Date: Fri, 22 Mar 2013 11:11:48 -0400

> intro.  The goals do belong in a separate section

Okay.  I'll tackle that for the next version.

>>   open, transparent, and broad multi-stakeholder manner.

How would you describe the bottoms-up policy development process used by the RIRs?  And, when all of them agree, the adoption of a global policy.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 22 Mar 2013 11:43:45 -0400

> The intended status is Informational.  Is there a reason for that?

RFC 2050 contains rules that are superseded by RIR policies.

> Why does the document obsolete RFC 2050?  There is no explanation for that in the Abstract or the Introduction section.

This document replaces RFC 2050.  Since the publication of RFC 2050, the Internet Numbers Registry System has changed significantly.  This document describes the present Internet Numbers Registry System.

> Is there a reference for that?

RFC 2860 seems to be a fine reference.  We could find others, but this seems to be good enough.

> I don't see what the above has to do with structure (see section title).

The authors will try to improve the wording.  The discussion of IANA should probably say that IANA represents to top of the IP address and AS number allocation hierarchies.

> Maybe referencing RFC 5855 would be better.  It may be easier not to say anything about reverse DNS.

Thanks.

> The specification for Whois is RFC 3912.  I vaguely recall that the "policy" text in the previous specification was viewed as problematic by the IETF.

Thanks.

> Could someone please translate the above in plain English?  What's the IETF angle in all that?

This points to the policy structure that replaces the rules that were in RFC 2050.

> What action is required from IANA in Section 7?

No actions at this time.

> Why should I read RFC 6484 to understand  draft-housley-rfc2050bis-00?

It should be informative.

Russ

---

From: SM <[email-masked]>
Date: Fri, 22 Mar 2013 09:55:24 -0700

Hi Russ,
>RFC 2050 contains rules that are superseded by RIR policies.

That doesn't explain the label. :-)

>This document replaces RFC 2050.  Since the publication of RFC 2050, 
>the Internet Numbers Registry System has changed 
>significantly.  This document describes the present Internet Numbers 
>Registry System.

I suggest adding text, for example, what is mentioned above.

>this seems to be good enough.

Ok.

>The authors will try to improve the wording.  The discussion of IANA 
>should probably say that IANA represents to top of the IP address 
>and AS number allocation hierarchies.

There is already text in the first paragraph of Section 2.  I suggest 
leaving it to that.

>This points to the policy structure that replaces the rules that 

John Curran responded to this.  The current text is not clear.  If 
you would like to remove policy text it may be better not to get into 
policy text.

>No actions at this time.

I suggest removing the IANA Considerations Section.

>It should be informative.

I don't see how it would be referenced in the draft then.  I suggest 
removing that reference.

Regards,
-sm