Subject: draft-ietf-dnsext-rfc2671bis-edns0-00 (fwd)

From: Alfred Hönes <[email-masked]>
Date: Tue, 1 Jan 2008 09:06:59 +0100 (MEZ)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

----- Forwarded message from Alfred Hönes -----

>From [email-masked] Sat Dec 29 15:53:25 MEZ 2007
From: Alfred Hönes <[email-masked]>
To: [email-masked]
Date: Sat, 29 Dec 2007 15:53:22 +0100 (MEZ)
Subject: draft-ietf-dnsext-rfc2671bis-edns0-00

Hello,
after studying the recently published Internet-Draft authored by you,
          draft-ietf-dnsext-rfc2671bis-edns0-00,
I'd like to submit a few comments.

The items below are presented in textual order.
Occasionally, to give more context, I quote larger blocks of
text literally and show the replacement proposed using the
shorthand notation:

   <original draft text>
---
   <modified text>

I also sometimes use change bars ('|' in column 1) and up/down
pointing marker lines ('^^^'/'vvv') to emphasize the location
of textual issues, proposed corrections, or new text.
Modified or proposed new text has been (re-)adjusted to match
RFC formatting rules, where appropriate.
I also try to accomodate published RFC-Ed policy on style and
punctuation etc. in my proposals.

(1)  Document Metadata and purpose

The draft name seems to indicate that this draft is intended as
a replacement for RFC 2671, but that is not stated explicitely.

Also, other parts of the draft look like a hybrid of an update to,
and a full replacement for, RFC 2671.  I strongly recommend to
build an unambiguous, self-contained replacement that will fully
obsolete RFC 2671.  All other solutions would certainly be a
never ending source of confusion.

(BTW: RFC 2821 once has incorporated the SMTP extension mechanism,
 ESMTP, into the updated SMTP specifiation, and the 2821bis draft
 continues this way.
 This conforms to the protocol design principle accepted in the
 IETF, that the basic specification of a protocol that is envisioned
 to be extended in various ways should always already describe and
 standardize the purposely crafted extensibility mechanisms needed
 to this end, to ensure interoperability with future extensions.
 Thus, it certainly would be very useful to incorporate the EDNS
 mechanism into an updated basic DNS protocol specification (which
 would be welcome for many more reasons anyway), but such effort is
 probably far out of scope currently.)

I suggest to add (in common style) to the document heading:

| Intended Status: Standards Track
| Obsoletes: 2671 (if approved)

(2)  Section 1

In line with item (1) above, I suggest to add a paragraph to
Section 1 (e.g., at the beginning of 1.2.) that introduces RFC 2671
and clarifies the relationship of this draft to it, for instance:

 1.2.
|  [RFC2671] originally has proposed extensions to the basic DNS
|  protocol to overcome these deficiencies.  This memo refines that
|  specification and obsoletes RFC 2671.

   Unextended agents ...

(3)  Section 2 and Section 3

IMHO, the draft is not explicit enough in stating its role in
specifying the extensions / affected protocol elements.

Also, as I understand the structure of the draft, Section 2 is
intended as descriptive text, and the subsequent sections contain
the normative text.

I suggest to add, at the end of Section 2.1, a statement indicating
the action performed by this memo, for instance:

|  The OPT pseudo-RR specified in Section 4 contains subfields that
|  carry a bit field extension of the RCODE field and additional flag
|  bits, respectively; for details see Section 4.6 below.

W.r.t. Section 2.2, Section 7 contains the statement:
   This document assigns label type 0b01xxxxxx as "EDNS Extended Label
   Type."  We request that IANA record this assignment.

Hence, in Section 2.2 it should be made explicit that this memo
reinforces the allocation made in Section 3 of RFC 2671.

Preferably, the text in Section 3 should only contain precise
normative content.  The current text in Section 3 is only a review
of the legacy, which should be appended to (or merged into) the
current text of Section 2.2.  This should be followed by a short
preview/description of what this memo does w.r.t. label types.
For instance, add to the end of 2.2:

|  Section 3 of this document reserves DNS labels with a first octet
|  in the range of 64-127 decimal (label type 01) for future
|  standardization of Extended DNS Labels.

Similarly, in Section 2.3 the action of the memo should be made
explicit.  For instance, add to the end of 2.3:

|  To this end, the OPT pseudo-RR specified in Section 4 contains a
|  maximum payload size field; for details see Section 4.5 below.

(4)  Section 3

As stated above, I strongly recommend to only place normative text
(and/or 'meta-normative' text, if you like) into Section 3.
This text should be self-contained; the reader should not need the
descriptive/informative sections to understand/implement the
specification.

For instance, the new text for Section 3 could be:

