Subject: Re: I-D Action: draft-moonesamy-rfc2050-historic-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Sat, 12 Jan 2013 09:36:00 +0000

I object to making RFC 2050 historic without retaining at least the
content of its Section 1 as an IETF BCP.

While the IETF did formally hand over details of address
allocation policy to IANA, we did so knowing that the RIRs
themselves, and IANA, considered themselves bound by RFC 2050
(see the list of authors of that document).

An update of RFC 2050, within the scope set by the IETF-IANA
MoU, would be reasonable. Abrogation is not reasonable.

Regards
   Brian Carpenter (speaking only for myself)

On 12/01/2013 08:51, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : Reclassifying Internet Registry Allocation Guidelines to Historic
> 	Author(s)       : S. Moonesamy
> 	Filename        : draft-moonesamy-rfc2050-historic-00.txt
> 	Pages           : 4
> 	Date            : 2013-01-12
> 
> Abstract:
> RFC 2050 describes the registry system for the distribution of globally
> unique Internet address space and registry operations.  It also
> discusses about policy issues which are outside the scope of the IETF.
> This document reclassifies RFC 2050 as Historic.  It also reclassifies
> RFC 1366 and RFC 1466 as Historic.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-moonesamy-rfc2050-historic
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-moonesamy-rfc2050-historic-00
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: S Moonesamy <[email-masked]>
Date: Sat, 12 Jan 2013 10:18:10 -0800

>content of its Section 1 as an IETF BCP.

 From Section 1 of RFC 2050:

   "Currently there are three regional IRs established;
    InterNIC serving North America, RIPE NCC serving Europe,
    and APNIC serving the Asian Pacific region."

The above information is outdated.

>(see the list of authors of that document).

That was in 1996.  The question is whether BCP 12 reflects current practices.

>MoU, would be reasonable. Abrogation is not reasonable.

Noted.

At 03:44 12-01-2013, Abdussalam Baryun wrote:
>I also think similar with Carpenter, why reclassify to historic.
>rfc2050 is still valid, and why limiting the ietf?

IETF participants have not decided about policies regarding IP 
address allocation since well over 10 years.  Such matters are 
determined within other communities.  It would only be limiting to 
the IETF if it is a matter directly related to IETF protocols.

Regards,
S. Moonesamy

---

From: David Conrad <[email-masked]>
Date: Sat, 12 Jan 2013 11:36:40 -0800

Brian,

> content of its Section 1 as an IETF BCP.

Which part of section 1 do you think has any relevance to the IETF as a BCP?

> (see the list of authors of that document).

As one of those authors, I will state that I believe that RFC 2050 should be moved to historic (actually should have been moved quite some time ago).

- RFC 2050 was an attempt to document the _then current_ policies and processes of the RIRs. An RFC was chosen because there was no other viable publication mechanism that would reach the relevant communities. The Internet has changed a bit since 1996.  RFC 2050 documents the "Best Current Practice" of the then Internet registries for a very brief window -- RIR policies had already changed from what was documented in RFC 2050 by the time it had gotten through the IESG gauntlet.

- RFC 2050 explicitly discusses allocation policy of IPv4. IPv4 allocation is largely over. The vast majority of RFC 2050 is not particularly relevant to IPv6. Address allocation policies are and have been defined within the address consuming communities which have (reasonably) robust, open, and transparent mechanisms by which anyone can contribute. The IPv6 allocation framework has been defined in other RFCs.

- RFC 2050 discusses allocating IPv4 addresses to RIRs, ISPs, and end users for operational purposes and is unrelated to meeting the technical protocol standardization needs of the IETF.

> MoU, would be reasonable.

No, since addressing is _explicitly_ declared out of scope of that MoU, see section 4.3 of RFC 2860:

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

I don't think it is particularly useful or helpful to try to assert that the IETF did "formally hand over" address allocation to IANA since, as you know, there are lots of folks who have, do, and will claim address allocation, as an operational matter, was never the IETF's to "hand over". What might be useful/helpful is to try to identify the portions of RFC 2050 that have any relevance to the IETF and verify that those portions are covered elsewhere.

Regards,
-drc

---

From: John C Klensin <[email-masked]>
Date: Sat, 12 Jan 2013 17:21:28 -0500

--On Saturday, January 12, 2013 11:36 -0800 David Conrad
<[email-masked]> wrote:

>...
>   "Two particular assigned spaces present policy issues in
> addition    to the technical considerations specified by the
> IETF: the assignment    of domain names, and the assignment of
> IP address blocks. These    policy issues are outside the
> scope of this MOU."
> 
> I don't think it is particularly useful or helpful to try to
> assert that the IETF did "formally hand over" address
> allocation to IANA since, as you know, there are lots of folks
> who have, do, and will claim address allocation, as an
> operational matter, was never the IETF's to "hand over". What
> might be useful/helpful is to try to identify the portions of
> RFC 2050 that have any relevance to the IETF and verify that
> those portions are covered elsewhere.

David (and Brian and Subramanian), 

