[ppml] Revised Proposal -- Eliminate Lame Server Policy
Robert Bonomi
bonomi at mail.r-bonomi.com
Mon Sep 17 21:47:22 EDT 2007
> 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?
More information about the ARIN-PPML
mailing list