Subject: [dnsop] I-D ACTION:draft-ietf-dnsop-inaddr-required-05.txt

From: [email-masked]
Date: Mon, 26 Apr 2004 15:26:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group of the IETF.

	Title		: Requiring DNS IN-ADDR Mapping
	Author(s)	: D. Senie
	Filename	: draft-ietf-dnsop-inaddr-required-05.txt
	Pages		: 5
	Date		: 2004-4-26
	
Mapping of addresses to names has been a feature of DNS. Many sites,
implement it, many others don't. Some applications attempt to use it
as a part of a security strategy. The goal of this document is to
encourage proper deployment of address to name mappings, and provide
guidance for their use.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-inaddr-required-05.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsop-inaddr-required-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsop-inaddr-required-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 27 Apr 2004 20:03:42 -0400 (EDT)

This draft was already discussed and rejected.  I note that the draft 04 
has been deleted from the IETF site. 

Instead of addressing any of the many previous issues addressed against
the 04 draft, as demonstrated by reviewing the archives of that
discussion, it simply rehashes the same wrong claims made by the 04 draft.

Indeed, it was pointed out that it does not accurately state ARIN's policy
on the subject. This was just one of _many_ problems, but probably the
easiest to fix.  It is practically an insult to resubmit this draft in its
present form.

So, why is it coming up again?  

Can we finally kill this once and for all?

		--Dean

***In fact, according to Leslie Nobile, ARIN is considering dropping
in-addr support in the future, and has gone so far as to engage its
attorney's to research the question of whether it is obligated to provide
the service. Their lawyers say they are not obligated.

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Dean Anderson <[email-masked]>
Date: Thu, 29 Apr 2004 10:21:13 -0400 (EDT)

Am I preaching to the choir, or do people disagree with me?

It would be good to let your opinions be known.

Otherwise, we might allow further misleading and false claims about 
whether in-addr is required.  In-addr is not required, nor will this draft 
(despite its misleading name) change that. It should also not be allowed 
to mislead people on the policies of other organizations, nor should it be 
allowed to promote bad practices by applications or otherwise mislead 
people as to the purpose and utility of in-addr.

		--Dean

.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 Apr 2004 17:37:05 +0300 (EEST)

> It would be good to let your opinions be known.

Yes, I disagree.

> people as to the purpose and utility of in-addr.

The document should be revised to take out all the upper-case keywords 
and bogus things like:

  Regional Registries and any Local Registries to whom they delegate
   SHOULD establish and convey a policy to those to whom they delegate
   blocks that IN-ADDR mappings are required.  Policies SHOULD require
   those receiving delegations to provide IN-ADDR service and/or
   delegate to downstream customers.

.. even if this would be a good practice, it's not an IETF business to 
set these requirements or so it would seem to me.

On the other hand, it's fine to discuss the tradeoffs of in-addr 
mappings, why it would make sense to have them (or why not), how they 
are set up properly, etc. -- all of this is what (IMHO) the document 
should be doing.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.

---

From: Peter Koch <[email-masked]>
Date: Thu, 29 Apr 2004 19:58:09 +0200

> Am I preaching to the choir, or do people disagree with me?

Some do, count me in.

> (despite its misleading name) change that. It should also not be allowed 

Please look into the document, the title was changed whereas the filename and
the announcement text continued to say "require". In the document there are
still some "requirements" - and, btw, non-ASCII characters - that I feel
should be ``diplomatized'', but I fully support the general direction of that
document.

-Peter
.

---

From: Peter Koch <[email-masked]>
Date: Thu, 29 Apr 2004 20:17:23 +0200

> The document should be revised to take out all the upper-case keywords 

use of RFC 2119 keywords in documents not specifying protocols or processes
is a tightrope walk anyway, but as long as the weaker forms like SHOULD or
RECOMMENDED are used they are OK for a BCP.

> set these requirements or so it would seem to me.

The IETF also suggests/recommends certain network ingress filters although
that's not its core business. However, I agree that the term "required" here
again is too strong. Highly RECOMMENDing should be sufficient, not more but
also not less.

-Peter
.