Subject: WG last call: ENDS0

From: Robert Elz <[email-masked]>
Date: Thu, 17 Dec 1998 00:09:19 +1100

As indicated in the (draft) minutes of the DNSIND meeting, the WG
meeting in Orlando concluded that the EDNS0 draft is done, and ready
for WG last call.

This is that WG last call.   We will run it until the end of this year
(ie: comments should be sent during 1998).

The draft is : draft-ietf-dnsind-edns0-00.txt

It is known that an "IANA Considerations" section will need to be added
to the draft before it can proceed further, so there's no need to make
that particular comment.

Please send other comments to the list.

wrt the IANA considerations.

There are two issues - first, that section ought note that this draft has
caused the IANA to assign values for the OPT RR type, and the 0b01xxxxxx
label type, and that the "0b11xxxxxx" label type is now reserved.   It also
needs to indicate that the RCODE space is now 12 bits, rather than 4, and
that the IANA registry of RCODE values is now larger.

Second, it needs to indicate that the IANA is to create a registry of
OPTION-CODEs for the OPTION RR, and how that registry is to be maintained.

There are two basic methods for maintenance of the registry.   We can
specify in the IANA considerations in the doc) that new entries are to
be added by IESG standards action only - that basically means that a PS
status RFC is needed before a new value will be assigned.   Or we can
indicate that they can be assigned by publication of any RFC (ie: as long
as the details are published, the IANA can issue a code).   Or we can
designate a WG "expert" to whom the IANA can turn to request advice when
an application for a new code is received.   Typically the expert consults
the mailing list for opinions, however the IANA need a designated person so
they can have someone whose opinion they trust, rather than relying upon
them making some kind of sense of a WG mailing list discussion.

For this, and in conformance with most traditional DNS practice, I'd suggest
the first of those - IESG standards action, as the assignment rule.
Opinions please?

kre

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 16 Dec 1998 14:29:12 -0600

> [ ... ]

I agree completely.

				Matt

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 17 Dec 98 10:56:19 JST

Kre;

> the first of those - IESG standards action, as the assignment rule.

In practice, it means people just use new values of OPTION-CODEs
without consulting IANA.

Neither ISO nor IETF can't interfere the development of defacto
standards.

The more closed IETF, the less public attention.

> Or we can
> as the details are published, the IANA can issue a code).

That's a too strong requirement. I-D or any open specification has
been the open tradition of the Internet, if not IETF.

							Masataka Ohta

---

From: Peter Koch <[email-masked]>
Date: Fri, 18 Dec 1998 02:02:23 +0100

> caused the IANA to assign values for the OPT RR type, and the 0b01xxxxxx

This has caused some confusion in the recent past. There's no statement
in BCP 26 that requires single allocations documented in the very same
RFC to go into that section. Wasn't this really meant to document how
administration of newly created name/numberspaces should be dealt with?

> label type, and that the "0b11xxxxxx" label type is now reserved.   It also
"0b11xxxxxx" is the standard compression indicator; WG consensus was (in LA)
that "0b10xxxxxx" should be given to local compression. So, why mention it
here at all?

> the first of those - IESG standards action, as the assignment rule.

The RR type number space has probably been the one facing the highest demand
so far (wrt DNS).  Some - even recently assigned - types are documented in
informational (KX RR) RFCs and also non-RFC documents (ATMA RR), i.e. without
formal IESG approval. Neither of OPT and TYPE is a scarce resource (2^16).
However, the introduction of new OPT codes might cause more interoperability
problems than new RR types. So, I'm in favor of the "IETF Consensus" model,
which opens the door for Experimental RFC specs, but not needlessly further.

-Peter

---

From: Robert Elz <[email-masked]>
Date: Sat, 19 Dec 1998 03:14:37 +1100

Date:        Fri, 18 Dec 1998 02:02:23 +0100
    From:        Peter Koch <[email-masked]>
    Message-ID:  <[email-masked]>

  | There's no statement
  | in BCP 26 that requires single allocations documented in the very same
  | RFC to go into that section.

