Subject: Re: [dnsext] WGLC: RFC5395bis obsoleting RFC5395

From: Alfred Hönes <[email-masked]>
Date: Fri, 19 Nov 2010 21:10:33 +0100 (MEZ)

> Remember this last call ends over the weekend.
>
>     Olafur

Olafur,
thanks for the heads-up!

In general: Support.

Minor concerns:

(1)
Section 5 and Annex A call for use of the dns-rrtype-applications
AT ietf.org mailing list, but the two descriptions of the purpose
and usage do not match precisely.  I'd appreciate a consistent
clarification of who's to send to that address at which stage of the
process.

IIUC what Section 5 says, only the expert(s) should be able to send
to dns-rrtype-applications, and this is the final step in the review,
which triggers IANA's clerical workflow; this should be made more
explicit.  (See below.)

Wouldn't  dns-rrtype-applications AT IANA.ORG  make more sense for
the purpose indicated in Annex A?

Sections 1, 3.1.1, and 3.1.2 and Annex B point to dnsext AT ietf.org
for discussion. To avoid surprise/confusion, it might be wise to
mention the dns-rrtype-applications email address and its use by the
expert(s) in an additional paragraph appended to 3.1.2.

(2)
I suggest to turn text in Sect. 5 to past tense where it actually
describes what IANA already has done on behalf of RFC 5395,
to better distinguish that from the References and mailing list
name update that IANA will have to perform for this memo;
e.g.   s/IANA shall establish/IANA has established/

Nits:

a)
The draft uses old (verbous++) "Status of This Memo" boilerplate.

b)
Essential procedural clauses are hidden therein:

                           It is intended to become the
   new BCP 42 obsoleting RFC 5395. Comments should be sent to the DNS
   Extensions Working Group mailing list <[email-masked]>.

Nobody reads the (assumed) boilerplate text.  Therefore, it might
be preferable to place these sentences in an additional front note
(using the xml2rfc <note> element inside <front>).

c)
It looks like the draft was based on a draft for RFC 5395 and
RFC-Ed changes retrofitted; yet, I miss some of the editorial
improvements applied in the RFC.
(For instance, compare the unpleasant layout of the table in
section 2.2 with the much better readable version in RFC 5395.)
This can be fixed at the RFC Editor.

Note that a rfcdiff of the RFC and the current draft might be more
instructive than the standard diffs offered at tools.ietf.org ; use:
  <http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=rfc5395.txt
         &url2=draft-ietf-dnsext-5395bis-01.txt>
But also note that this diff tool hides formating changes, e.g. in
table alignment or References.

d)
In the table in 3.1.4, hyphen is used for interval ranges *and* to
separate values from description.
In combination with the irregular indentation, that's rather confusing:

-------- snip --------
        0
   0x0000 - Reserved; allocation requires IETF Standards Action.

        1
   0x0001 - Andrews File Service v3.0 Location Service [RFC1183].

        2
   0x0002 - DCE/NCA root cell directory node [RFC1183].

        3 - 65,279
   0x0003 - 0xFEFF - Allocation by IETF Review.

   65,280 - 65,534
   0xFF00 - 0xFFFE - Private Use.

   65,535
   0xFFFF - Reserved; allocation requires IETF Standards Action.

-------- snip --------

A better layout with columnar alignment would look like this:

-------- snip --------

        0
   0x0000           Reserved; allocation requires IETF Standards Action

        1
   0x0001           Andrews File Service v3.0 Location Service [RFC1183]

        2
   0x0002           DCE/NCA root cell directory node [RFC1183]

        3 - 65,279
   0x0003 - 0xFEFF  Allocation by IETF Review

   65,280 - 65,534
   0xFF00 - 0xFFFE  Private Use

   65,535
   0xFFFF           Reserved; allocation requires IETF Standards Action

-------- snip --------

(Note: Trailing periods are not needed in the table; dropping these
 allows to adhere to the margins.)

e)
Similar considerations apply to the table in 3.2.

f)
Other SDOs use "Annex" for normative appendices, yes, but the
RFC Editor doesn't like that.  :-(
"Annex B" however is likely to be regarded as non-normative;
so "Annex" isn't a good match.

g)
FYI: Idnits yields funny comments.  :-)
(No action needed.)

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: Andrew Sullivan <[email-masked]>
Date: Fri, 19 Nov 2010 15:36:35 -0500

> clarification of who's to send to that address at which stage of the

Hrm.  You're right that this isn't consistent.  The actual workflow is
that we send the template to dns-rrtype-applications in order to
_start_ the review process.  IANA's ticketing system is a subscriber
to that list, and that's actually how they get the ticket.  So what's
in the annex is right.

I'm ok with cleaning this up, if nobody objects, since it's the same
sort of clean-up as the other goal of getting the address of where to
send discussion correct.

> the purpose indicated in Annex A?

Doesn't matter: this is the list we have.  Let's not tinker, please.

> expert(s) in an additional paragraph appended to 3.1.2.

No.  It's not used for anything other than submission.  That's how
we've actually done this, so let's stick with the practice as it
stands.

> The draft uses old (verbous++) "Status of This Memo" boilerplate.

This is actually on purpose, because we wanted diffs not to show up
extraneous things.  (Not that it was completely successful.)

> (using the xml2rfc <note> element inside <front>).

Well, that'd be entertaining in a draft that comes from nroff ;-)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.