Subject: [Gen-art] Gen-ART LC review of draft-ietf-tsvwg-rsvp-ipsec-03.txt

From: Miguel Garcia <[email-masked]>
Date: Tue, 10 Oct 2006 14:24:45 +0300

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-ietf-tsvwg-rsvp-ipsec-03.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date:  October 10th, 2006
IESG Telechat date: 12 October 2006

Summary: The document is ready for publication as a PS RFC.

Comments: A comment about the IANA registration Section should be fixed. 
Some other, mostly editorial, comments that you may want to fix as well.

- Section 7, IANA Considerations. I didn't find a reference to the 
registry (and subregistry, if applicable), where IANA has to operate. I 
am also wondering if including references to the policy for allocation 
helps IANA or not, probably not, in which case, I would suggest to have 
a firm proposal that does not refer IANA to look at that policy.

The first paragraph in Section 7 currently reads:

    This document requests that IANA allocates two new C-Types under the
    existing SESSION Class (Class 1) for the two new RSVP objects
    defined in section 2.1: GENERIC-AGGREGATE-IP4 SESSION and GENERIC-
    AGGREGATE-IP6 SESSION. This allocation is in accordance with [RSVP-
    MOD] which defines the default assignment policy as Standards Action
    for new Class-Type values under an existing class.

Suggest rewording:

This document requests IANA to modify the RSVP parameters registry, 
'Class Names, Class Numbers, and Class Types' subregistry, and assign 
two new C-Types under the existing SESSION Class (Class number 1), as 
suggested below:

Class
Number  Class Name                            Reference
------  -----------------------               ---------

      1  SESSION                               [RFC2205]

         Class Types or C-Types:

          xx   GENERIC-AGGREGATE-IP4           [RFCXXXX]
          yy   GENERIC-AGGREGATE-IP6           [RFCXXXX]

[Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 
number of this specification. Suggested values: xx=17, yy=18]

And then the second paragraph in Section 7 reads:

    This document also requests that IANA allocates one new Class-Num for
    the SESSION-OF-INTEREST class, and two new C-Types for the two new
    RSVP objects under that class defined in section 2.2: GENERIC-AGG-
    IP4-SOI and GENERIC-AGG-IP6-SOI. The Class-Num for the SESSION-OF-
    INTEREST class is to be allocated in the range from 128 to 183
    defined in [RSVP-MOD] as to be assigned by Standards Action. In
    accordance with [RSVP-MOD], the Class-Type values under the SESSION-
    OF-INTEREST class are to be allocated according to the following
    policy:
      o C-Type values from 0 through 127 are to be assigned by Standards
         Action
      o C-Type values from 128 through 191 are to be assigned by Expert
         Review
      o C-Type values from 192 through 255 are reserved for Vendor
         Private use
      o C-Type value 1 is to be allocated to the GENERIC-AGG-IP4-SOI
         object defined in this document
      o C-Type value 2 is to be allocated to the GENERIC-AGG-IP6-SOI
         object defined in this document.

I would rewording along the following lines:

This document also requests IANA to modify the RSVP parameters registry, 
'Class Names, Class Numbers, and Class Types' subregistry, and assign 
one new Class Number for the SESSION-OF-INTEREST class and two new 
C-Types for that class, according to the following table below:

Class
Number  Class Name                            Reference
------  -----------------------               ---------

    zzz  SESSION-OF-INTEREST                   [RFCXXXX]

         Class Types or C-Types:

           aa  GENERIC-AGG-IP4-SOI             [RFCXXXX]
           bb  GENERIC-AGG-IP6-SOI             [RFCXXXX]

[Note to IANA and the RFC Editor: Please replace RFCXXXX with the RFC 
number of this specification. Suggested values: zzz=132 aa=1, bb=2]

Some other minor comments:

- Please run the idnits tools at http://tools.ietf.org/tools/idnits/ and 
fix the reported errors:

     Checking conformance with RFC 3978/3979 boilerplate...

   * The document seems to lack an RFC 3979 Section 5, para 2 IPR Disclosure
     Acknowledgement -- however, there's a paragraph with a matching 
beginning.
     Boilerplate error?
   * There are 6 instances of too long lines in the document, the 
longest one
     being 1 character in excess of 72.

   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
   - It seems as if not all pages are separated by form feeds - found 0 form
     feeds but 26 pages

   Miscellaneous warnings:
   - Line 32 has weird spacing: '...   and  may be...'
   - Line 272 has weird spacing: '...rations  are...'

- There is a section whose title is "Specification of Requirements". 
This section lacks a number. Typically, it is numbered, and perhaps 
located after the Introduction. Then this section is typically titled 
"Terminology", and the text should point to BCP 14. A suggested 
rewording of this paragraph:

    In this document, the key words "MUST", "MUST NOT", "REQUIRED",
    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
    RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
    described in BCP 14, RFC 2119 [KEYWORDS] and indicate requirement
    levels for compliant implementations.

- Probably the RFC Editor will request to expand all the acronyms the 
first time they are used. This affects to RSVP (in the title), DSCP 
(abstract), PHB, etc.

- I would suggest to include a Figure number and a caption to each 
figure. For example, below Figure 1 there are a couple of unnumbered 
figures. The same applies for the figures in Sections 2.1, 2.2, and so on.

- I find odd that Section 1.1. mentions "Internet-Drafts". The fact that 
a document is an Internet-Draft is merely temporal, so those documents 
will cease to be Internet-Drafts, at some point in time. So I would 
suggest to rename the title of Section 1.1 as "Related technical 
documents" or something like that.

- In Section 2, 5th paragraph, the text reads:
"This specification only defines the use of the GENERIC-AGG-IP4-SOI
  and GENERIC-AGG-IP6-SOI objects in two circumstances: "

I am wondering if the "only" applies to "defines" or to "in two 
circumstances". I suspect (but please check) that what you want to say is:

"This specification defines the use of the GENERIC-AGG-IP4-SOI
  and GENERIC-AGG-IP6-SOI objects, which are applicable only in two
  circumstances: "

- Avoid the usage of the future tense, unless strictly needed. For 
example, in the first paragraph under Section 3.1, replace:

    "Both RESV and PATH processing will need to be changed to support the
    new objects. "

with

    "Both RESV and PATH processing need to be changed to support the
    new objects. "

- In Section 3.1, 4th paragraph from the bottom, I wonder whether the 
normative "MAY" is really normative or not. In my opinion, it does not 
indicate any protocol option, but looks like an additional 
implementation option that does not have impact on the protocol:

        o When the RSVP-AGGREGATE FILTER_SPEC is used and the SESSION
           type is GENERIC-AGGREGATE, each node MAY have a data
           classifier installed for the flow:

- Section 4, 8th paragraph: I would suggest to remove "in this 
document". So replace:

"However, in this document, the Deaggregator MUST use ..."

with

However, a Deaggregator behaving according to this specification MUST use "

Best regards,

         Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art