Subject: Re: Last Call: <draft-housley-rfc2050bis-01.txt> (The Internet Numbers Registry System) to Informational RFC

From: SM <[email-masked]>
Date: Fri, 10 May 2013 11:40:45 -0700

At 16:06 16-04-2013, The IESG wrote:
>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'The Internet Numbers Registry System'
>   <draft-housley-rfc2050bis-01.txt> as Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2013-05-14. Exceptionally, comments may be

This draft is well-written and it is a significant improvement 
compared to the previous version.

In Section 2:

   "As such, allocations must be made in accordance with the operational
    needs of those running the networks that make use of these number
    resources and by taking into consideration pool limitations at the
    time of allocation."

The global IPv4 address pool is currently depleted.  Two RIR regions 
are in IPv4 exhaustion phase.  There is a proposal in the RIPE region 
to remove "need" [1].  I gather that this new version of the Internet 
Numbers Registry System looks towards a future where hosts are IPv6 
accessible.  Given that the free IPv6 address pool is very large and 
that IP addresses are not free, what is the rationale for keeping 
allocations in accordance with operational needs?

   "Registration Accuracy: A core requirement of the Internet
    Numbers Registry System is to maintain a registry of
    allocations to ensure uniqueness and to provide accurate
    registration information of those allocations in order to
    meet a variety of operational requirements."

There isn't any mention of privacy [2] considerations in the 
draft.  Is it up to the IETF to set up a one-stop shop for personal 
data requests?

Regards,
-sm

1. https://www.ripe.net/ripe/policies/proposals/2013-03
2. http://lists.arin.net/pipermail/arin-ppml/2012-April/024596.html

---

From: "cb.list6" <[email-masked]>
Date: Fri, 10 May 2013 17:44:29 -0700

On May 10, 2013 11:51 AM, "SM" <[email-masked]> wrote:
> This draft is well-written and it is a significant improvement compared
to the previous version.
> The global IPv4 address pool is currently depleted.  Two RIR regions are
in IPv4 exhaustion phase.  There is a proposal in the RIPE region to remove
"need" [1].  I gather that this new version of the Internet Numbers
Registry System looks towards a future where hosts are IPv6 accessible.
 Given that the free IPv6 address pool is very large and that IP addresses
are not free, what is the rationale for keeping allocations in accordance
with operational needs?

I disagree with need based assignment and believe this draft should remove
all such language

The need based policy is not equitable and is nothing but a drag in the
post ipv4 exhaust world.

I have made a case for moving away from need basis here,
http://lists.arin.net/pipermail/arin-ppml/2013-April/026592.html

The ietf should really take the time to review what the rirs have done and
if their mandate needs to be updated.

Ipv4 belongs to the market and ipv6 does not have scarcity issues.

CB

> There isn't any mention of privacy [2] considerations in the draft.  Is
it up to the IETF to set up a one-stop shop for personal data requests?

---

From: David Conrad <[email-masked]>
Date: Fri, 10 May 2013 18:36:15 -0700

SM,

On May 10, 2013, at 11:40 AM, SM <[email-masked]> wrote:
> The global IPv4 address pool is currently depleted.  

The IANA IPv4 free pool is exhausted (well, modulo blocks of addresses returned to IANA), yes.

> Two RIR regions are in IPv4 exhaustion phase.  There is a proposal in the RIPE region to remove "need" [1].  

Yes.

> I gather that this new version of the Internet Numbers Registry System looks towards a future where hosts are IPv6 accessible.  

Sure, but it is also looking towards the remaining few IPv4 allocations that will be made over the next few years.

> Given that the free IPv6 address pool is very large and that IP addresses are not free, what is the rationale for keeping allocations in accordance with operational needs?

The fact that the IPv6 address pool is very large does not remove the fact that it is a not an infinite resource and thus, constraints must be applied to allocation policy. Lacking those constraints, I'm sure you or I could come up with an allocation policy that would blow through the IPv6 free pool quite quickly. To date, the communities interested in IP addressing have established policies that dictate "operational needs" should be the primary constraint (as opposed to say constraining on geo-political boundaries, by ability to pay, etc). However, the second part of that sentence is saying that pool limitations at the time of allocation should also be taken into consideration.  Since _at this time_ the IPv6 free pool is quite large, it would follow that allocation policy constraints would be minimal (as I believe they are).

> There isn't any mention of privacy [2] considerations in the draft.  

True. The document is documenting current practices and policies. At this point in time, I'm unaware of a global privacy practice or policy that is applicable to all levels of the Internet Numbers Registry System.

> Is it up to the IETF to set up a one-stop shop for personal data requests?

I suspect not, but I suspect it isn't up to the IETF to dictate global privacy policy either.

Regards,
-drc

---

From: Eliot Lear <[email-masked]>
Date: Sat, 11 May 2013 14:14:57 +0100

Dave,

Just on this point:

> True. The document is documenting current practices and policies. At this point in time, I'm unaware of a global privacy practice or policy that is applicable to all levels of the Internet Numbers…

It's probably worth saying that the various PDPs SHOULD address policy
considerations.  How they address them is a matter for them, individually.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Sat, 11 May 2013 14:24:29 +0100

Uch...  you can see where my head is:

> considerations. How they address them is a matter for them, individually.

s/policy considerations/privacy considerations/

Grr...

Eliot

---

From: SM <[email-masked]>
Date: Sat, 11 May 2013 08:17:12 -0700

Hi David,
At 18:36 10-05-2013, David Conrad wrote:
>Sure, but it is also looking towards the remaining few IPv4 
>allocations that will be made over the next few years.

I am looking at the draft from an IETF perspective.  There is IPv4 
address space for protocol assignments.  It could be said that the 
IETF's role is limited to providing guidance on IP architectural and 
operational considerations (e.g. RFC 6177).  Several years ago some 
RIRs adopted policies which were inconsistent with IAB/IESG 
recommendations.  I suggest leaving IPv4 allocations unrelated to 
protocol assignments up to other communities to avoid further inconsistencies.

