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/>

--
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: Paul Vixie <[email-masked]>
Date: Mon, 05 May 2008 13:27:05 +0000

> > ...

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

i would like to just publish the document, and not lose another IETF Interval
(that being the time between meetings) wondering how many bits can dance on
the head of this particular pin.  any objections to declaring mandatoriness
controversial and moving on without it?

---

From: [email-masked]
Date: Mon, 5 May 2008 17:28:03 +0000

peter, i like this approach.

--bill