Re: WG last call: ENDS0

[Thomas Narten <narten@raleigh.ibm.com>]

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