>The fact that the IPv6 address pool is very large does not remove 
>the fact that it is a not an infinite resource and thus, constraints 
>must be applied to allocation policy.

The constraints are not set by the IETF.  It's up to other 
communities to see what constraints, if any, should be applied.

>  Lacking those constraints, I'm sure you or I could come up with an 
> allocation policy that would blow through the IPv6 free pool quite 
> quickly. To date, the communities

Yes.  I doubt that you or I would get away with it. :-)

>interested in IP addressing have established policies that dictate 
>"operational needs" should be the primary constraint (as opposed to 
>say constraining on geo-political boundaries, by ability to pay, 
>etc). However, the second part of that sentence is saying that pool 
>limitations at the time of allocation should also be taken into 
>consideration.  Since _at this time_ the IPv6 free pool is quite 
>large, it would follow that allocation policy constraints would be 
>minimal (as I believe they are).

InternetNZ wrote a very good message, in my opinion, a few months to 
argue for the position it took on a proposal.  It applied its 
principles to explain its position.  I would like to look at this in 
terms of principles instead of politics.  From the above I see that 
communities interested in IP addressing set the policy constraints, 
e.g. "operational needs".  If it's a policy it cannot be a principle.

I'll suggest alternative text:

   1) Allocation Pool: IP addresses and AS numbers are fixed length numbers.
      The allocation pools for these number resources are considered as
      resources which are finite.

The principle for the above is to avoid set any constraint unless it 
is necessary for IETF protocols to work.

>True. The document is documenting current practices and policies. At 
>this point in time, I'm unaware of a global privacy practice or 
>policy that is applicable to all levels of the Internet Numbers 
>Registry System.
>

Section 2 is about the goals for distributing number resources (re. 
first sentence).  I suggest removing the third goal as it might be a 
matter of global (or other) policy.  It also makes privacy a 
non-issue as there isn't any relationship between it and the goals.

In Section 5:

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

I'll wordsmith this:

   It is expected that discussions regarding Internet Numbers 
Registry evolution
   will continue to consider the overall Internet address architecture and
   goals mentioned in this document.

I removed the "must".

I noticed the following in Section 5:

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

The text does not add any value as "must be taken into consideration" 
does mean anything.  The IETF publishes recommendations which people 
can elect to follow or ignore.  If one believes that it is important 
to consider technical recommendations the person or organization can 
try and convince the appropriate venue to state that.

Regards,
-sm

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 May 2013 08:14:23 +1200

On 12/05/2013 03:17, SM wrote:
...
>> The fact that the IPv6 address pool is very large does not remove the
>> fact that it is a not an infinite resource and thus, constraints must
>> be applied to allocation policy.
> 
> The constraints are not set by the IETF.  It's up to other communities
> to see what constraints, if any, should be applied.

It's up to the IETF to set boundary conditions for the address space
that it created (in the case of IPv6) or inherited (in the case of
IPv4), in order to protect the long-term viability of the Internet.

...

>      resources which are finite.

That doesn't set any boundary conditions beyond those imposed by
mathematics, and is therefore a no-op. The mention of "operational
needs" is a real boundary condition that makes it clear that
address space is not to be wasted. As has been pointed out from
time to time, it would be quite easy to design an allocation model,
fully respecting the hierarchical constraint in the following
guideline, that blows away galactic quantities of address space,
even for IPv6.

It is entirely appropriate for the IETF and IAB to write a goal
that avoids this.

> The principle for the above is to avoid set any constraint unless it is
> necessary for IETF protocols to work.

No IETF protocol will work if the address space is exhausted of
if BGP4 runs out of steam or otherwise fails. The goals listed in
Section 2 address that.

...
> matter of global (or other) policy.  

No, it's a necessity in order for the two preceding goals to be
verifiably achieved, and to avoid accidental duplication of
addresses.

...

>   It is expected that discussions regarding Internet Numbers Registry
> evolution

The "must" is necessary.

> does mean anything.  

Er, it means what it says. It is exactly as powerful as any other
"must" or even "MUST" written by the IETF. If you ignore it, your
network might break.

I think that the current wording of the draft is correct.

   Brian

---

From: SM <[email-masked]>
Date: Sat, 11 May 2013 16:34:24 -0700

At 13:08 11-05-2013, Tom Vest wrote:
>Sorry, but unless you can point to some relevant real-world examples 
>of self-executing, self-sustaining principles, or you're a nihilist 
>and don't really believe that such things as principles exist at 
>all, this is a patently false, bordering on nonsense statement.

I am not suggesting any self-executing or self-sustaining principles.

>One is tempted to ask "work for who?" but that would entail giving 
>this statement more credence that it merits. Since TCP/IP is only 
>useful to the end of communication between two or more nodes, the 
>proposed "principle" of finitude would perfectly consistent with 
>this, and almost every other IETF addressing/attachment protocol 
>*not* working at all.
>
>Or did you mean to say that "The principle for the above is to avoid 
>set any constraint unless it is necessary for IETF protocols to 
>'work' between two virtual machines, under lab conditions"?

What I meant was to leave policy (PDP, etc.) to the communities 
interested in IP addressing.  I'll quote part of a message posted on 
the thread:

   'To date, the communities interested in IP addressing have 
established policies
    that dictate "operational needs" should be the primary constraint 
(as opposed
    to say constraining on geo-political boundaries, by ability to pay, etc).'

The message is at 
http://www.ietf.org/mail-archive/web/ietf/current/msg79200.html in 
case what I was quoted is misrepresented.

>IPv4), in order to protect the long-term viability of the Internet.

There is some text about Internet address architecture.  It would 
cover that if the relevant communities are agreeable to it.

