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 PROTECTED]> 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
