[dnsext] Re: polishing of draft-ietf-dnsext-rfc3597-bis-01

[Alfred Hönes <[e-mail]>]

Andreas,
thanks for your detailed response.

> Alfred Hoenes wrote:
>> A few notes on the revised "Handling of Unknown RR Types" draft,
>> draft-ietf-dnsext-rfc3597-bis-01.
>
> Thank you for your continued review, and sorry that I have taken this
> long to respond.

"this long" ??   No need to excuse!  I'd been happy having the time
to follow up to all pending threads this fast!  :-)


>> (1)  Definitions
>>
>> The draft has a useful Section 2, "Definitions".
>> However, the definition of "well-known RR type" is buried in
>> Section 4.  I suggest to move that definition into Section 2
>> and adjust the text in Section 4 accordingly.  For instance:
>>
>> Append a new paragraph to Section 2:
>>
>>    A "RR of well-known type" is hereby specified as having one of the
>>    RR types defined in [RFC1035].  (This term has been introduced by
>>    [RFC3597] and is not changed hereby.)
>>
>> Edit the 2nd paragraph of Section 4:
>>
>>    To avoid such corruption, servers MUST NOT compress domain names
>>    embedded in the RDATA of types that are class-specific or not well-
>>    known.  This requirement was stated in [RFC1123] without defining the
>> |  term "well-known"; it is hereby specified that only the RR types
>> |  defined in [RFC1035] are to be considered "well-known".
>> ---
>>    To avoid such corruption, servers MUST NOT compress domain names
>>    embedded in the RDATA of types that are class-specific or not well-
>>    known.  This requirement was stated in [RFC1123] without defining the
>> |  term "well-known" (now introduced in Section 2 above).
>
> I'm not convinced this would be an improvement.  The text you propose
> moving is not really a "definition" in the sense of defining a term
> for use within the document itself; rather, it prescribes a particular
> interpretation of a term in RFC1123, and thereby forms an integral
> part of the protocol specification.  As such, I still think it belongs
> in section 4 rather than in section 2.

Well, the improvement IMHO would be the central place to look for
definitions, making it easier for future documents to include these
definitions 'en bloc' by reference.
Your argument is somehow valid as well.  I thought I had taken care of
the special role of this term in my proposed text via the parenthetical
explanation.  (I have corrected my spelling error in the quote above.)

It would be possible to combine the benefits of a central repository
of the terms used in the memo and at the same time leaving normative
text in place, by using an "indirect" definition in Section 2, pointing
to the normative text.  For instance:

|   RFC 1123 [RFC1123] has used "RR of well-known type" without giving
|   a definition of the term.  See Section 4 below for the normative
|   definition (originally introduced by [RFC3597]).


>> (2)  Text Representation -- format rules
>>
>> The list of 'word' in Section 5 might be improved visually
>> by making use of "symbols" type list format, e.g. using dashes
>> or asterisks.
>
> Agreed, but I'm not sure how to do this in "nroff -ms" (the document
> is based on the original RFC3597 nroff source); hints are welcome.

Sorry, I can't offer recent experience, but as the RFC Editor uses
nroff for the final stage, it must be possible.
Do you have the macros available that are described in
Section 5.3.7.2 if draft-lilly-using-troff-05 ?
There, bulleted lists are produced by using:

.BL
.LI
first bulleted item
.LI
second bulleted item
.LE


Bruce Lilly's tmac.rfc nroff/troff macros are available from his
web site as described in that draft.


>> Also, guided by the example at the end of the section, I suggest
>> to refer to the RFC 1035 rules for line folding (using parentheses).
>> The introductory clause only talks about white space; so some
>> elaborations as to what is regarded white space here seem to be
>> appropriate.  (Similarity to the "CFWS" construct in email!)
>> After re-reading the related part of RFC 1035, I therefore also
>> suggest adding a note that recalls the possibility of semicolon-
>> delimited end-of-line comments as defined in RFC 1035.
>>
>> These additions hopefully make the specification here more self-
>> contained (last para of Section 1!) and admonish implementers to not
>> forget the general rules.  :-)
>
> Point taken regarding properly defining the term "white space".
> RFC1035 says "Any combination of tabs and spaces act as a delimiter
> between the separate items that make up an entry", so I will change
> the text to be consistent with this terminology, including replacing
> the term "word" by "item".  That is, I will replace
>
>   The RDATA section of an RR of unknown type is represented as a
>   sequence of white space separated words as follows:
>
> by
>
>   The RDATA section of an RR of unknown type is represented as a
>   sequence of items separated by any combination of tabs and
>   spaces, as follows:

So I assume that you have applied the change of terminology to the
3rd item in the subsequent list (the only other occurrence of "word"
in this sense).


> As to the general rules regarding parentheses and end-of-line comments
> in master files, as much as I would like to educate readers about
> them, I don't think that is within the scope of the current document.

Not sure.  If these optional "decorations" were not mentioned in the
normative text here, the reader could be led to the assumption that
the draft text wanted to state an exemption from the general rules
for the case on unknown RR types.


>> (3)  Change Summary
>>
>> We are going to obsolete RFC 3597 and heading for DS with this draft.
>> IESG rules thus require describing the differences of the memo from
>> its predecessor in some part of the document that is not doomed to be
>> stripped off by the RFC Editor.
>>
>> Therefore, it might be wise to add a section (or Appendix)
>> "Changes Since RFC 3597" that gives a condensed summary of
>> the current Appendix A.
>
> Will do, but I'm still curious as to where these IESG rules are
> documented - do you have a reference?

I'm not aware of a written statement, but my brain leaks as well.
In general, the well-known rule of "In the IETF it is most important
to know which of the written rules are _not_ applied in practice"
is likely to need an addition "... and which other, unwritten rules
are expected to be followed closely."   :-)


> Regards,
> --
> Andreas Gustafsson, [e-mail]


Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+