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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Brian,

On Jan 12, 2013, at 1:36 AM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote:
> I object to making RFC 2050 historic without retaining at least the
> 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?

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

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.

> An update of RFC 2050, within the scope set by the IETF-IANA
> 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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]