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

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Feb 2008 05:44:31 +0000

thanks again for this.  all of your recommendations will appear in edns0bis-00.

re:

> From: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
> Subject: draft-ietf-dnsext-rfc2671bis-edns0-00 (fwd)
> To: [email-masked]
> Date: Tue, 1 Jan 2008 09:06:59 +0100 (MEZ)
> X-Mailer: ELM [$Revision: 1.17.214.3 $]
> Sender: [email-masked]
> 
> [ 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
> Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3)
>       id AA190880004; Sat, 29 Dec 2007 15:53:24 +0100
> Return-Path: <[email-masked]>
> Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3)
>       id PAA20672; Sat, 29 Dec 2007 15:53:23 +0100 (MEZ)
> From: Alfred HÎnes <[email-masked]>
> To: [email-masked]
> Message-Id: <[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/>

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