[ppml] Revised Proposal -- Eliminate Lame Server Policy

[Owen DeLong]

On Sep 17, 2007, at 6:47 PM, Robert Bonomi wrote:

>
>> Date: Sat, 15 Sep 2007 08:51:04 -0700
>> To: policy at arin.net, Public Policy Mailing List <ppml at arin.net>
>> Subject: [ppml] Revised Proposal -- Eliminate Lame Server Policy
>>
>> Based on discussions with the AC Shepherds and input received on the
>> mailing list, I am revising my Lame Server proposal.
>
> I generally support the intent of this proposal.
>
> I have two minor linquistic quibbles with the specific words used,
> plus one substantive issue with the wording, as indicated below.
>
>
>> 1.	Policy Proposal Name: Deprecate Lame Server Policy
>>
>> 7.	Policy statement:
>> 		Replace Section 7 of the NRPM in it's entirety with the
>> 		following text:
>>
>> 	7.	Staff action to improve ARIN public database accuracy and
>> 		consistency.
>
>
> Linguistic quibble:
>   'Action to improve' implies that there are other "initial"  
> actions being
>   taken with regard to `accuracy'/'consistency'.  Of which there is no
>   mention, anywhere.
>
Not at all.  Action to improve implies that the existing accuracy of  
such
databases has room for improvement which requires action.

> Fix:
>   Substitute: "actions with regard to" for the suspect phrase.
>
The problem with this is that it allows for actions whether they improve
or degrade the database.  Clearly, the intent of the policy is to  
improve
the accuracy of the databases, and, as such, I think that preserving
the existing wording is preferable.

>>
>> 		7.1	ARIN staff shall take reasonable and practicable means to
>
> Linguistic quibble:
>   '... shall take ... means to ..." is improper usage.
>
> Fix:
>   use one of --
>   "... shall employ ... means to ..."
>   "... shall take ... steps to ..."
>   or similar
>
I'll take your word for it, and, I have no issue with any of the
choices presented.

>> 			ensure and improve the accuracy of all ARIN public
>> 			databases, including, but, not limited to WHOIS,
>> 			delegations of the in-addr.arpa zone, and, delegations
>> 			of the ip6.arpa zone.
>
> Issue:
>   A) The above language is unclear as to the scope of ativities  
> that staff are
>      expected to undertake.
>      There are at least three separate 'relevant' senarios;
>        1) at time of resoure allocation/assignment
>        2) when a complaint of an 'error' is  received,
>        3) staff-initiated "compliance checking"

Yes.  The intent is to move these decisions out of the public policy  
process
and place them where they belong in the staff operational procedures
domain.  As such, it is fully expected that this policy would result  
in the
development of several operational guidelines by the ARIN staff and
management to implement the policy in each of those areas mentioned.

>   B) _If_ staff-initiated testing is included in the scope of  
> activities,
>      there needs to be a parallel  "operations" suggestion as to  
> the basic
>      parameters for that testing -- e.g., how frequently sweeps  
> should be
>      run, how fast something that fails an initial sweep should be  
> re-tested,
>      how long a problem must persist before it is considered an  
> "error"
>      requiring action, etc., etc.
>
Yes... There are already some of these going through the ACSP, and,
I expect there will be more, both ACSP and Staff initiated.

> Discussion:
>   1) 'to ensure ... accuracy' clearly implies that some  
> verification must be
>      done at the time of origial allocation/assignent.
>   2) '... improve the accuracy of..." clerly implies that some  
> investigationn
>      is called for when a valid complaint is received.
>      NOTE: is it appropriate _somewhere_ to set minimum  
> requirements for what
>      constitutes a 'complaint'?  Something like "5 consecutive  
> failures within
>      a 1 week period, with minimum of 12 hours between any two  
> checks"?
>   3) Pro-ative checking is clearly authorized under this language.   
> It is not
>      clear if the intent is to (a) mandate, (b) recommend, but not  
> require,
>      or (c) merely 'allow for the possibility of' (as in 'when  
> staff has
>      nothing better to do with their time.')
>
Heh... Spelling quibble:  I presume you mean Pro-active checking.

All of the above are intended.  As to the specifics of item 3, it is
intended to be somewhat left to the discretion of staff and management
to implement the best process based on community input and
knowledge of the situation.  If the community feels that staff needs
additional direction in this area, the ACSP is an excellent tool
to further fine-tune the process.

> Suggestion:
>   1) Proposed NPRM 7.1 be modified to explicitly list all the above- 
> mentioned
>      scenarios as being with the scope of this policy.
>
>   2) the acompanying 'operational' guidelines specifies:
>      a) that staff MAY perform pro-active checks at will, and  
> SHOULD do so at
> 	least quarterly.  (Rationale: staff is free to act agressively, while
> 	setting 'minimum' standards.)
>      b) that testing SHALL origiate from several 'unrelated'  
> locations within
> 	the ARIN region. and that any test must fail from all such points,
> 	before it is concluded that that test failed.  (Rationale: to prevent
> 	network connectivity issues from being mistaken as database issues.)
>      c) that a failed test SHALL be repeated daily, until it has  
> failed on 5
> 	consecutive attempts.  After 5 consecutive failures, it is deemed to
> 	be an 'error', calling for corrective ation to be taken.  (Rationale:
> 	to prevent 'short-term, transient' problems from being mistaken as
> 	database issues.)
>      d) that an 'externally generated' complaint of a database  
> fault SHOULD
> 	show at least 5 failed queries over a period of a week or more, with
> 	at least 12 hours between any 2 attempts.  (Rationale: To reduce the
> 	liklihood of external complaints being the result of 'short-term,
> 	transient' problems, rather than being actual database errors.)
>      e) that in-addr.arpa and ip6.arpa delegation checking is  
> limited to zones
> 	that are a top-level component of an ARIN allocation/assigment.
> 	e.g., for a /14, staff checks only the 4 constituent /16 zones.
> 	If the /16 has been delegated to a customer, it _is_ still checked.
> 	Secondary zone delegations -- e.g., in this case, customers who are
> 	delegated 1 or more /24s -- are _not_ checked.  (Rationale: It is the
> 	task of the zone owner to police sub-delegations.)
>     NOTE: "Somewhere" it will be necessary to specify an objective  
> standard
>         test for determining/establishing access.
> 	E.g., for a 'whois' contact, is it sufficient to verify that there is
> 	functioning mail exchanger for the domain named, and that it responds
> 	'2xx' to a RCPT TO for the given address, or does one actally need to
> 	send e-mail to the address, and make sure that it was delivered/
> 	received. (something similar to the closed-loop confirmation process
> 	used by various mailing lists.  e.g., for rDNS, do _ALL_ the  
> responding
> 	nameservers have to return the same authoritative information for  
> that
> 	zone, or is it sufficient for _one_ of them to do it?  Does the zone
> 	need to contain _any_ PTR records, or is a SOA, with at least 2 NS
> 	records sufficient?
>
Yes.  It is the firm belief of the author that all of this belongs  
squarely in
the hands of the staff and management at ARIN and the should this policy
be adopted, such documentation would be forthcoming within a reasonable
time. Further, the author believes that the ACSP provides a sufficient
mechanism for the community to provide additional guidance to staff.
The author does, however, believe that such operational guidelines need
to be published and that ARIN does not currently have a good mechanism
for doing so.  Author is, in parallel working with ARIN in hopes of
creating such a framework, but, this work is outside of the IRPEP.

This is definitely _NOT_ a fire-and-forget policy.  It is an attempt  
to move the
focus of these efforts to the ACSP and ARIN staff while allowing the  
process
to be improved without the full weight and overhead of the IRPEP for  
every
detail.  The intent being to facilitate better and more responsive  
action by
ARIN staff in all of the above cases rather than to in any way reduce  
any
such existing efforts.

Owen