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 PROTECTED]>
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 PROTECTED]
Nokia Research Center Helsinki, Finland
