[136925] in North American Network Operators' Group
Re: "Leasing" of space via non-connectivity providers
daemon@ATHENA.MIT.EDU (David Conrad)
Sun Feb 6 14:16:38 2011
From: David Conrad <drc@virtualized.org>
In-Reply-To: <585A8651-6C2E-4B16-9D03-6C756CC9E77D@arin.net>
Date: Sun, 6 Feb 2011 09:16:09 -1000
To: John Curran <jcurran@arin.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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?=20
> Bill indicated he "was there when it was written" in reference to Jon =
being an=20
> author, and I was inquiring to whether he had any knowledge of Jon's =
intent that=20
> he could share. If you have knowledge of Jon's intent, or any insight =
on why RFC=20
> 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=20
>>> must be approved by the regional registries. The party trying to =
obtain the IP=20
>>> address must meet the same criteria as if they were requesting an IP =
address=20
>>> directly from the IR." =20
>>=20
>> 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?
>=20
> The handling of general case varies based on the community developed=20=
> 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,=20
> 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
