Subject: Re: DNS is mandatory text

From: Peter Koch <[email-masked]>
Date: Tue, 15 Apr 2008 18:06:32 +0200

On Tue, Mar 11, 2008 at 11:31:54PM -0400, Olafur Gudmundsson wrote:

{catching up ...}

> So I propose that the next version of EDNS0bis contain something like:
> (feel free to word smith)
> 
> ENDS is required
> 
> ENDS was specified in 1999 been on the wire since then, with minimal
> adverse effects.
> As number of uses of DNS require larger answers than can be easily fit in
> 512 byte answers, it makes sense to require modern DNS software to implement
> EDNS0.
> Thus Authorative servers, Recursive Resolvers, Stub-resolver and middle-ware
> boxes speaking DNS in any form MUST implement ENDS0 and MUST support buffer
> size of at least 2K.

I agree that some text like this somewhere would be helpful but we need to
distinguish the respective audiences.  Even though the requirement originated
from the ENUM sphere, where some are used to working with monolithic
documents that cover both implementation and operation, there's a split
to make:

1) DNS software implementors first need to implement EDNS0 _and_ need to
   support a reasonable minimum maximum payload size.

2) "middleboxes" need to understand that DNS packets no longer are
   restricted to 512 octets in payload length and should be left alone.

3) Operators need to configure (and/or vendors need to supply defaults)
   not only EDNS0 enabled, but also with "reasonable" (as in: TBD)
   payload sizes.

Any self-reference ("this spec now is mandatory") seems dubious to me,
and although that path hasn't been walked much, a look at RFC 2026
shows that in addition to maturity levels, the standards process (yes,
usual disclaimer of general inapplicability applies - no pun - but still)
knows about "requirement levels" to be expressed in "Applicability
Statements" that are expected to accompany a "Technical Specification".
Following the spirit instead of the letter, I'd assume that (1) and maybe (2)
above could go in an AS-like document (probably separate from the EDNS0/bis
draft), while (3) is an operational issue that would be addressed in a BCP,
giving trade-off considerations (did I say that?) and making size
recommendations.

-Peter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Apr 2008 13:59:25 -0400

>Any self-reference ("this spec now is mandatory") seems dubious to me,

That point is one I have been trying to espouse for some time.  The 
IETF, lacking any protocol police or conformance labeling is not in 
position to declare anything as mandatory.

The way I try to approach this, and am now trying with the so-called 
"AXFR clarify" draft in DNSEXT, is to define a service as being 
comprised of certain elements.  If an implementation purports to 
offer the service, then the implementation is claiming conformance.

When it comes to operations, not all operations will encounter ENUM 
and will not need something like EDNS.  There are plenty of turnkey 
DNS implementations that will hum on adequately without it.

Again with the AXFR clarify - what I did was recommend that "general 
purpose" DNS implementations offer AXFR functionality.  I think that 
is the approprate approach for this - "general purpose" DNS code 
might or might not be used to do ENUM.  The alternative to "general 
purpose" is "turnkey" (or another similar word).

It's okay to say "DNS implementations of ENUM services (MUST SHOULD, 
RECOMMEND, MAY whatever) implement and use EDNS0 with a 
minimum/maximum message size of" but the same statement is not 
generalizable to all DNS implementations.  Constraints on services 
are okay, when it comes to protocols we should stick to defining what 
things mean.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Danny Mayer <[email-masked]>
Date: Tue, 15 Apr 2008 20:26:47 -0400

>> boxes speaking DNS in any form MUST implement ENDS0 and MUST support buffer

Does the text really say ENDS? I'm sure it's supposed to say EDNS0 and 
if not thats an error.

Danny

---

From: Peter Koch <[email-masked]>
Date: Wed, 16 Apr 2008 09:34:52 +0200

> position to declare anything as mandatory.

we're in slight disagreement here. I'm not questioning the IETF's
ability to make a statement about the applicability of a certain
protocol (element).  Of course the IETF can't enforce compliance,
but that's only so true for all the specs and besides the point.
Let's give the willing parties guidance.

-Peter