Regards,
-sm

---

From: Tom Vest <[email-masked]>
Date: Sat, 11 May 2013 16:08:39 -0400

On May 11, 2013, at 11:17 AM, SM wrote:

> If it's a policy it cannot be a principle.

Sorry, but unless you can point to some relevant real-world examples of self-executing, self-sustaining principles, or you're a nihilist and don't really believe that such things as principles exist at all, this is a patently false, bordering on nonsense statement.

> The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to work.

One is tempted to ask "work for who?" but that would entail giving this statement more credence that it merits. Since TCP/IP is only useful to the end of communication between two or more nodes, the proposed "principle" of finitude would perfectly consistent with this, and almost every other IETF addressing/attachment protocol *not* working at all. 

Or did you mean to say that "The principle for the above is to avoid set any constraint unless it is necessary for IETF protocols to 'work' between two virtual machines, under lab conditions"? 

I suggest that the proposed alternative text should be rejected.

> Section 2 is about the goals for distributing number resources (re. first sentence).  I suggest removing the third goal as it might be a matter of global (or other) policy.  

Since uniqueness is a basic constraint for most if not all current addressing/attachment-related IETF protocols -- even between two virtual machines, under lab conditions -- and would still be a basic constraint even if current address protocols were not quantity constrained in any way, you seem to be suggesting that the IETF forego not only policy statements, but also your own "only work" principle, at least under certain circumstances. 

Bottom line: this word "principle," I do not think it means what you think it means. 

I suggest leaving section three in place.

TV

---

From: Tom Vest <[email-masked]>
Date: Sun, 12 May 2013 16:45:51 -0400

> I am not suggesting any self-executing or self-sustaining principles.

Fair enough; I will assume that we agree that "policies" and "principles" are not mutually exclusive and incompatible phenomena, and that the class of durable, self-executing, and self-sustaining principles is an empty set.

