[ppml] Policy Proposal 2005-3: Lame Delegations

[Glenn Wiltse]

   That is all well and good... and quite frankly I personaly appreate the
discussion that just took place... as it attempted to answer my question
to Why? Why is any of this effort to get rid of lame delegation nessasary.

 Now that I've got the answer(for the most part) and also done further
research on my own. I think the policy proposal is full of problems and I
would not support it at this time.

 I'll try to sumerise what I find objectionable and/or confused
by... (with regard to the proposal itself)

 First off, we are told that lame delegations are a problem, and
there needs to be action taken to correct it. I'll accept that there
at least is the potential for overloded servers by just leaving lame
delegations alone, however I see no data that would indicate exactly
how big a problem it is.

 Next we are asked by the AC to get rid of the current procedures
for contacting the people responsible for the servers that are suposed
to be lame. The reason we are asked to remove the details of the
procedures for contacting these people, is because ARIN staff apparently
don't have time to do it all. Yet we aren't told what parts of the current
procedures are taking up all the time. We also have been given no data
to indicate how much time is currently spent in trying to eradicate
lame delegations.

  For now, lets just consider those two points... We don't know how
big of a problem lame delegations are in terms of server load and we
don't know how much time is spent trying to get rid of lame delegations.
All we know is that ARIN staff apparently is unable to keep up with
the current methods for getting rid of the lame delegations. For all
I know, it might be a better use of ARIN resources to beef up the
servers.

  So, aside from not having enough information to make a wise choice
on the above to points...

  I think it's important there be clear statements about the steps
that will be taken before deleting a lame delegation. I'm no lawyer
but I would think that there could be some liablity issues involved
if you simply start removing delegations to the in-addr.arpa space
without clearly stating the policy and procedures. With the current
policy, at least there is clear wording that describes how the attempted
contacts will proceed, and how long ARIN will wait before deleting
a 'lame' delegation. While eliminating this wording may help ARIN staf,
it's not clear it helps ARIN customers much.

  I also don't like that nether the current or proposed policys would
be clear as to wether a whole CIDR blocks worth of delegations will
be droped when there may only be one portion of that block being actualy
lame...

  Well I said I was going to sumerise this... I haven't made much
progress in doing that yet...  but I guess as close as I can get is...

I can not support the "Policy Proposal 2005-3: Lame Delegations" since
I see numorious flaws with it. I also have virtualy no data that would
help me make an informed decsion about this proposal.

Glenn

On Thu, 14 Apr 2005, Azinger, Marla wrote:

> 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.
>
> !DSPAM:425e98c0129051373527317!
>
>