Subject: [Gen-art] Gen-Art Review: draft-ietf-nsis-qspec-22.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 21 Nov 2009 18:32:34 -0500

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?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 22 Nov 2009 15:29:18 -0500

If the problem is that the base documents are experimental, then I am 
very confused by the repeated references in the document to standards 
track documents for defining new state machine transitions.  If that 
state machines are standards track, it would seem that the QoS encodings 
for those state machines ought to be standards track as well.

If the state machines are not standards track, then it would seem that 
this document should be experimental, to match the rest of the set.

Yours,
Joel

Gerald Ash wrote:
> 
> 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 /<[email-masked]>/* wrote:
> 
> 
>     From: Joel M. Halpern <[email-masked]>
>     Subject: Gen-Art Review: draft-ietf-nsis-qspec-22.txt
>     To: "General Area Review Team" <[email-masked]>, "Mary Barnes"
>     <[email-masked]>
>     Cc: "Magnus Westerlun" <[email-masked]>, "IETF
>     discussion list" <[email-masked]>, [email-masked],
>     [email-masked]
>     Date: Saturday, November 21, 2009, 6:32 PM
> 
>     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.
> 
>     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.
>     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:
>     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?
> 
>

---

From: Gerald Ash <[email-masked]>
Date: Sun, 22 Nov 2009 12:15:46 -0800 (PST)

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 <[email-masked]> wrote:

From: Joel M. Halpern <[email-masked]>
Subject: Gen-Art Review: draft-ietf-nsis-qspec-22.txt
To: "General Area Review Team" <[email-masked]>, "Mary Barnes" <[email-masked]>
Cc: "Magnus Westerlun" <[email-masked]>, "IETF discussion list" <[email-masked]>, [email-masked], [email-masked]
Date: Saturday, November 21, 2009, 6:32 PM

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?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Nov 2009 09:34:48 +0100

Hi Joel and Jerry,

Yes, these are clearly left overs before forcing all the documents into
experimental. I commented in AD review about registration rules
requiring standards track. Which I believe is fixed, but the comments in
the document seems to not have been fixed.

Secondly I think we need to have a discussion on the intended status of
the document. I think I personally do have a preference for publication
as experimental. I agree that it defines so much of the data format and
its rules that it makes sense to have it on the experimental track,
rather than informational.

More views and arguments please.

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------