> What I meant was to leave policy (PDP, etc.) to the communities interested in IP addressing.  I'll quote part of a message posted on the thread:
> 
>  'To date, the communities interested in IP addressing have established policies
>   that dictate "operational needs" should be the primary constraint (as opposed
> The message is at http://www.ietf.org/mail-archive/web/ietf/current/msg79200.html in case what I was quoted is misrepresented.

I certainly did not intend to misrepresent your position. But given the fact that the "part of a message" that you reproduced was offered in response to doubts that you yourself raised about the points covered therein (esp. "operational need"), what is your position, exactly? As David said, "to date" the communities have established policies that are broadly informed by the practical implications of the finitude and uniqueness constraints on address resource management. However, to conclude based on past observations that such will always be true would be tantamount to claiming that management of those constraints is assured by the operation of (unspecified self-executing, self-sustaining) principles. Based on your views as expressed in/around draft-moonesamy-rfc2050-historic-00, it's pretty clear that you don't see any durable, much less "timeless" principles embodied therein -- but that only makes your position on these matters all the more ambiguous. 

Perhaps it would help if you would answer the following clarifying questions:

1. Is it your position that some other force or principle(s) outside of the general mechanisms/practices documented in RFC2050 (and potentially, RFC2050-bis) guarantees that IETF-defined addressing protocols will "just work" as designed, in perpetuity, and thus the informational codification of matters related to the management of finitude and uniqueness constraints is at best unnecessary, at worst counterproductive? If so, what are those unnamed forces/principles, exactly?

2. Is it your position that, if the traditional "communities interested in IP addressing" one day elect to adopt policies that make it impossible for IETF addressing protocols to fulfill even the basic "just work" test, then from the "IETF view"  that should be regarded as a perfectly appropriate and acceptable outcome?

> There is some text about Internet address architecture.  It would cover that if the relevant communities are agreeable to it.

Could you please clarify which passages about Internet address architecture you are suggesting are sufficient to make the sections about distribution and uniqueness constraints unnecessary?

Thanks, 

TV

---

From: SM <[email-masked]>
Date: Mon, 13 May 2013 01:49:16 -0700

At 13:45 12-05-2013, Tom Vest wrote:
>I certainly did not intend to misrepresent your position. But given 
>the fact that the
>  "part of a message" that you reproduced was offered in response to 
> doubts that you yourself raised about the points covered therein 
> (esp. "operational need"), what is your position, exactly? As David 
> said, "to date" the communities have established policies that are 
> broadly informed by the practical implications of the finitude and 
> uniqueness constraints on address resource management. However, to 
> conclude based on past observations that such will always be true 
> would be tantamount to claiming that management of those 
> constraints is assured by the operation of (unspecified 
> self-executing, self-sustaining) principles. Based on your views as 
> expressed in/around draft-moonesamy-rfc2050-historic-00, it's 
> pretty clear that you don't see any durable, much less "timeless" 
> principles embodied therein -- but that only makes your position on 
> these matters all the more ambiguous.

I prefer to keep draft-housley-rfc2050bis-01 separate from other 
drafts to keep matters simple.  My position is that it is better to 
work towards consensus.

>1. Is it your position that some other force or principle(s) outside 
>of the general mechanisms/practices documented in RFC2050 (and 
>potentially, RFC2050-bis) guarantees that IETF-defined addressing 
>protocols will "just work" as designed, in perpetuity, and thus the 
>informational codification of matters related to the management of 
>finitude and uniqueness constraints is at best unnecessary, at worst 
>counterproductive? If so, what are those unnamed forces/principles, exactly?
>
>2. Is it your position that, if the traditional "communities 
>interested in IP addressing" one day elect to adopt policies that 
>make it impossible for IETF addressing protocols to fulfill even the 
>basic "just work" test, then from the "IETF view"  that should be 
>regarded as a perfectly appropriate and acceptable outcome?

I don't have an opinion about questions (1) or (2).

>Could you please clarify which passages about Internet address 
>architecture you are suggesting are sufficient to make the sections 
>about distribution and uniqueness constraints unnecessary?

The comment was in a reply to a comment from another person.  There 
wasn't any mention of "distribution and uniqueness constraints" in 
the quoted text.

Regards,
-sm

---

From: David Farmer <[email-masked]>
Date: Tue, 14 May 2013 13:02:51 -0500

...
> matter of global (or other) policy.  It also makes privacy a non-issue
> as there isn't any relationship between it and the goals.
...

The third goal you refer to focuses on the need for "accurate 
registration information ... in order to meet a variety of operational 
requirements."  I believe this to be a valid technical concerns of the 
IETF, it is difficult to imagine how a global Internet can technically 
function without this.  So, I think it is important for it to remain in 
the draft.

However, issues of privacy, law enforcement access, and a myriad of 
other extremely important issues related to the Internet Numbers 
Registry System are outside the technical and operational scope of the 
IETF.  The whole point of the draft is to document the issues that are 
properly the concern of the IETF towards the Internet Numbers Registry 
System and to pass the rest of it to the multi-stakeholder environment 
of ICANN and the RIRs to hash it out.

-- 
================================================
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: David Conrad <[email-masked]>
Date: Tue, 14 May 2013 11:32:35 -0700

Hi,

On May 14, 2013, at 11:02 AM, David Farmer <[email-masked]> wrote:
> The third goal you refer to focuses on the need for "accurate registration information ... in order to meet a variety of operational requirements."  I believe this to be a valid technical concerns of the IETF, it is difficult to imagine how a global Internet can technically function without this.  So, I think it is important for it to remain in the draft.

I would also point out that the third goal makes no statement on whether the registration data is publicly available or not.

> However, issues of privacy, law enforcement access, and a myriad of other extremely important issues related to the Internet Numbers Registry System are outside the technical and operational scope of the IETF.  The whole point of the draft is to document the issues that are properly the concern of the IETF towards the Internet Numbers Registry System and to pass the rest of it to the multi-stakeholder environment of ICANN and the RIRs to hash it out.

Exactly. Section 4 notes that provision of "public WHOIS" has been a technical consideration and that "it may be necessary for the Internet community to examine these and related technical and operational considerations and how best to meet them."

Regards,
-drc

---

From: David Farmer <[email-masked]>
Date: Wed, 15 May 2013 18:50:55 -0500

> Exactly. Section 4 notes that provision of "public WHOIS" has been a technical consideration and that "it may be necessary for the Internet community to examine these and related technical and oper…

I agree with everything you say above regarding public available of the 
registration data.  However, at the same time Section 7, quoted below, 
makes a very strong argument for it to remain public.

"It is generally recognized that accuracy and public availability of 
Internet registry data is often an essential component in researching 
and resolving security and operational issues on the Internet."

So lets play a little hypothetical here;  What if an RIR or ICANN 
through a global policy decided Whois Data no longer should be public 
for overriding privacy reasons.  My read of Section 5, is that would be 
proper path for such a change, and long as the technical guidance of the 
IETF is considered in the process.  But then through RFC 2860 and 
Section 5, if the IETF objected on technical or architectural grounds, 
and formally through the IESG, then the IAB would essentially adjudicate 
the issue.  And ICANN or the RIR are obligated to accept the decision of 
the IAB.  Do I have that right?

To be clear, I'm not advocating Whois should or shouldn't remain public, 
or that anything is wrong with the Section 5.  This just seemed like a 
plausible hypothetical to explore how the puzzle pieces work together to 
make the Internet Numbers Registry System.  Also, I just want to fully 
understand what Section 5 really means.

Thanks.

---

From: John Curran <[email-masked]>
Date: Fri, 17 May 2013 08:13:01 -0400

On May 15, 2013, at 7:50 PM, David Farmer <[email-masked]> wrote:

> So lets play a little hypothetical here;  What if an RIR or ICANN through a global policy decided Whois Data no longer should be public for overriding privacy reasons.  My read of Section 5, is that would be proper path for such a change, and long as the technical guidance of the IETF is considered in the process.  But then through RFC 2860 and Section 5, if the IETF objected on technical or architectural grounds, and formally through the IESG, then the IAB would essentially adjudicate the issue.  And ICANN or the RIR are obligated to accept the decision of the IAB.  Do I have that right?

To be abundantly clear, you are hypothesizing a difference of opinion between the 
IETF/IESG and the ICANN/RIR communities, wherein the technical guidance of the IETF 
was considered during the ICANN/RIR decision process, but in the end the outcome was 
contrary to IETF expectations.

This would be an unfortunate (but not impossible) situation, as many folks in the 
combined community would likely have been involved during the process trying to 
figure out why there is such a significant difference in views and facilitating
sharing of the beliefs and thought processes that underlie the situation.  (btw,
these types of efforts happen in more contexts than just the hypothetical one you 
suggest, and are a good reason to ask "Have you hugged your AD recently"? ;-)
 
> To be clear, I'm not advocating Whois should or shouldn't remain public, or that anything is wrong with the Section 5.  This just seemed like a plausible hypothetical to explore how the puzzle pieces work together to make the Internet Numbers Registry System.  Also, I just want to fully understand what Section 5 really means.

Ultimately, your hypothetical situation could result in the breakdown of the present
relationship between IETF and ICANN/RIR organizations (ref: RFC 2860, section 2), with 
otherwise indeterminate consequences...  i.e. "It would be bad."   When the various 
Internet organizations are aligned in the coordination of Internet critical resources 
(DNS, IP addresses, protocol & parameter #'s), then the result is well understood.  
We lack experience with the alternative, and it is not clear whether chair remains 
upright when missing one or more legs.

FYI,
/John

p.s. Disclaimer:  My views alone.

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 May 2013 18:54:31 +0300

> To be abundantly clear, you are hypothesizing a difference of opinion
> between the IETF/IESG and the ICANN/RIR communities, wherein the
> technical guidance of the IETF was considered during the ICANN/RIR
> decision process, but in the end the outcome was contrary to IETF
> expectations.

if you s/expectations/preference/ then there is a growing track record.
try the new greed top level domains (gtlds) for starters.

randy

---

From: John C Klensin <[email-masked]>
Date: Fri, 17 May 2013 13:23:52 -0400

--On Friday, May 17, 2013 18:54 +0300 Randy Bush <[email-masked]>
wrote:

>> To be abundantly clear, you are hypothesizing a difference of
>> opinion between the IETF/IESG and the ICANN/RIR communities,
>> wherein the technical guidance of the IETF was considered
>> during the ICANN/RIR decision process, but in the end the
>> outcome was contrary to IETF expectations.
> 
> if you s/expectations/preference/ then there is a growing
> track record. try the new greed top level domains (gtlds) for
> starters.

I've been trying to stay out of this thread, but let me take
that a little further.  I believe that IETF "preferences" are
largely based on the overall welfare of the Internet as a
complete system.  I also believe that the understanding of that
system among IETF participants as a group is generally pretty
good.   Certainly we fail sometimes; IMO, much more often that
I'd like.   But there still seems to be rather general agreement
about success criteria and those criteria, to quote Harald's
comment of some years ago, involve making the Internet work
better.

In addition, actual capture of the IETF consensus process is
really hard.  WGs can sometimes be captured by specific
interests and the IESG decision processes are sometimes not
ideal, but capture is hard.  As several recent threads on the
IETF list illustrate, large portions of the community are
passionate about how decisions are made, express themselves
vigorously, and are usually listened to enough to affect actions
when that is appropriate.

As far as I can tell, large parts of the ICANN community and its
decision processes (I'm not going to comment on the RIRs because
I don't have nearly enough recent exposure) don't subscribe to
those same criteria.  Their most-cited criteria are
competitiveness.   "Security and stability" are chanted as a
mantra, but, empirically, that chant is about the avoidance of
major, scandalous, problems that can be directly attributed to
ICANN decisions rather than about making things better.  And the
price of entry and effective participation has gradually evolved
(or been captured) in a way that biases issue consideration and
decision making toward the wishes of a narrow range of
commercial interests with short-term profitability goals plus a
few symbolic "public" or "civil" "constituencies" whose ability
to be effective is constrained by the desire to continue to
participate and feed at the ICANN trough (the phrase "enjoy fine
lunches and dinners at the expense of others" may be applicable
here).   Those processes seem to be self-reinforcing and
self-reproducing enough, and driven in practice by a narrow
enough range of interests, to meet almost any criterion for a
"captured" label.

The level of harmony and conformance between ICANN's stated
principles and core values (as reflected in its bylaws,
reference [ICANNBL] in the draft) and ICANN's actual influences
and operational and decision-making practices would seem to lie
far outside the scope of this document.   I think the document
reflects a certain naivety about the range of differences
between theory and practice, but I'd not convinced that is
harmful beyond some risks of making the authors look silly in
some conceivable future scenarios.

If the "technical guidance of the IETF" were really based on the
best interests of a better Internet and then used as input to a
process that doesn't consider that a particularly useful
criterion, then an outcome that is contrary to that advice is
nearly inevitable unless the advice coincidentally matches the
criteria that are actually being used.  What should be done
about that is a different and, sadly complex matter  (especially
given the risks of significant collateral damage that could harm
the Internet).  

But it doesn't seem to me that is the present issue.  For the
present document, if it accurately describes the current
situation and how things have evolved since 2050, then it is
worth publishing.  If we don't like how things work, it seems to
me that changing that is part of a different effort and that a
good current description is a necessary starting point.

I, however, do have one significant objection to the current
draft of the document and do not believe it should be published
(at least as an RFC in the IETF Stream) until the problem is
remedied.  The Introduction (Section 1) contains the sentence
"Since the publication of RFC 2050, the Internet Numbers
Registry System has changed significantly."    That sentence is
expanded upon in Section 6, which bears the interesting title of
"Summary of Changes Since RFC 2050".  But Section 6 contains no
such summary, merely a statement that things have changed and
that some material -- unidentified except by the broadest of
categories -- has been omitted.   

I do not believe this document is complete enough to publish as
an RFC in the IETF Stream without a real summary of the changes
since 2050, preferably with either explanations of each
significant change or references to the documents or discussions
that instituted or explained those changes.

   best,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 May 2013 08:14:38 +1200

John,

On 18/05/2013 05:23, John C Klensin wrote:

...
> Registry System has changed significantly."   

If we want to avoid ratholes built into the document, it might be
prudent to rephrase that sentence as
"Since the publication of RFC 2050, the environment of the
Internet Numbers Registry System has changed."

> That sentence is

I took that section title to refer to changes *in the text* of
2050, not changes in the system. Maybe the authors could clarify
their intent, and if it is limited to text changes, clarify
the wording accordingly.

     Brian

---

From: John C Klensin <[email-masked]>
Date: Fri, 17 May 2013 19:59:16 -0400

--On Saturday, May 18, 2013 08:14 +1200 Brian E Carpenter
<[email-masked]> wrote:

>> draft of the document and do not believe it should be
>> published (at least as an RFC in the IETF Stream) until the
>> problem is remedied.  The Introduction (Section 1) contains
>> the sentence "Since the publication of RFC 2050, the Internet
>> Numbers Registry System has changed significantly."   
> 
> If we want to avoid ratholes built into the document, it might
> be prudent to rephrase that sentence as

Both statements are true-- the environment has changed and the
system has changed.  At least in principle, the environment has
changed less with three three really notable events being the
advent of ICANN, the end-game of the IPv4 address space, and the
growing importance of the IPv6 one.  I think that can be said
and the other changes summarized.  From my point of view, if we
have to avoid describing the changes to avoid ratholes, it would
be legitimate for someone to ask what we are hiding.  

>> That sentence is
>> expanded upon in Section 6, which bears the interesting title
>> of "Summary of Changes Since RFC 2050".  But Section 6
>> contains no such summary, merely a statement that things have
>> changed and that some material -- unidentified except by the
>> broadest of categories -- has been omitted.
 
> 2050, not changes in the system. Maybe the authors could
> clarify their intent, and if it is limited to text changes,
> clarify the wording accordingly.

I just checked your hypothesis by looking at a diff between 2050
and the present draft.  As far as I can tell from a quick
review, there is not a single unchanged paragraph.  So, if the
issue is text changes, this is not an update but an almost
complete replacement.

    john

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 May 2013 13:08:35 +1200

> issue is text changes, this is not an update but an almost

Yes, because apart from anything else, the draft leaves out
a number of topics that are explicitly out of IETF scope since
RFC 2860. I don't really see what we are hiding in this:

   This document
   describes the Internet Numbers Registry System as it presently exists
   and omits policy and operational procedures that have been superseded
   by ICANN and RIR policy since RFC 2050 publication.

(given that there is a reference to RFC 2860 a few lines earlier).

If I had the edit pen I would probably want to rephrase that
paragraph a bit, but it does say what has been deleted and why.

     Brian

---

From: Steve Crocker <[email-masked]>
Date: Tue, 21 May 2013 09:42:57 +0100

Dan and John,

Thanks for the exchange last week.  As chair of ICANN's Board of Directors and an active participant in ICANN's current effort to take a fresh look at the Whois architecture and operation, your notes catch my attention in multiple ways.  But first, for the benefit of under forty crowd, let me briefly introduce myself.  In the late 1960s I chaired the ARPANET's Network Working Group, which eventually morphed into today's IETF.  I created the RFC series and I was one of the architects of the three facets of openness that are the foundation of the Internet protocol process, viz open architecture, open participation and open publication.  In the late 1980s and early 1990s I served as the first area director for security and later on the IAB.  I also co-chaired the POSIED Working Group that revised the standardization process, moving the authority from the IAB to the IESG, and in the mid 2000s I served on the ISOC board and participated in the formation and initial operation of the IETF Administrative Support Activity (IASA) and I served on its IAOC.  For the past 11 years I've been active in ICANN, serving for several years as the chair of the Security and Stability Advisory Committee and also on the board of ICANN, and about two years ago I was elected chair of the ICANN board.  And despite having spent a great deal of time in management and political roles in this environment, I remain fundamentally a technical person.

I want to share two thoughts, one about the role of the IETF, ICANN and other organizations within the Internet ecosystem, and one about Whois.

The great strength of the IETF is it's a forum for technical people to come together, work out the details of protocols, and publish consensus documents.  The IETF does not have any formal powers granted by legal authorities.  IETF standards are effective because they're accepted and they work, not because they're imposed on anyone.  IETF standards are respected around the world because they embody the wisdom and experience of the technical community.  No one is obliged to use the protocols created within the IETF, but, of course, a huge portion of the world does use these protocols.

ICANN was created in 1998 to operate the IANA function and to expand and organize the marketplace in domain names.  The IANA function is fundamentally a clerical service.  It records the assignment of unique identifiers that are used throughout the Internet, and it does so in accordance with the values and policies established by the community.  The IANA service includes publication of the IETF's protocol parameters, allocation of blocks of AS numbers, IPv6 address blocks, and, until recently, IPv4 blocks to RIRs, and administration of the top level of the domain name hierarchy.

Like the IETF, ICANN is also an open organization.  ICANN meetings are free, and a veritable ocean of documents are published regularly, many in multiple languages to increase availability.

ICANN is purposefully organized to include participation from a range of communities, e.g. business, civil society, governments, and the technical community.  As I write this, I am at a retreat for the ICANN Board focusing on strategic planning.  One of the seats on the Board is allocated to a liaison from the IETF, and thus I am actually sitting at the time I drafted this note in between Thomas Narten and Jonne Soininen, the outgoing and incoming IETF liaisons to the ICANN Board.

One of the large and often time-consuming activities within ICANN is the development of policies that pertain to the domain name system.  John Curran wrote:

> sharing of the beliefs and thought processes that underlie the situation.

I agree completely with John.  It is indeed possible for ICANN to adopt policies that are not perfectly aligned with IETF recommendations.  Possible, but not usual.  Over here at ICANN we pay a LOT of attention to the IETF.  We depend heavily on the IETF's work and we never seek to duplicate or ignore it.  (I sometimes have to explain to my colleagues at ICANN who have not had the benefit of the IETF experience that "let's send it over to the IETF" doesn't work.  The IETF isn't a standing army ready to do ours or anyone else's work.  Rather, I say, it's a place where the relevant people can get together to get their work done.  And, indeed, a number of ICANN people actively participate in various IETF working groups.)

The roster of topics active within ICANN at any given time is fully documented and publicized, and I invite anyone who is interested to participate.  We listen to everyone, and we publish tentative results, tentative policies, etc. for everyone to critique.

Let me now turn to Whois.  The Whois system's origins go back to the earliest days of the Arpanet.  The roles of technical point of contact and administrative point of contact were usually the system administrator and his administrative manager for the time-sharing system at the laboratory at that site.  Each time-sharing system served somewhere between a few dozen and a few hundred users.  The users were not listed, just the administrators for the system.  There weren't really any issues of accuracy, privacy or accountability.  Today, of course, these terms apply to the registrants and supporting personnel for *each* domain name, and there are well over 100,000,000 domain names registered just within the generic top level domains.  The country code top level domains are roughly the same number, and their Whois structures and policies are each controlled by the individual ccTLD operator and their communities.

Last November, the ICANN Board accepted the recommendations of the Whois Review Team, an expert group commissioned under the Affirmation of Commitments (AoC) ICANN signed with the U.S. Department of Commerce in 2009.  The terms of reference included in the AoC continued the original model that the structure of Whois remain the same and that access be free and available to everyone.  A number of us on the ICANN Board had been concerned for a long time that purpose of the Whois system had evolved far away from its original purpose, and that it was well past time to take a fresh look at the entire system.  Accordingly, the Board initiated an effort, in parallel with acceptance and implementation of the Whois Review Team's recommendations, to start with a clean slate and think through whether we might be better served by a revised system.  An expert working group was assembled and is currently working through these issues.  Its output will be a consideration of the issues and recommendations for further work.  It is not yet clear whether the result of this effort will lead to a large change, a small change, or no change at all.  What is clear is that the results of this working group will become fully public, and any decisions will come through our usual policy development process.

As I said above, I invite anyone who is interested to participate.

The IETF, ICANN, the RIRs, ISOC, W3C and other organizations have all arisen within the ecosystem that accompanies the growth and prevalence of the Internet.  It is natural for there to be some tension, competition and rivalry among our institutions, but we have all been part of the same grand enterprise, we all share the same core values, and we all work toward the same goal of an open, innovative, expanding Internet.

Steve Crocker,
Chair, ICANN Board of Directors

---

From: Randy Bush <[email-masked]>
Date: Tue, 21 May 2013 16:58:44 +0700

dear emperor, despite the braggadocio, there seems to be a shortage of
attire.  icann is notorious for pretending to be open but being
effectively closed.  it solicits public comment and ignores it.  i could
go on and on, but i am far less wordy.

randy

---

From: Olivier MJ Crepin-Leblond <[email-masked]>
Date: Tue, 21 May 2013 12:00:24 +0200

> The IETF, ICANN, the RIRs, ISOC, W3C and other organizations have all arisen within the ecosystem that accompanies the growth and prevalence of the Internet.  It is natural for there to be some ten…

+1 to everything Steve has said.
And I take this opportunity to remind you that you can directly
influence the outcome of *all* the work at ICANN by taking part in it.
There are several avenues for this.

One of them is through the ALAC: the At-Large Advisory Committee's
(ALAC) role is to facilitate input from Internet users into the ICANN
policy processes. It does not purport to "represent" Internet users, but
it tries as much as it can to act in the *best interests* of Internet
users. But without your input and particularly on technical issues where
we need as much help as we can get, the ALAC cannot issue Statements
that adhere to the general point of view of Internet users.
How can you take part?
The North American region allows for individual membership. Other
regions require that you are part of an At-Large Structure (ALS) to
participate - but if you see the list, you'll notice there are a LOT of
ALSes, many of which are ISOC Chapters.
And you do NOT need to be part of an At-Large Structure to participate
in the At-Large Working Groups. Membership is only needed for matters of
voting - and since we operate by consensus, that's a rare occurrence,
usually only kept to selection of leadership.

A few links:
ALAC Correspondence: http://www.atlarge.icann.org/correspondence
ALAC Policy Development: https://community.icann.org/x/bwFO
ALAC Working Groups: https://community.icann.org/x/loIi

I know this is a shameless plug but in the face of the threat posed by
non-multi-stakeholder systems of governance, I felt a follow-up on
Steve's post was necessary. As Steve says so eloquently, we need to all
work toward the goal of an open, innovative, expanding Internet.

Warm regards,

Olivier MJ Crépin-Leblond
ALAC Chair
https://community.icann.org/x/ppEi

---

From: Olivier MJ Crepin-Leblond <[email-masked]>
Date: Tue, 21 May 2013 12:25:19 +0200

Dear Randy,

> go on and on, but i am far less wordy.

Quite frankly, I used to have the same feeling... until very recently.
With Steve at the wheel, things have improved a lot. Whilst as recently
as 3 years ago, we often used to feel that ALAC advice was tossed over
the wall and we'd never hear any feedback & be blatantly ignored, things
have improved and we are heard and more importantly listened to a lot
more. Credit for this is due to the new Leadership Teams, both on the
volunteer & Staff parts of ICANN. Today, it's still not perfect, but you
cannot fix a bus by shooting it - work on it instead, to fix it. I
believe it's fixable.
Start here: http://www.icann.org/en/news/public-comment/atrt2-02apr13-en.htm

Kind regards,

Olivier
(not wearing any hat)

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html

---

From: SM <[email-masked]>
Date: Tue, 21 May 2013 08:50:27 -0700

Hi Steve,
At 01:42 21-05-2013, Steve Crocker wrote:
>I want to share two thoughts, one about the role of the IETF, ICANN 
>and other organizations within the Internet ecosystem, and one about Whois.
>
>The great strength of the IETF is it's a forum for technical people 
>to come together, work out the details of protocols, and publish 
>consensus documents.  The IETF does not have any formal powers 
>granted by legal authorities.  IETF standards are effective because 
>they're accepted and they work, not because they're imposed on 
>anyone.  IETF standards are respected around the world because they 
>embody the wisdom and experience of the technical community.  No one 
>is obliged to use the protocols created within the IETF, but, of 
>course, a huge portion of the world does use these protocols.

IETF standards are  "de facto" standards.  It is doubtful whether 
some of the RFCs embody the wisdom and experience of the IETF 
community.  Nobody may be obliged to use these "standards".  However, 
do people have a choice?  How would I contact the IETF if my mail 
server uses another "standard"?

>Like the IETF, ICANN is also an open organization.  ICANN meetings 
>are free, and a veritable ocean of documents are published 
>regularly, many in multiple languages to increase availability.

I note that IETF meetings are not free.  Everyone can claim to be open.

>ICANN is purposefully organized to include participation from a 
>range of communities, e.g. business, civil society, governments, and 
>the technical community.  As I write this, I am at a retreat for the 
>ICANN Board focusing on strategic planning.  One of the seats on the 
>Board is allocated to a liaison from the IETF, and thus I am 
>actually sitting at the time I drafted this note in between Thomas 
>Narten and Jonne Soininen, the outgoing and incoming IETF liaisons 
>to the ICANN Board.

There are currently three comments about the proposed Whois 
Information Status Policy ( 
http://www.icann.org/en/news/public-comment/wisp-10may13-en.htm 
).  There's more comments than that for some IETF Last Calls (e.g. 
http://www.ietf.org/mail-archive/web/ietf/current/msg79366.html 
).  The IETF Chair posted an article on his blog.  There is a long 
thread about it ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg78984.html 
).  The ICANN range of communities seem to be having problems sending 
mail as I don't see any trace of their participation.

If I want to know what the IESG is up to, I read a web page and I find:

   "abstract: the draft does stuff, it doesn't 'set out to' do stuff, 
at least not anymore"

>  of the IETF experience that "let's send it over to the IETF" 
> doesn't work.  The IETF isn't a standing army ready to do ours or 
> anyone else's work.  Rather, I say, it's a place where the relevant 
> people can get together to get their work done.  And, indeed, a 
> number of ICANN people

Agreed.

>  actively participate in various IETF working groups.)

