[ppml] Policy Proposal 2005-3: Lame Delegations

[Azinger, Marla]

I must say there has been alot of good informative debate on this policy.  

However, I hope everyone realizes that the Lame Delegation Policy "meaning" itself is not what this policy proposal is about.  The only reason this proposal is in front of the community is to ask permission to deviate from the strict "notification" guidelines that were included within the original approved policy.  ARIN staff will continue to carry out this policy as written...they just need some breathing room to work the notification process as fit per customer.

This proposal is ONLY a modification to the "notification" part of the policy.

That said...if anyone should choose to suggest changes to the actual Policy and its "meaning" then I urge you to bring it up seperately at the open sessions so that your concerns get heard and evaluated.  AND so that we do not bog down our proposal to "modify" the "notification process" within the policy.

Thank you
Marla Azinger
Electric Lightwave

-----Original Message-----
From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On Behalf Of
Edward Lewis
Sent: Wednesday, April 13, 2005 3:49 PM
To: David Conrad
Cc: Paul Vixie; ppml at arin.net
Subject: Re: [ppml] Policy Proposal 2005-3: Lame Delegations


At 12:19 -0700 4/13/05, David Conrad wrote:
>On Apr 13, 2005, at 11:11 AM, Paul Vixie wrote:
>>>  Why?  Why is this nessasary? If someone's got their in-addr.arpa stuff
>>>  broken, it's not really hurting anyone but themselves. Seems like this
>>>  is a waste of ARIN resources to me.
>>  i don't agree.  bad or missing in-addr.arpa or ip6.arpa data hurts us all.
>
>While I do not necessarily disagree, can you expand on why you believe lack of
>reverse information hurts us?

I see Paul has answered this, but I think that there's a non-sequiter here.

The lame delegation policy is meant to trim bad referrals from an 
ARIN managed name server to a supposedly running server that is not. 
The point isn't the worthiness of the reverse map at all - the point 
is the health of what is there.

Paul's "bad or missing" - IMHO - refers to data incorrectly stating 
that DNS is running on a system and/or "missing" servers, not to the 
presence or absence of "name servers on a network block."

Incorrect referrals have induced some DNS implementations to overly 
burden the root servers (and others).  Partly to blame is the 
convention of a name server, in claiming lameness, is to refer the 
requestor back to the root.  Unwary implementations would loop 
forever.  Wary implementations that just won't take an intermediate 
"no" for an answer keep pounding away too.  Such observations led to 
the original lame delegation policy.

As someone who lives and breathes DNS, I can't imagine why a network 
operator wouldn't have at least a stub zone for their address range 
mostly because it's so trivial to set up and some DNS-using 
applications expect there to be something.  But I won't go so far as 
to say that the reverse map is mandatory.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.