[ppml] Is this Lame or what?

LOL.  I understand your point about research...but there is value in the postings.  Eventually it should progress toward clarification to all.  And I do believe from all the confusion the current written text has caused, that some clarification is needed.  Be it policy, definitions clarified or just staff process clarification publicly posted somewhere.  There is clearly some work to be done here in order to minimize confusion and/or resolve something that seems to be not fully baked.  And you might have also noticed how many different views surrounding the whole topic are out there...so the discussion in my view is good. Is daunting and does it add to more ppml to read? yes.  But...that is how we keep the process open and able to change if the community realizes later on down the road that they do or dont like what currently is written as policy or process.

Cheers!
Marla


-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Scott Leibrand
Sent: Tuesday, September 11, 2007 4:49 PM
To: Member Services
Cc: Public Policy Mailing List
Subject: [ppml] Is this Lame or what?


After doing some research (which I highly recommend everyone do before 
posting), I'm not sure any policy changes are needed to deal with the 
two specific cases raised so far.

ARIN's Lame Delegations page at 
http://www.arin.net/reference/lame_delegations.html states that "ARIN 
tests a reverse zone by requesting the SOA (Start of Authority) record 
from the name servers registered in WHOIS. ... Any other answer (or an 
inability to reach the nameserver due to a forward lookup failure) 
results in the delegation being deemed lame. If all of zones for a given 
name server of a specific network registration are lame, the delegation 
registration is deemed lame."

The way I read that, the fact that the authoritative servers for 
160.76.in-addr.arpa., 161.76.in-addr.arpa., and 64.114.208.in-addr.arpa. 
through 95.114.208.in-addr.arpa. do not respond to queries qualifies 
them as lame.  Under ARIN's own policy, that further means that "After 
30 consecutive days of lameness, ARIN notifies the points-of-contact of 
record via e-mail." and then if they get no response and it's not fixed, 
"After 90 consecutive days of lameness, ARIN strips the lame delegations 
from the WHOIS registration record and notifies the points-of-contact of 
record of the actions taken."

Can anyone from ARIN comment as to whether they share my interpretation 
that a non-responsive name server is deemed lame, and subject to removal 
under the procedure outlined above?

Thanks,
Scott

Azinger, Marla wrote:
> I would like to see a proposal that is along the lines of clarifying in addition to Owens proposal to just take it away.  Hopefully we havnt scared John off and he will give a wack at it.
>
> Cheers!
> Marla
>
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
> William Herrin
> Sent: Tuesday, September 11, 2007 3:32 PM
> To: Owen DeLong
> Cc: Public Policy Mailing List
> Subject: Re: [ppml] Policy Proposal -- Eliminate Lame Server policy
>
>
> On 9/11/07, Owen DeLong <owen at delong.com> wrote:
>   
>> 1.      Policy Proposal Name: Deprecate Lame Server Policy
>> 7.      Policy statement:
>>                 Delete section 7 from the NRPM
>>     
>
> Owen,
>
> Are you sure this is the right way to move on this? If we're going to
> call ISPs "Local Internet Registries," shouldn't we expect them to
> behave as internet registries and do the things that internet
> registries do, including reallocation and assignment of the RDNS
> attached to every IP address?
>
> Regards,
> Bill Herrin
>
>   
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.