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

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Dec 2006 10:11:21 +0100

It seems this got lost somewhere in list moderation.

      Brian

Subject: Re: Gen-ART LC review of draft-ietf-tsvwg-rsvp-ipsec-03.txt
From: Francois Le Faucheur IMAP <[email-masked]>
To: Miguel Garcia <[email-masked]>
Cc: Francois Le Faucheur IMAP <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], General Area Review Team <[email-masked]>, James Polk <[email-masked]>, Magnus Westerlund <[email-masked]>, Lars Eggert <[email-masked]>
Date: Tue, 26 Dec 2006 12:10:36 +0100

Hello Miguel,

Just wanted to thank you for your review and comments. I have  
addressed your comments in the next revision that I am working on.

Francois.

On 10 Oct 2006, at 13:24, Miguel Garcia wrote:

> 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