I do not see ICANN people participating in an IETF Last Call.  I 
would not call it active participation.

>The roster of topics active within ICANN at any given time is fully 
>documented and publicized, and I invite anyone who is interested to 
>participate.  We listen to everyone, and we publish tentative 
>results, tentative policies, etc. for everyone to critique.

I am curious about where the ICANN "process" is documented.  I could 
not find anything that looks like RFC 2026.

>within the generic top level domains.  The country code top level 
>domains are roughly the same number, and their Whois structures and 
>policies are each controlled by the individual ccTLD operator and 
>their communities.

With all due respect I find it hard to believe that Whois structures 
and policies are controlled by the respective communities.

>and think through whether we might be better served by a revised 
>system.  An expert working group was assembled and is currently 
>working through these issues.  Its output will be a consideration of 
>the issues and recommendations for further work.  It is not yet 
>clear whether the result of this effort will lead to a large change, 
>a small change, or no change at all.  What is clear is that the 
>results of this working group will become fully public, and any 
>decisions will come through our usual policy development process.

The output of that working group was lacking.  If an IETF working 
group cannot produce useful results it should be shut down.  It seems 
that ICANN's measure is "public" and "process" instead of a 
results-oriented approach.

>The IETF, ICANN, the RIRs, ISOC, W3C and other organizations have 
>all arisen within the ecosystem that accompanies the growth and 
>prevalence of the Internet.  It is natural for there to be some 
>tension, competition and rivalry among our institutions, but we have 
>all been part of the same grand enterprise, we all share the same 
>core values, and we all work toward the same goal of an open, 
>innovative, expanding Internet.