There are cans of poisonous, vicious vipers (only superficially
resembling cans of worms) that are, IMO, best not opened and
this is, IMO, one of them.  The reasons for that are probably as
obvious to you as they are to me and I certainly agree with most
of your last paragraph above.  However, I don't think the
section of 2860 that you cite helps very much because there is
another way to read it.  That alternate reading, which I believe
is actually the correct one, says that the addressing issues
(and the domain ones) consist of two parts "technical
considerations" which are specified by the IETF and "policy
issues" that are someone else's problem.  Indeed, it says
"policy issues in addition to...", which I think recognizes that
those "technical considerations" may have policy implications
and that it is within scope for the IETF to specify those too.
The exclusion is for policy issues that are _not_ part of the
technical considerations.

With the understanding that the boundary that posits is very
fuzzy, I don't think that basic principle has changed
significantly since the MOU and probably not much since RFC
2050.  The IETF still has responsibility for the technical
specification of addresses and the policies that narrowly
implies; other policy issues, including the models for
allocations of addresses to those who will use them, belong to
others.  

I think it unwise try to define the boundary more precisely than
that.  You may recall that an attempt was made to do so more or
less unilaterally at the time the NRO was formed; in my opinion,
that didn't work out especially well for the Internet (YMMD).
If Jon were participating in this conversation today, I'm quite
sure that he would be saying that it is much more important for
the RIRs and the IETF to work together to get the best result
for the Internet rather than putting energy into trying to
legislate or enforce a boundary (whether that effort started in
the IETF or in the RIRs).

best,
   john

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Jan 2013 13:49:16 -1000

> If Jon were participating in this conversation today, I'm quite sure
> that he would be saying that it is much more important for the RIRs
> and the IETF to work together to get the best result for the Internet
> rather than putting energy into trying to legislate or enforce a
> boundary (whether that effort started in the IETF or in the RIRs).

can't speak for dr postel.  but this seems a responsible position.

randy

---

From: David Conrad <[email-masked]>
Date: Sat, 12 Jan 2013 16:19:43 -0800

John,

On Jan 12, 2013, at 2:21 PM, John C Klensin <[email-masked]> wrote:
> However, I don't think the
> another way to read it.  

As you know, there are many in both high and low places who choose the interpretation of 2860 that best fits their particular interests, regardless of the intent of that document (or, from personal experience, efforts to try to explain history or reality).  As such, I'll repeat: I do not believe it useful or helpful to go down that particular rat hole.

The more relevant bit:

> The IETF still has responsibility for the technical

I believe RFC 2050 does (and did) _not_ address "technical specifications of addresses", but rather documented (past tense) the then "best current practice" of policies associated with the operational deployment of those addresses for a short period around 1995 or so.

The Internet has moved on. The IETF still has the responsibility to define address technical specifications (e.g., an IPv6 address is 128 bits long), however I do not believe the IETF now has the responsibility to define operational deployment policy or processes (if it ever did).

As such, I think it perfectly appropriate to move RFC 2050 to "historic" since, in fact, it actually is.

> legislate or enforce a boundary

I doubt anyone rational would disagree with this, but I don't think that's the topic of discussion.  The issue, as I understand it, is that RFC 2050 is outdated and historic and its status should be made to reflect that truth.

Regards,
-drc

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 Jan 2013 16:34:10 -0800

On 1/12/2013 4:19 PM, David Conrad wrote:
> I believe RFC 2050 does (and did) _not_ address "technical
> specifications of addresses", but rather documented (past tense) the
> then "best current practice" of policies associated with the
> operational deployment of those addresses for a short period around
> 1995 or so.
>
> The Internet has moved on. The IETF still has the responsibility to
> define address technical specifications (e.g., an IPv6 address is 128
> bits long), however I do not believe the IETF now has the
> responsibility to define operational deployment policy or processes
> (if it ever did).
>
> As such, I think it perfectly appropriate to move RFC 2050 to
> "historic" since, in fact, it actually is.

The document's abstract declares the document's purposes to be:

    This document describes the registry system for the distribution of
    globally unique Internet address space and registry operations.
    ...
    This document describes the IP assignment policies currently used by
    the Regional Registries to implement the guidelines developed by the
    IANA. The guidelines and these policies are subject to revision at
    the direction of the IANA.

Unless I'm misunderstanding something, there's a simple issue here that 
should be resolved through a simple question:  Does the document still 
satisfy either of these purposes sufficiently and accurately.  My 
understanding from this thread (and elsewhere) is that the answer is no. 
  By definition, the document's role is therefore Historic and it only 
makes sense to make this official.

If there is content in the document that happens to still be useful, it 
should be extracted and published separately, so that no reader will 
suffer confusion and think that the remainder of the document remains 
applicable.

d/

ps.  A replacement document that /is/ sufficient to the current Internet 
would be a service to the community.

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Jan 2013 17:14:39 -1000

< vituperation >

> operational deployment of those addresses for a short period around

from this ops pov, the danvers meeting was where the ops and the irs met
to agree on the critical issue of sean's ags+s falling over, agree that
we would not filter on shorter than a /19 outside of swamp, and that the
irs would allocate no longer than /19.  that the ir folk then took it
and made a massive layer nine out of it was on your own heads.  the
american idiom is that chickens come home to roost.

