John, On Feb 5, 2011, at 8:47 PM, John Curran wrote: > On Feb 6, 2011, at 1:25 AM, David Conrad wrote: >> Last I checked, the other four authors of RFC 2050 are still alive. Why not >> ask them? > Bill indicated he "was there when it was written" in reference to Jon being > an > author, and I was inquiring to whether he had any knowledge of Jon's intent > that > he could share. If you have knowledge of Jon's intent, or any insight on why > RFC > 2050 includes the existing allocations if the intent was actually to leave it > vague > with respect to same, that also would be helpful.
As you're aware, RFC 2050 was a group effort, so focusing on Jon's intent seems questionable particularly given he sadly isn't around to provide corrections. My recollection is that all of the authors recognized that attempting to deal with what is now known as legacy space was _extremely_ controversial and was wildly unlikely to have reached any consensus, particularly in the context of how the IETF works and the then ongoing battles regarding CIDR deployment and its implications. Instead, we consciously focused on merely trying to document the then current practice for allocations and assignments. Even that turned out to be a prolonged nightmare, especially trying to get it through the IESG (which discouraged further attempts at trying to use the IETF to derive addressing policy). In other words, since RFC 2050 merely attempted to document then current practices, it intentionally did not address (pun intended) allocations made prior to the establishment of those practices directly. Rather, it merely noted that future allocations or assignments would take existing holdings into account. With regards to specific language, you reference section 2.1.1. You'll note that this is in a section talking about guidelines for how ISPs should deal with address space. It is saying ISPs should treat assignments to their customers like loans. Section 2.1.3 is talking about two different things as indicated by the terminology used. The "future _allocations_ may be impacted" is talking about allocations made from the RIR to the ISP. The "existing _loans_ may be impacted" is saying the RIR could ignore assignments the ISP has made to its customers (making it a bit difficult for the ISP to get new space). >>> Further, RFC 2050 states "The transfer of IP addresses from one party to >>> another >>> must be approved by the regional registries. The party trying to obtain >>> the IP >>> address must meet the same criteria as if they were requesting an IP >>> address >>> directly from the IR." >> >> I'm curious: when HP acquired the assets of Compaq (or when Compaq acquired >> the assets of Digital), is it your position that HP (or Compaq) "met the >> same criteria as if they were requesting an IP address directly from the >> IR." for 16.0.0.0/8? > > The handling of general case varies based on the community developed > policy over the years, [...] but will note that at one > time the M&A transfer policy allowed transfer of all held number resources > without justification of need as long as the entire entity was involved, > but at this point the policy indicates that [....] So, if you believe ARIN policy applies to all space, you're saying that ARIN at one time violated the section of RFC 2050 you quoted and that later, ARIN changed that policy. This sort of policy evolution is exactly what was envisioned when we wrote RFC 2050. We assumed policies would change over time, and as such RFC 2050 was merely documenting the current practice as it was in 1996. This is why I always find your referencing 2050 as if it is sacred text curious. In thinking about this, since RFC 2050 was focused on IPv4 allocation policy and there is no more IPv4 to allocate, 2050 should probably be moved to historic. Regards, -drc
