Document: draft-ietf-tsvwg-rsvp-ipsec-03.txt Reviewer: Miguel Garcia 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 "