|  The first octet in the on-the-wire representation of a DNS label
|  specifies the label type; the basic DNS specification [RFC1035]
|  dedicates the two most significant bits of that octet for this
|  purpose.
|
|  This document reserves DNS label type 0b01 for use as an indication
|  for Extended Label Types.  A specific extended label type is selected
|  by the 6 least significant bits of the first octet.  Thus, Extended
|  Label Types are indicated by the values 64-127 (0b01xxxxxx) in the
|  first octet of the label.
|
|  Allocations from this range are to be made for IETF documents fully
|  describing the syntax and semantics as well as the applicability of
|  the particular Extended Label Type.
|
|  This document does not describe any specific Extended Label Type.

Note:
 Some details, like the word 'reserves' in the second paragraph above
 (vs. 'allocates'), and the allocation policy indicated in the 3rd
 paragraph, will need to be discussed.

(5)  Section 4.3

To improve the readability of the specification, I strongly recommend to
explicitely state the numeical value of the RR type already allocated
for the OPT pseudo-RR.

Thus, please change:

   Field Name   Field Type     Description
   ------------------------------------------------------
   NAME         domain name    empty (root domain)
|  TYPE         u_int16_t      OPT
   [...]
---
   Field Name   Field Type     Description
   ------------------------------------------------------
   NAME         domain name    empty (root domain)
|  TYPE         u_int16_t      OPT (41)
   [...]
                                  ^^^^^

(6)  Section 4.4

In the artwork in Section 4.4, there are no single-octet fields;
Thus, the headline indicating byte offsets should be improved upon
for added clarity.  I suggest to change:

                 +0 (MSB)                            +1 (LSB)
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   0: |            [...]
---   v                               v                               v
|     :          +0 (MSB)             :              +1 (LSB)         :
      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   0: |            [...]

(7)  Section 4.6

Note:
 This change recommended in item (6) above is not needed so much
 for the artwork in Section 4.6, but for the sake of uniformity,
 it might be applied there as well.

I suggest to *not* quote the decimal representation of numerical field
values in the text, to distinguish these from literal text constants.
(The text also is inconsistent in using <"> and <''> for this purpose.)
Thereby, the single occurrence of a violaton of 'rational quoting'
in the text will be nullified as well.

Thus, I suggest to change:

   EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  Note
|                  that EXTENDED-RCODE value "0" indicates that an
                                             ^ ^      v v         v  v
|                  unextended RCODE is in use (values "0" through "15").
---
   EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  Note
|                  that EXTENDED-RCODE value 0 indicates that an
|                  unextended RCODE is in use (values 0 through 15).

and:

   VERSION         Indicates the implementation level of whoever sets it.
                   Full conformance with this specification is indicated
|                  by version ``0.''  Requestors are encouraged to set
                              ^^ ^^^
                   this to the lowest implemented level capable of
                   expressing a transaction, [...]
---
   VERSION         Indicates the implementation level of whoever sets it.
                   Full conformance with this specification is indicated
|                  by version 0.  Requestors are encouraged to set this
                   to the lowest implemented level capable of expressing
                   a transaction, [...]

(8)  Section 7

Neither RFC 2929 nor I-D 2929bis cover the EDNS sub-registries
rooted in RFC 2671:

   "EDNS Extended Label Type"
   "EDNS Option Codes"
   "EDNS Version Numbers"

Thus, the draft should advise IANA to 're-parent' those sub-registries
to this memo, and it should contain full IANA considerations for all
three sub-registries, including allocation policy statements,
in conformance with BCP 26, RFC 2424.

Also, I recommend to more clearly and uniformly state the specific
sub-registry addressed in all allocation statements, for the ease of
readers less experienced with DNS details (including IANA staff).

(9)  Section 9

I suggest to use the common punctuation style, in conformance with
contemporary RFC author guides.

For instance, change:

|  [RFC1035]    P. Mockapetris, ``Domain Names - Implementation and
|               Specification,'' RFC 1035, USC/Information Sciences
|               Institute, November 1987.
---
|  [RFC1035]    P. Mockapetris, "Domain Names - Implementation and
|               Specification", STD 13, RFC 1035, November 1987.

|  [RFC2119]    S. Bradner, ``Key words for use in RFCs to Indicate
|               Requirement Levels,'' RFC 2119, Harvard University, March
                1997.
---
|  [RFC2119]    S. Bradner, "Key words for use in RFCs to Indicate
|               Requirement Levels", BCP 14, RFC 2119, March 1997.

etc. ...

Best regards,
and my best wishes for the New Year,
  Alfred Hönes.

--

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

----- End of forwarded message from Alfred Hönes -----

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