"It's the end of the world as we know it" -- REM

Jimmy Hess mysidia at gmail.com
Wed May 1 05:36:32 UTC 2013


On 4/30/13, Owen DeLong <owen at delong.com> wrote:

> With all due respect, this is a reference in section 8.3 to call out that
> the policies in section 4 regarding qualification of recipients are to be
> followed when determining eligibility for an 8.3 transfer.

I don't read a reference to section 4 there.  don't think it's a
reasonable belief, that a network operator supplicating for transfer
of IPv4 resources,  would come to this conclusion -- there is no
reason to select a specific section to apply because no section is
mentioned,
reading the policy on their own, and  what you are seeing there -- may
be a result of
bias from your prior exposure to another interpretation of the language.

Its also possible, that all of us who were reviewing the proposed
transfer policy language read some rationale statement at one time or
another, and just (incorrectly) assumed that the final language
accomplished our intended effect.


I don't think this issue should effect any network operators at this
time, but nonetheless i'm concerned about the RIR policy having
confusing, surprising, or hidden ramifications built into it,  which
are problematic and not previously considered.


> I would suggest that considering the expressed intent of the policy is more
> useful than attempting to nit-pick the most nonsensical possible

I looked at the intent of the policy specifically, and it seems pretty obvious
that 4.2.2.1.1 and  4.2.2.1.3   very clearly do not  intend that they
apply to transfers,
or other situations where a /20 is not involved.

If 8.3 says the current policy applies, then,  that by definition
imports also the intent and scope restriction in the other sections of
the policy,  not just the procedures or rules.


Specific evidence of intent from 4.2.2.1.1 quote:  " if an
organization holds a smaller allocation, such as 12 /24s, from its
upstream provider, the organization would not meet the minimum
utilization requirements of a /20."

Furthermore, the 8.3 transfer rule specifically states that the minimum is /24.
And the stated requirement is demonstrated need,  not "whatever
constraints apply to other kinds of allocations/assignment".


When the interpretation is intent, with these two statements taken
together, we have here, a contradiction between the acceptance of a
/24 that can only be resolved by refraining from applying 4.2.2.1.1
and 4.2.2.1.3, or the antecedent is false  (you're not requesting a
/20,  so it follows that you don't need to meet the minimum
utilization requirements of a /20).


There _is_ a reasonable demonstrated need criteria,  in 4.2,   that
could apply to transfers; though, it's 4.2.3.    Reassignment of
address space...


The characterization of the transfer recipient as a "customer"  for
reassignment purposes,  seems less-problematic than the
characterization of a /24 as a /20,  for imposing  4.2.2.1.1 ,
and carries no  requirement for a prior upstream assignment.

> That is the express intent of that clause in the rationale and according to
> the authors during discussions of the policy text prior to its adoption.

My expectation about 8.3 is that justification is still to be
required.   But not the application of  /20 justification criterion to
a /23 or smaller.

Also,  i'm not sure what bearing the author's intent may have,  as a
policy document has to be able to stand on its own,  and  different
members of the community,  may aparently have had a different
understanding of some of the ramifications of the language.

If the language doesn't convey the intent in a clear, at least
discernible way,  that can be shown through sufficient evidence in the
document, then the supposed intent may as well not exist:   I mean,
it's like saying the developed policy didn't matter   "just the
author's intent"?.

> 4.1 provides only general principles. In and of itself it is not a complete
> set of policies. In addition to the guidance provided by 4.1, one must qualify
> under 4.2 if one is an ISP/LIR or 4.3 if one is an end-user. There are
> exceptions provided in 4.4 et. seq. for certain special cases.

Yes;  i'm not sure,  what,  if any relevance these distinctions really
have or ought to have, with transfers, and a minimum size of /24, and
/23s allowed as well, however.


And I sure don't expect applicants for transfer applicants to sort all that out;
the policy should be more explicit,  and have conditions to clearly
apply to the situation.

-- 
-JH




More information about the NANOG mailing list