Subject: [dnsop] More on draft-ietf-dnsop-inaddr-required

From: Andrew Sullivan <[email-masked]>
Date: Tue, 4 Apr 2006 17:08:54 -0400

Dear colleagues,

During the Dallas meeting, the topic of draft-ietf-dnsop-inaddr-required
came up.  About five people, including me, indicated interest in the
draft, and the Chairs suggested that what was needed was an open
issues list.  

Since I committed to do something about this, I thought I'd propose a
summary list of what I take to be open issues.  I don't expect this
is a complete or correct list; I'm just proposing it so that we have
something to start with (or, perhaps, so you can all point and laugh
at what a bad job I've done understanding the discussion this far!). 
I'm also not proposing text patches now, on the grounds that we
perhaps need to agree on a list of what the issues are before we
attempt to fix them.  I hope this is helpful.

I compiled the following list by looking at the discussions about
this draft from last January.  The threads start at

<http://darkwing.uoregon.edu/~llynch/dnsop/msg03618.html>

and

<http://darkwing.uoregon.edu/~llynch/dnsop/msg03619.html>

I'm not including mere editorial comments (style, &c.) here, since I
doubt that's where the real contention is.

The list
--------

1.	Update the policy discussion in paragraph 3 of section 2.

2.	Fix informative reference [ARIN] target.

3.	Add informative reference to detailed APNIC policies at
        <http://www.apnic.net/services/dns_guide.html>.

4.	Add informative reference [AFRINIC].

5.	The recommendations in section 4 are not strong enough.

6.	The ability of people actually to add PTR records is not
	considered.

Also, I noted one issue while I was preparing this, but I'm not sure
it's in the discussion from January:

7.	Section 2, paragraph 2, appears to say that [RFC2050]
	requires RIRs to maintain IN-ADDR records on the large blocks
	they issue.  I'm not entirely sure that RFC2050 actually says
	that, even if that's what was intended.

Discussion
----------

* Issue 1
	
	Some of the policy is out of date, and needs to be adjusted
	to reflect the current policies of the bodies in question.

* Issues 2-4

	These are references that need fixing in light of (1).
 
* Issue 5

        Some people (I am among them) express uneasiness that the
        document seems to suggest both that IN-ADDR is a good thing,
        and that one shouldn't use it.  People argue that, therefore,
        the recommendation should be stronger.  In particular, some
        have argued that the advice in section 4.2 could be made a
        little more equivocal, so that operators are urged to be
        fully aware of the trade-offs they make in terms of
        reliability when relying on IN-ADDR, but that they should not
	be told "never do this".

* Issue 6

        Some people note that there are plenty of parts of the
        Internet where users have a hard time maintaining IN-ADDR. 
        So, the discussion of the state of affairs in section 2 (or
        perhaps 3, if it's renamed) should point out how difficult it
        sometimes is for people to do this maintenance (and,
        presumably, lament the situation as one that ought to be
        fixed).  In addition, any alteration of section 4.2 in
        accordance with (5) will need to point out to operators the
        potential victims of their decisions to rely on IN-ADDR.

*Issue 7

        RFC 2050 says, "The regional registries will be responsible
        for maintaining IN-ADDR.ARPA records only on the parent
        blocks of IP addresses issued directly to the ISPs or those
        CIDR blocks of less than /16." That doesn't entail that they
        will be responsible for such maintenance.  It rather entails
        that, if they are responsible for anything, they're only
        responsible as far as the parent block (or the blocks less
        than /16).  Perhaps there's another source which makes it
        unambiguously clear that they are in fact responsible for
        this?

Best regards,
A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

.
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: Wed, 5 Apr 2006 14:22:20 -0400 (EDT)

I thought that the title was going to be changed to 'inaddr-encouraged', and I
thought there were additional issues with the text, but I don't have a list
right off-hand. Though I recall some particular problems with the notion that
reverse and foward should or can always match, and particular problems with
security assumptions promoted in the draft.  

I'll see if I can review some of the email on the topic later this week, as well
as summarize some offlist discussion with a few people that apparently
misunderstood the text of the draft.

		--Dean

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

.