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

From: Andreas Gustafsson <[email-masked]>
Date: Tue, 16 Feb 2010 10:09:18 +0200

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.

> (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 herby.)
> 
> 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.

> (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.

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

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.

> (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?

Regards,
-- 
Andreas Gustafsson, [email-masked]

---

From: Alfred Hönes <[email-masked]>
Date: Tue, 16 Feb 2010 11:26:14 +0100 (MEZ)

Andreas,
thanks for your detailed response.

> Thank you for your continued review, and sorry that I have taken this

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

>>    [RFC3597] and is not changed hereby.)
>>

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]).

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

>   sequence of items separated by any combination of tabs and

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).

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

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

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| 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]                     |
+------------------------+--------------------------------------------+

---

From: Jim Reid <[email-masked]>
Date: Tue, 16 Feb 2010 11:00:51 +0000

> is based on the original RFC3597 nroff source); hints are welcome.

Hi Andreas. The magic incantation is

.IP \(bu
bunch of text
.IP \(bu
some more text

This gets [nt]roff to format the following text as an indented  
paragraph using \(bu -- the bullet character -- as a tag. Other tag  
characters or strings can be supplied as parameters to the IP macro. :-)

It's nice to know that I'm not the only one who still uses troff...

---

From: Andreas Gustafsson <[email-masked]>
Date: Fri, 19 Feb 2010 13:52:15 +0200

> definitions 'en bloc' by reference.

At this juncture, my main concern is the progress of this document
rather than the ease of writing future ones.  If the sentiment of the
working group as a whole is that your proposed change is important,
I will integrate it, but otherwise I would really prefer to leave the
text as is.

> Section 5.3.7.2 if draft-lilly-using-troff-05 ?

Unfortunately, I don't; the document is is based on plain "nroff -ms"
plus the fix.pl post-processing script from RFC2223 (the initial
version of the document predates draft-lilly-using-troff-05 by several
years).  But I did finally managed to find a (somewhat ugly) solution
based on the .IP command.

> 3rd item in the subsequent list (the only other occurrence of "word"

Yes, I have.

> for the case on unknown RR types.

RFC1035 says:

   The format of these files is a sequence of entries.  Entries are
   predominantly line-oriented, though parentheses can be used to continue
   a list of items across a line boundary, and text literals can contain
   CRLF within the text.  Any combination of tabs and spaces act as a
   delimiter between the separate items that make up an entry.  The end of
   any line in the master file can end with a comment.  The comment starts
   with a ";" (semicolon).

I really don't see how the mere lack of a mention of these rules could
be interpreted as stating an exemption from them.  RFCs that define
new (i.e., known) RR types and their presentation formats also
typically don't mention the comment and line continuation syntax
explicitly.  These aspects of the master file format aren't even
specific to RR entries; they apply to any entry including ones like
$ORIGIN and $INCLUDE.

> are expected to be followed closely."   :-)

If that's indeed the case, it would seem to have rather serious
implications with regards to the openness of the IETF process.
-- 
Andreas Gustafsson, [email-masked]

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 19 Feb 2010 14:26:01 +0100 (MEZ)

Andreas,
thanks for your feedback, again.  Follow-up elaborations inline.

> I will integrate it, but otherwise I would really prefer to leave the

Hmm. You start confusing me.  "At this juncture," ...
AFAICS, the draft is not yet short of being shipped.

Recent anecdotal evidence from the famous and honorable effort to
update/advance email RFCs to Full Standard and voices from the IESG
that seem to indicate preference to make editorial improvements
earlier, not on the way from PS to FS, I simply thought the current
state of _this_ draft would be a good opportunity to apply such
improvements.

However, I will not insist on this detail.  Just my 2 ct.

>  ...

As has been pointed out recently, our old Standards are a treasure
of important details folks are not always aware of.   :-)

Unlike typical new RR type definitions, this memo contains rather
concise normative text of the presentation format (on 'unknown'
RR types) -- and that is good so and important.

Therefore, I saw the risk that readers of section 5 skimming over
the passage,

   The RDATA section of an RR of unknown type is represented as a
   sequence ofwhite space separated items as follows:

   [...]

could be (mis-)led to the assumption that this text was *overriding*
the general rules in RFC 1035.

Since DS and FS documents should be even more precise and unambiguous
than PS documents, IMO it would be a good idea to add a hint/reminder
that the general rules you quote correctly still hold as well for the
presentation format of unknown RR types.

Once more, just my 2 ct. (or maybe 20 ct., this time).

>>>> [...]

[ I'm splitting off this part to a different message.
  It has turned into a diversion into general IETF practices.
  Further discussion of that topic most likely should not be
  pursued on this list, due to its much more general scope. ]

Kind regards,
  Alfred.

---

From: Alfred Hönes <[email-masked]>
Date: Fri, 19 Feb 2010 15:02:51 +0100 (MEZ)

This is the part of my follow-up response to Andreas Gustafsson
that I have split off since it started to get off-topic.
Any more general follow-up discussion should better migrate to a more
appropriate list, e.g. the IETF main discussion list.

>>>> (3)  Change Summary
[ah]
>>>> "Changes Since RFC 3597" that gives a condensed summary of
[gson]
>>> documented - do you have a reference?
[ah]
>> are expected to be followed closely."   :-)
[gson]
> implications with regards to the openness of the IETF process.

Regarding openness, I have more serious concerns.
(RFC-to-be's held off by IESG intransparently, etc.... )
But that is off-topic here.

I'm not sure where I last had read that phrase (flame?) above -- and it
essentially doesn't matter here --, I bet it was one of the procedural
drafts from Brian Carpenter in which he tried to overcome the road
blocks to revising RFC 2026 and adopting it to long standing practice.

I am tempted to quote a COMMENT posted yesterday by an AD, with
respect to a technical document in the IESG and the IETF procedures
followed in its (6 years lasting) genesis, and I challenge its more
general applicability to the meta level of IETF procedural standards
as well  (and so I've elided from the quote all keywords related to
the triggering circumstances):

   "[...]
    This would seem to imply that the .... WG has decided to
    deviate from the old IETF operating principle of "rough
    consensus and running code".  For at least some of the
    techniques described in this draft, they are generally
    accepted and widely implemented on key implementations.
    I ask what the reason is for divorcing IETF standards
    from established best practices and actual running code?
    ... RFCs are not sacred documents, they should reflect what
    we want our implementations to do.  But maybe there are
    important use cases for the actual standard ... behavior
    in this space, just that I don't know about them.  Please
    educate me about the background for this decision."

That said, I perhaps should emphasize once more that I appreciate
the effort to advance RFC 3597 on the Standards Track (and thereby
follow RFC 2026 in this case, albeight with a less tight schedule).

Kind regards,
  Alfred.