Subject: [Ltru] Last Call Comments: draft-ietf-ltru-registry-09

From: "Scott Hollenbeck" <[email-masked]>
Date: Fri, 15 Jul 2005 09:57:14 -0400

draft-ietf-ltru-registry-09 looks really good.  It's precise and complete as
far as I can tell.  I did find a few small issues, though:

Section 1, second-to-last paragraph:
Please add citations for RFCs 3066 and 1766.

- This document replaces RFC 3066, which replaced RFC 1766.
+ This document replaces RFC 3066 [RFC3066], which replaced RFC 1766
[RFC1766].

Section 2.1, first paragraph:
Please cite the ABNF specification in "ABNF %x2D".

- ABNF %x2D
+ ABNF [RFC2234bis] %x2D

Section 2.1, bottom of page 5:
Please cite a specification for US-ASCII since the text says "Note that
although [RFC2234bis] refers to octets, the language tags described in this
document are sequences of characters from the US-ASCII repertoire".

Section 2.1, top of page 6:
- capitalization of some of the subtags, but these MUST not be taken to
+ capitalization of some of the subtags, but these MUST NOT be taken to

Page 22, 5th paragraph:
"MAY NOT" is not an RFC 2119 imperative.  A change to "do not" might be
appropriate.

Section 3.6: What type of RFC is required?  Informational or Standards
Track?  Community-reviewed, or RFC-Editor published?  Does it matter?  It
might be helpful to cite one of the methods described in section 2 of RFC
2434 if one is appropriate.  Later text in the section says "although the
IESG MAY change the assignment when approving the RFC", so I have to believe
that we're talking about either an "IETF Consensus" or "Standards Action"
document.

-Scott-

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 15 Jul 2005 18:03:55 +0200

> - This document replaces RFC 3066, which replaced RFC 1766 
> + This document replaces RFC 3066 [RFC3066], which replaced
>   RFC 1766 [RFC1766].

In other words s,RFC 3066,<xref target="RFC3066" />, and
s,RFC 1766,<xref target="RFC 1766" />, combined with the
existing <?rfc symrefs="on" ?> resulting in

| This document replaces [RFC3066], which replaced [RFC1766].

> + ABNF [RFC2234bis] %x2D

I'd prefer to explain ABNF in chapter 1 together with used 2119
keywords (BTW, "SHALL NOT" isn't used, but Bruce is on vacation):

[...]
|    document are to be interpreted as described in [RFC2119].
+    The syntax is shown using the ABNF defined in [RFC2234bis].  

> Please cite a specification for US-ASCII

Reference stolen as is from the SPF RfC:
<reference anchor="US-ASCII">
  <front>
    <title>USA Code for Information Interchange, X3.4</title>
    <author>
      <organization abbrev="ANSI">
        American National Standards Institute (formerly United States of
        America Standards Institute)
      </organization>
    </author>
    <date year="1968"/>
  </front>
  <annotation>
    ANSI X3.4-1968 has been replaced by newer versions with
    slight modifications, but the 1968 version remains
    definitive for the Internet.
  </annotation>
</reference>

> "MAY NOT" is not an RFC 2119 imperative.

Do you have a tool for this stunt ?  It's even folded.

> A change to "do not" might be appropriate.

Or to SHALL NOT, fixing two nits at the same time.

> Section 3.6: What type of RFC is required?  Informational
> or Standards Track?  Community-reviewed, or RFC-Editor
> published?  Does it matter?

It matters, IMHO better than "informational" or "historic". 

> It might be helpful to cite one of the methods described in
> section 2 of RFC 2434 if one is appropriate.  Later text in
> the section says "although the IESG MAY change the assignment
> when approving the RFC", so I have to believe that we're
> talking about either an "IETF Consensus" or
> "Standards Action" document.

The former "IETF consensus" should be good enough, that would
allow experimental RfCs.  Also allowing RfC editor submissions
would be tricky:

It would be a mixture of "IESG approval" for the prefix letter,
some IESG review as for all RfC editor submissions, combined
with no approval (otherwise it would be very similar to "IETF
consensus" only bypassing the "IETF last call", bad idea).  If
the RfC editor insists on it the IESG would have to assign the
prefix letter anyway, but I still don't want an "informational"
RfC to screw up language tags.  So let's take "IETF consensus".

                         Bye, Frank