[ppml] Policy Proposal -- Eliminate Lame Server policy

[Owen DeLong]

On Sep 11, 2007, at 3:22 PM, Edward Lewis wrote:

> At 14:10 -0700 9/11/07, Owen DeLong wrote:
>
>> 8.	Rationale:
>> 		Recent PPML discussion has called attention to the
>> 		fact that lame DNS delegations are more an operational
>> 		issue than one of policy.  As such, the existing lame
>> 		delegation policy should be removed from the NRPM
>> 		to remove the resultant confusion.  This is not meant
>> 		to prevent ARIN staff from taking reasonable action
>> 		WRT DNS operational issues related to resources issued
>> 		by ARIN, but, such action can be covered by staff
>> 		operational guidelines and is not within the scope
>> 		of Address Policy.
>
> Hmmmm. Mmmmmmmmm.
>
> First I want to ask for a definition of the "scope of Address  
> Policy."  I have a vague idea, I gather it refers to IPv4 address  
> ranges, IPv6 address ranges, and Autonomous System number(s).   
> (It's that I don't think of AS numbers as addresses; I usually  
> refer to the triad of parameters as IP numbering resources.  Okay,  
> okay, splitting terminology hairs here, what I'm asking for is a  
> pointer or statement about the scope.)
>
I suppose I should have said "Number Resource Policy".  I suppose  
there isn't really
much in the way of a pointer about scope that I can give you.   
However, it is my
opinion that the responsibility and scope of ARIN policy should be  
limited to
the assignment and delegation of number resources.  Operational  
concerns about
routing and DNS are, in my opinion outside of that scope and only  
serve to muddy
the waters of good number resource policy.

> I may or may not agree that the lame delegation "policy" should be  
> excluded from the NRPM.  I am unsure about that.
>
Understood.
> What I would be against is dropping any membership requirement on  
> the staff to enforce clean health (lexically stretching "lameness")  
> on the DNS systems operated by ARIN.  I think it is incumbent upon  
> ARIN not to refer DNS traffic to servers which answer "incorrectly."
>
I have no problem with that as a general procedure, but, that's a  
procedural
and operational question and not what I would consider to be number  
resource
policy.  Certainly such a consideration could go well through the  
ACSP and
I would even support such a suggestion.

> I could argue that (all?) IP address allocation policy is an  
> operational consideration.  Poor address allocation policy would  
> cause an undue burden on the routing system.  E.g., what if we only  
> gave a (IPv6) /48 to LIRs each time the asked regardless of need  
> and wound up with highly fragmented allocations?  I'm being silly  
> here, to stress the point that I disagree that with the criteria of  
> being an operational issue means removal from the NRPM.
>
Sure, but, not all operational considerations are IP address  
allocation policy.
Operational considerations are a superset of IP address allocation  
policy.
Actual operations, operational tactics, and operational requirements and
standards are not, however, number resource policy.

As to fragmented allocations, I'm not 100% convinced that's a bad thing.
While I agree that we should do what we can to reduce the degree to  
which
we fragment things in order to accommodate limitations of today's  
routing
system, I firmly believe that our rather high degree of success in  
doing so
has been one of the factors in our failure to develop a workable and
scalable routing system.

So... I don't advocate going out and fragmenting for the sake of  
fragmenting,
but, I do think that we should stop basing policy on concerns over  
routing
table growth, and, instead manage policy based on rational allocation
and assignment concerns.  ISPs who run routers should take the  
responsibility
for the operational concerns of routing table size.

> Still, I am not necessarily against what is proposed here.  I'm  
> just saying I have questions for now, but I don't want to see this  
> lost.
>
Yep... Understood.

> I don't want sloppy servers.
>
Neither do I, but, I am not convinced that it is ARINs place to  
attempt to
force or even pressure others to clean up their sloppy servers.

Owen