I know.   But believe me, for the cost of a sentence or two, things will
progress easier...

  | "0b11xxxxxx" is the standard compression indicator; WG consensus was (in LA)
  | that "0b10xxxxxx" should be given to local compression. So, why mention it
  | here at all?

Either it should be removed from the main body of text of the draft, or
mentioned here.   Since edns0 will be done before local-compression, the
latter can override the former, so which choice is made does not matter
a lot.

  | So, I'm in favor of the "IETF Consensus" model,
  | which opens the door for Experimental RFC specs, but not needlessly further.

We now have support for almost every reasonable choice here...   Can we have
more opinions from others please?

And now I remember it, the "version number" space is another that is to
get numbers allocated from it.  That one also needs to be mentioned in the
IANA considerations section.   I would assume (hope) that we will all agree
that only standards action RFCs should be able to assign new version numbers.

kre

---

From: Thomas Narten <[email-masked]>
Date: Wed, 23 Dec 1998 14:26:59 -0500

Mostly nits here.

>      fields whose range has been or soon will be exhausted, and does not

comma not needed

>    2 - Affected Protocol Elements
> 
>    2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
>    word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
>    1-bit flags.  The original reserved Z bits have been allocated to
>    various purposes, and most of the RCODE values are now in use.  More
>    types and more possible RCODEs are needed.
     ^^^^^

s/types/OPCODEs/ ??

>    2.3. DNS Messages are limited to 512 octets in size when sent over UDP.

How about citing the RFC that requires this.

>    While the minimum maximum reassembly buffer size is still 512 bytes,
>    most of the hosts now connected to the Internet are able to reassemble
>    larger datagrams.  Some mechanism must be created to allow requestors to
>    advertise larger buffer sizes to responders.

Also, I don't believe the above terminology is accurate. The term
"reassembly buffer size" is also used to refer to the maximum-sized IP
datagram a stack is able to receive (after fragmentation); that value
is 576 bytes. The 512 limit above is something specific to DNS.

To avoid confusion, how about rewording something like:

   DNS Messages are limited to 512 octets in size when sent over UDP
   [RFC 1035]. With the ubiquity of LANs with large MTUs (e.g., 1500
   octets for Ethernet), most hosts are able to accept larger
   datagrams.  A mechanism is needed to allow requestors to
   advertise that they can accept larger responses.

>   CLASS        u_int16_t      sender's UDP buffer size
   
I assume this quantity refers to the UDP payload size, excluding UDP,
IP and lower layer headers. It would be good to state this clearly.

>   EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.

If I interpret this correctly, the extended-rcode field is appended to
the 4-bit RCODE field in the header to get one 12-bit RCODE. If that
is the case, be sure to mention somewhere that value 0x00 is reserved
so that the existing RCODES are grandfathered in correctly. Also, is
the intention NOT to reserve one of the RCODE types to mean "there is
an extended rcode that goes along with this one". Might be good to do
that in the short term, to make sure implementations don't ever
confuse currently defined RCODEs with extended RCODEs that happen to
share the first 4 bits (i.e,. the guidelines to IANA section needs to
be thought about a bit here).

>    VERSION         Indicates the implementation level of whoever sets it.
>                    Full conformance with the draft standard version of this
>                    specification is version ``0.''  Note that both

s/the draft standard version of//

("draft standard" has a specific meaning in RFCs, and this could be
confusuing.)

>   expected to send a respose with RCODE NOTIMPL, FORMERR, or SERVFAIL.

s/respose/response/

Thomas

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 20 Dec 98 8:53:59 JST

Kre;

> more opinions from others please?

I think reality checks work better than opinions.

Can Informational RFCs be published without review?

Which makes interoperability problems worse, IANA registeded
assignments or unofficial undocumented ones?

							Masataka Ohta