Please note that I can only speak for myself.  I don't see any 
reflection of the "functional geographic, and cultural diversity of 
the Internet  at all levels of policy development and 
decision-making" in the IETF.  The IETF does not share that core 
value.  I did not find anything in IETF documents about "depending on 
market mechanisms to promote and sustain a competitive 
environment".  I did not see anything in IETF documents about 
introducing and promoting competition".  I don't see anything in IETF 
documents about promoting decisions based on expert advice.  Someone 
in the IETF will likely correct me if I am incorrect about all this.

If there are statements in a document which appear to assert 
something but subtly imply something different, opposite, or stronger 
in the way they are made it is possible to materially affect the 
outcome by commenting about that.  The IESG could ignore the comments 
if it wishes.  That might not be a good idea though as something can 
be done about it.

ICANN's curse is having a community where people might burn it to the 
ground to get what they want.  That's possible in the IETF too.  The 
IETF's curse is having this mailing list.

I gather that everyone is aware that civil society has been somewhat 
uncivil lately.  That society has not made any significant negative 
comments about the IETF.  It has made negative comments about other 
organizations.  It is left to the reader to draw his or her conclusions.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Tue, 21 May 2013 09:09:37 -0700

Hi Olivier,
>usually only kept to selection of leadership.

The voting and consensus part reminds me of the ITU.  The vote that 
happened last year has been the subject of numerous comments.

