Joel,
Thanks for the quick review. I agree with all your comments and suggestions.
Regarding your suggestion on RFC type (change it from Informational to PS), I
believe it could not become PS since the other NSIS documents (GIST & QoS-NSLP)
are Experimental.
Thanks again,
Jerry
--- On Sat, 11/21/09, Joel M. Halpern <jmh(_at_)joelhalpern(_dot_)com> wrote:
From: Joel M. Halpern <jmh(_at_)joelhalpern(_dot_)com>
Subject: Gen-Art Review: draft-ietf-nsis-qspec-22.txt
To: "General Area Review Team" <gen-art(_at_)ietf(_dot_)org>, "Mary Barnes"
<mary(_dot_)barnes(_at_)nortel(_dot_)com>
Cc: "Magnus Westerlun" <magnus(_dot_)westerlund(_at_)ericsson(_dot_)com>, "IETF
discussion list" <ietf(_at_)ietf(_dot_)org>, nsis(_at_)ietf(_dot_)org,
draft-ietf-nsis-qspec(_at_)tools(_dot_)ietf(_dot_)org
Date: Saturday, November 21, 2009, 6:32 PM
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 resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-nsis-qspec-22
QoS NSLP QSPEC Template
Reviewer: Joel Halpern
Review Date: 21-Nov-2009
IETF LC End Date: 25-Nov-2009
IESG Telechat date: N/A
Summary: This document is almost ready for publication as an RFC.
I am concerned about the RFC type. If a revision of the document is needed,
there are a few minor items to consider for inclusion.
Major:
I am unclear about whether the intended status (Informational) for this
document is correct.
At first, it seemed correct. The document is defined as providing a template
for a resource specification block (a QSPEC), and other model specific
documents are expected to define exactly what QoS paramters they will use.
It even seemed fine that this document mandates that the QSPEC include the
indication of the QoS Model. That is necessary information.
Where I start to have concerns is in section 3.1 of this document. There, the
document starts specifying requirements on any and of QoS Model documents. It
says things like "A QOSM specification MUST include the following:". If this
document is defining normative requirements for standards track documents (and
the text explicitly states that QOSM definitions sometimes need to be standards
track), then I don't see how it can be an informational document.
If the QOSM requirements, and the QSPEC support requirements ("The QSPEC
objects ... MUST be supported by QNEs.") are actually copied from some other
document, then the problem is a lesser issue of unclear referent. But if this
document is the source for these normative requirements, it does seem that
Informational is wrong.
Given that this document actually defines bits to be used on the wire, it may
be appropriate to publish it as a PS.
Alternatively, BCP may be acceptable, although a bit unusual.
The fact that this document defines the format of information fields and
includes the IANA registration for those fields to be used in QOSM documents
also suggests that informational is inappropriate as it would create a
conceptual dependence of all standards track QOSM documents on an Informational
RFC. Also, this document includes guidelines to follow in future IANA
allocations.
Minor:
In describing the constraints parameters, the text in section 3.3.2 carefully
describes the semantics, and the composition rule. However, it seems to leave
out the unit of measure. (The constraints are given in the detailed message
information formats section, but it would seem sensible to include them in
3.3.2.)
Editorial:
Should there be an editorial note when "minimum QoS" is first described
indicating that the term "minimum" is used generically, as for many parameters,
like loss rate or latency, what needs to be specified is the maximum acceptable
value?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf