[ppml] New RFC about inaddr-arpa PTR records

I did not agree with this draft. This draft has actually been in the
DNSOP WG for 7 years.  This is not the '5th' draft, but rather the 5th
draft with that name.  The original draft was submitted in 2000 under
the name 'inaddr-required' (google inaddr-required and in-addr-required)  
Almost no one agrees with the premise that in-addr should be required.  
The authors repeatedly made assurances that they "did not mean that
in-addr would be required", but the text of the draft continued to work
in the requirement implicitly or explicitly, despite continuous and
widespread objections to this.  Finally, they were forced to change the
name to eliminate the implication that in-addr would be required.  We
are now on the 5th revision of the re-named draft.

However, the current draft still contains a number of false statements
and false implications, and misleads people to think that in-addr is
required and improves security, etc.  Many people on the WG don't
believe that in-addr should be required. Every time someone complains
about the implication of the draft that in-addr is required or that the
draft implies that in-addr improves security, etc, the authors make
gratuitous changes to the wording, announce that they have 'addressed
the concerns', and try again, without changing the meaning.

They have also changed the draft type to 'informational' in an attempt
to address charges about lack of facts and the discredited claims
contained within the draft. Documents in the IETF 'informational'
category doesn't need to be 'true' in any scientific sense. But most
people, and particularly most system administrators, don't know the
difference.

Frustrated by the continuing willfull attempts to assert and imply that
in-addr is required and other false claims in the draft, I authored a
draft with true statements on the status of the in-addr system, and
which debunked certain claims. My draft informs readers about the status
and good practices of the reverse dns system.  My draft can be found at

http://www.ietf.org/internet-drafts/draft-anderson-reverse-dns-status-00.txt

At present, no one participating in the DNSOP WG was interested in
considering my alternative draft. This gives a good idea of who
participates in the DNSOP WG---reasonable people need to participate in
DNSOP WG!

I'll probably publish my document elsewhere as a technical report. It
might make a good magazine article.

		--Dean

On Thu, 13 Sep 2007 michael.dillon at bt.com wrote:

> How many of you who have commented on the in-addr.arpa issue, have read
> this draft?
> 
> http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-consideratio
> ns-05
> 
> As you might guess, by the number 05 at the end, this is the 5th version
> of the draft and is getting pretty darn close to becoming a published
> RFC. 
> 
> If your suggestions for new ARIN policy, or for ARIN operational
> procedures, do not agree with some part of this draft, you might want to
> contact the author or join the DNSOP working group here
> http://www.ietf.org/html.charters/dnsop-charter.html
> 
> I note that the word "lame" does not appear in the above draft.
> 
> -------------------------------------------------------
> Michael Dillon
> RadianzNet Capacity Management, 66 Prescot St., London, E1 8HG, UK
> Mobile: +44 7900 823 672 
> Internet: michael.dillon at btradianz.com
> Phone: +44 20 7650 9493 Fax: +44 20 7650 9030
> http://www.btradianz.com
>  
> One Community One Connection One Focus 
> 
> _______________________________________________
> 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