[ppml] Revised Proposal -- Eliminate Lame Server Policy

> 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.

Fix:
  Substitute: "actions with regard to" for the suspect phrase.

>
> 		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

> 			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"
  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.

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.')

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?