> RFC 2050 is outdated and historic and its status should be made to
> reflect that truth.

made your bed, sleep in it.  maybe learn not to do it again?  nope.  the
irs keep on making massive and complex policy.  there were and are
alternatives http://www.apnic.net/policy/proposals/prop-103

we need bookkeepers.  we get wannabe regulators.  now we have wannabe
regulators who want to write the regulations completely outside of
coordination with the rest of the community.  oh goodie.

randy

---

From: David Conrad <[email-masked]>
Date: Sat, 12 Jan 2013 20:26:36 -0800

On Jan 12, 2013, at 7:14 PM, Randy Bush <[email-masked]> wrote:
> made your bed, sleep in it.  

Mea culpa, but it's time to get out of bed.

> maybe learn not to do it again?  nope.  

To be clear, I think RFC 2050 was helpful when it was published, however as I said, the Internet has moved on and I believe there are better venues in which operational policies for addresses can be developed. I figure it's called "best _current_ practice" for a reason.

> we need bookkeepers.  we get wannabe regulators.  

+1

> now we have wannabe

> coordination with the rest of the community.  oh goodie.

I don't believe moving RFC 2050 to historic implies the operational community efforts to develop policy is "completely outside coordination with the rest of the community". I would, in fact, be quite supportive of (and would even contribute to (if it would be helpful)) IETF input to ICANN/IANA on a replacement for RFC 2050. 

Regards,
-drc

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Jan 2013 19:01:23 -1000

< more vituperation >

>> we need bookkeepers.  we get wannabe regulators.  

and, as a friend pointed out, in sidr, we are arming them.  i try hard
to ameliorate this.  but that's another subject.

> I don't believe moving RFC 2050 to historic implies the operational
> community efforts to develop policy is "completely outside
> coordination with the rest of the community".

fwiw, i do not consider the irs to represent the operational community,
though they claim very loudly to do so.  they have coopted the space,
but, imiho, represent the interests of self-perpetuating organizational
fiefdoms far more than operators.  itu-t wannabes.

> I would, in fact, be quite supportive of (and would even contribute to
> (if it would be helpful)) IETF input to ICANN/IANA on a replacement
> for RFC 2050.

at russ's request (i did warn him of the poolpah), i tried to start a
2870 (dns root ops) bis with only one sentence added.

   2.7  Root servers SHOULD fully support queries and make corresponding
        responses with either IPv4 or IPv6.

the root ops private fiefdom rose up in objetion and non-cooperation
which has become their hallmark.

fighting fiefdoms is a waste of time.  the answer is to shut them the
hell down.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Jan 2013 20:55:56 -1000

> fighting fiefdoms is a waste of time.  the answer is to shut them the

a friend asked (to put it politely:-) me to clarify.

[ first, mea multi culpea, i helped start and/or served on the board (or
  equivalent) of a number of the organizations against which i rail.
  consider me the loyal opposition.  but i try, as we say, to work for
  the internet. ]

when people's livelihoods depend on an organization's existence, self-
interest is inevitable.  no blame, we're all just funny monkeys.  there
are no evil players here, just humans.  it's not their fault, it is ours
for creating and allowing it.

yes, we need the ir function fulfilled.  but i have become more and more
sceptical that we need six organizations doing it.  and organizations
with large staff.  we have built a privileged regulatory class.  when
you have a large building, half a dozen 'coffee ladies' on staff, or a
bunch of lawyers, then it's time for a revolution.

the ietf and nanog outsource out all services in arms' length contracts.
this has responsibility and accountability built in [0].  yes, all
organizations are self perpetuating, but i prefer the model where no one
is paid (directly [1]).

and i much prefer the ietf's nomcom model, which ameliorates the board
election game of the irs, nanog, etc, which are beauty contests and do
not serve the community well.  imiho, the beauty contests, the paid
fiefdoms, and the lawyers have led us from the bookkeeping model to the
regulatory.

randy

--

[0] - Accountability is something that is left when responsibility has
      been subtracted.  -- Pasi Sahlberg
[1] - http://archive.psg.com/051000.ccr-ivtf.pdf

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Jan 2013 08:18:14 +0000

I of course agree with Dave Conrad that current practice has changed
since 1996. FWIW I also fully agree with John. I think it is quite
possible to write a quite short update of BCP 12 that keeps the
technical points that are still valid and omits the policy points
that have been delegated to IANA. Maybe we should have done this
in 2000.

Regards
   Brian

---

From: Arturo Servin <[email-masked]>
Date: Sun, 13 Jan 2013 12:22:21 -0200

I agree that RFC2050 is not completely valid with the current state of
the Internet, but making it historic will not solve any problem IMHO.

	Before making 2050 historic, we should think what is and what is not
valid according with today's internet, what the technical community
needs to recommend to the RIR community and make a new document that
updates and obsoletes 2050.

Cheers,
as

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 13 Jan 2013 17:02:11 +0100

agree with Servin, to update 2050,

AB
+++

On Sun, 13 Jan 2013 12:22:21, Arturo Servin wrote:

Cheers,
as