[136930] in North American Network Operators' Group
Re: "Leasing" of space via non-connectivity providers
daemon@ATHENA.MIT.EDU (John Curran)
Sun Feb 6 14:53:37 2011
From: John Curran <jcurran@arin.net>
To: David Conrad <drc@virtualized.org>
Date: Sun, 6 Feb 2011 19:53:17 +0000
In-Reply-To: <57B939FE-3B74-4B70-8AD5-71176551C2BF@virtualized.org>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Feb 6, 2011, at 2:16 PM, David Conrad wrote:
>=20
> 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 cor=
rections.
While it may have been a group effort, Jon was the IANA.
> With regards to specific language, you reference section 2.1.1. You'll n=
ote 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 the=
ir customers like loans. Section 2.1.3 is talking about two different thing=
s as indicated by the terminology used. The "future _allocations_ may be i=
mpacted" is talking about allocations made from the RIR to the ISP. The "e=
xisting _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 t=
o get new space).
Interesting viewpoint in separating the two, as the full context is:
"If the information is not available, future allocations may be impacted.=20
In extreme cases, existing loans may be impacted."
Your suggestion that "existing loans may be impacted" means to be ignored=20
for evaluating future allocations does seems a bit superfluous when taken=20
in full context, but obviously must be considered as you are one of the=20
authors. One wonders why it just doesn't repeat "future allocations may=20
be impacted" for the second sentence.
Do you have any similar suggestions for how to reinterpret the transfer=20
section, i.e. " The transfer of IP addresses from one party to another
must be approved by the regional registries." or "The party trying to=20
obtain the IP address must meet the same criteria as if they were=20
requesting an IP address directly from the IR." ?
> So, if you believe ARIN policy applies to all space, you're saying that A=
RIN 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 w=
as envisioned when we wrote RFC 2050. We assumed policies would change ove=
r 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 i=
s sacred text curious.
It's fairly difficult to have a consistent global registry framework
that the regional registries operate under unless its actually followed
by the regional registries. What would have been best would have been
to separate the document into two; one for the overall Internet Registry=20
requirements technically necessary, and then one with the current view
on appropriate allocation policy. I wasn't there, so I can't say why
the two are combined.
In the particular instance you point out, I'm happy to say ARIN is back
in alignment with RFC 2050 as written.
> In thinking about this, since RFC 2050 was focused on IPv4 allocation pol=
icy and there is no more IPv4 to allocate, 2050 should probably be moved to=
historic.
It certainly would be worth considering revising to maintain the=20
portions which are an inherent technical requirements from IAB/IETF
versus those which are a snapshot of registry policy at the time.
It also is interesting to consider which forum(s) such an activity=20
should take place in, since it's clear that an overall framework=20
is necessary for the system to keep working globally.
/John
John Curran
President and CEO
ARIN