>work toward the goal of an open, innovative, expanding Internet.

I don't see any threat.  What I see are words defined or redefined to 
suit the interests of the day.

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 May 2013 10:03:47 -0700

On 5/21/2013 8:50 AM, SM wrote:
> comments about the IETF.

Actually it has.  Since he's such a long-active figure in those circles, 
check out Milton Mueller's Ruling the Root, from 10 years ago.  He was 
quite critical and dismissive of the technical community, including the 
IETF:

    http://bbiw.net/musings.html#rootreviewl

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: SM <[email-masked]>
Date: Tue, 21 May 2013 12:51:25 -0700

Hi Dave,
At 10:03 21-05-2013, Dave Crocker wrote:
>Actually it has.  Since he's such a long-active figure in those 
>circles, check out Milton Mueller's Ruling the Root, from 10 years 
>ago.  He was quite critical and dismissive of the technical 
>community, including the IETF:

Thanks for the reference.  I have read some messages [1][2] from the 
person.  I don't recall reading the book.  As the subject line 
mentions Whois I found something to read [3].

Regards,
-sm

1. http://lists.arin.net/pipermail/arin-ppml/2012-April/024498.html
2. http://lists.ripe.net/pipermail/address-policy-wg/2012-April/006888.html
3. 
http://www.mendeley.com/download/public/777611/2362103122/da394283f86f68aa168abaf59d919f78d7c8f2b8/dl.pdf