[ppml] Revised Proposal -- Eliminate Lame Server Policy

[Dean Anderson]

This is the tail wagging the dog.  I think that operations should
implement the policies, not the other way around.  I have to say that I
am greatly concerned by the nature of this notion that "operations will
do whatever it wants", in spite of policy. Historically, ISPs have 
separated engineering from operations so that engineering designs the 
network and makes the policy while operations supervises the craftpeople 
and implements the policies and the design.  Allowing operations to 
operate unsupervised is, and has been proven to be, a very poor 
decision.

1. That "motivating problem" for this discussion as Scott Leibrand
succinctly summarized it, is at best a corner condition.

> ARIN's current operational policy requires that all zones for a given
> registration be lame before considering the registration lame, and
> triggering the notification and removal process.  If a registrant gets
> a /22, and only sets up reverse DNS for one /24, ARIN does not take
> action against the other three zones (/24's).  This seems to be an
> artifact of the fact that you define a single set of DNS server per
> registration, not per zone (/24, /16, or /8), so ARIN only takes
> action at the level of the registration, not the level of the zone
> (where the problems actually arise).

While there has been a lot of talk about what ARIN should do in this
case, no one has presented any evidence that there is any actual harm,
nor that that harm is so great that policy must be changed. Nowhere is
there is a reason that operations in this case is so difficult that it
should simply be entirely free of policy constraints.

There is no compelling reason for the change in policy.  


2. Removing Section 7 also changes the compliance with RFC2050 and
impacts agreements with IANA, ICANN, DoC which mention RFC2050.

There are additional impacts which have not been examined.


3. It is entirely possible within the existing policy, to remove the DNS
delegation for a subset of zones of an Address block assignment. It is
only the registration software that limits one set of nameservers for
all zones, and the ARIN DNS zone generation software that has this
limitation.  It is not section 7 of the policy manual that requires 'all
zones for a given registration be lame' before removing an in-addr
delegation, but rather limitations in the operations tools used to
implement policy.  There is no such language in section 7.2.

There is no need to change the policy manual.


Therefore, I think this policy should be not be adopted. 

Dean Anderson
Av8 Internet, Inc



On Sat, 15 Sep 2007, Owen DeLong wrote:

> Based on discussions with the AC Shepherds and input received on the
> mailing list, I am revising my Lame Server proposal.
> 
> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
> 
> 1.	Policy Proposal Name: Deprecate Lame Server Policy
> 2.	Author
> 	a.	name: Owen DeLong
> 	b.	email: owen at delong.com
> 	c.	telephone: 408-921-6984
> 	d.	organization: JITTR Networks
> 
> 3.	Proposal Version: 2.0
> 4.	Submission Date: 11 September, 2007
> 5.	Proposal type: modify
> 	new, modify, or delete.
> 6.	Policy term: permanent
> 	temporary, permanent, or renewable.
> 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.
> 
> 		7.1	ARIN staff shall take reasonable and practicable means to
> 			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.
> 
> 8.	Rationale:
> 		Recent PPML discussion has called attention to the
> 		fact that lame DNS delegations are more an operational
> 		issue than one of policy.  As such, the existing lame
> 		delegation policy should be removed from the NRPM
> 		to remove the resultant confusion.  This is not meant
> 		to prevent ARIN staff from taking reasonable action
> 		WRT DNS operational issues related to resources issued
> 		by ARIN, but, such action can be covered by staff
> 		operational guidelines and is not within the scope
> 		of Address Policy.
> 
> 9.	Timetable for implementation:
> 		1 June, 2008
> 10.	Meeting presenter: Owen DeLong
> 
> END OF TEMPLATE
> 
> _______________________________________________
> 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.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000