Re: [dnsop] WGLC on draft-ietf-dnsop-bad-dns-res-03.txt

Suzanne Woolf <Suzanne_Woolf@isc.org> Mon, 22 November 2004 05:02 UTC

Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01731 for <dnsop-archive@lists.ietf.org>; Mon, 22 Nov 2004 00:02:19 -0500 (EST)
Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id iAM3srhP000105; Sun, 21 Nov 2004 19:54:53 -0800 (PST)
Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id iAM3sr6A000104; Sun, 21 Nov 2004 19:54:53 -0800 (PST)
Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id iAM3sq93029956 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <dnsop@lists.uoregon.edu>; Sun, 21 Nov 2004 19:54:53 -0800 (PST)
Received: by farside.isc.org (Postfix, from userid 10265) id 8027867503; Mon, 22 Nov 2004 03:54:47 +0000 (UTC)
Date: Mon, 22 Nov 2004 03:54:47 +0000
From: Suzanne Woolf <Suzanne_Woolf@isc.org>
To: dnsop@lists.uoregon.edu
Subject: Re: [dnsop] WGLC on draft-ietf-dnsop-bad-dns-res-03.txt
Message-ID: <20041122035447.GB36077@farside.isc.org>
References: <20041119215805.37460418A@thrintun.hactrn.net> <6.1.2.0.2.20041120155549.03b38d10@localhost> <20041121165643.GA29786@farside.isc.org> <Pine.LNX.4.61.0411212145290.23597@netcore.fi> <20041121222608.7D37C41FF@thrintun.hactrn.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20041121222608.7D37C41FF@thrintun.hactrn.net>
User-Agent: Mutt/1.4.2.1i
Sender: owner-dnsop@lists.uoregon.edu
Precedence: bulk
Reply-To: Suzanne Woolf <Suzanne_Woolf@isc.org>

On Sun, Nov 21, 2004 at 05:26:08PM -0500, Rob Austein wrote:
> It would help if folks who think they see protocol changes coming out
> of this document would clearly identify the protocol changes they
> think they're seeing.  Eg, the NS RRset ordering issue identified in
> the message that Pekka cited is not (in my opinion) a protocol change,
> since the DNS specs are already reasonably clear that RRsets are and
> always have been unordered.

In case it wasn't clear, I was suggesting that we investigate whether
some of the implementation advice might be more persuasive as
protocol, not that there's anything wrong with what the dnsop draft
already does. IOW, what Rob is asking for here is noble, right,
necessary....and not on any critical path for forwarding bad-dns-res
as a BCP.

I really want to see this draft go forward-- having it published at
all would give us a stick we don't presently have, so I don't want to
see the WG bog down on the question of whether it's cut from the right
tree.

There's a difference between saying "the Internet would be a better
place if implementors and/or operators did <x>" and "Implementations
that don't do <x> are not compliant with the standard." In the case of
the recommendations in bad-dns-res, it might be appropriate and useful
to "promote" some of them from recommendations to DNS protocol. This
is, however, outside of the question of whether they should be
published as implementation advice to curtail specific problems as
described in the draft.

I personally suspect that standards-track language (MUST and SHOULD)
sometimes causes confusion in BCPs, since we live in a world where
people are often a bit unclear on what's a standard anyway? -- but the
words are nearly unavoidable in a situation like this. However, the
draft itself is a little ambiguous on this point. The Abstract
describes its purpose as including "minor additions to the DNS
protocol specification and corresponding changes in iterative resolver
implementations", and uses RFC 2119 words.

I'd specifically suggest:

1. Clarify in the abstract and, if necessary, elsewhere that these
recommendations may or may not become protocol but they're still
really, really good ideas and following them means you'll be compliant
if they *are* standardized....and still a good citizen if they're not.

2. Take up a separate work item, if the WG so desires, of determining
which, if any, should be protocol. With bad-dns-res to motivate such
changes, they'll be easier to justify in DNSEXT if there's something
to be gained thereby.


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