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
On Tue, 4 Apr 2006, Andrew Sullivan wrote:
> 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
>
>
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
