QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)
RFC 5975

[Ballot comment]
Given text in the Abstract...
  The QoS NSLP protocol is used to signal QoS reservations and is
  independent of a specific QoS model (QOSM) such as IntServ or
  DiffServ.
...I was surpriesed to find specific parameter IDs for class parameters
such as PHB, DSTE and Y.1541.

I'm assuming you considered and rejected a generic "Traffic Class"
parameter that could be used differently in different QoS models.

It might help the reader if you clarified that, although the base
protocol is QoS-model-agnostic, the parameters that can be carried in
the QSPEC object are possibly closely coupled to specific models.

---

Section 4.1

  The support of local QSPECs is a new and quite powerful capability,
  which is illustrated in Figure 4 for a single flow to show where the
  initiator and local QSPECs are used.

"new" compared to what? maybe just delete that point?

---

Some of your experimental code point ranges seem particularly large.
The reason for keeping the ranges small is to stop experimental values
from becoming de facto standards. You might consider reworking the
ranges in line with RFC3692.

[Ballot discuss]
Section 3.2, the first three objects are characterized as read-only or read-write.  The text
describing Minimum QoS implies that it is read-only, but it is not stated.  The text for the
QoS Desired and QoS Available messages note which NSLP messages these objects can appear
in, but this is unspecified for QoS Reserved and Minimum QoS.  I would guess that QoS
Reserved can only appear in RESPONSE and perhaps NOTIFY, and that Minimum QoS can
appear in any of the messages?

The implications of making Minimum QoS optional are not clear to me.  Does a QNE that does
not support Minimum QoS ignore this object or reject the message?  If the object is ignored,
the QNI could receive a RESPONSE where QoS Reserved is less than Minimum QoS.  If the
message is rejected, the QNI may be denied service where acceptable levels of service were
available.

Section 4.3.2, Case 3 implies an overloading of the QoS Available semantics in the absence of
a Minimum QoS object:

  Some parameters in the QoS Available object may the same as in the
  QoS Desired object.  For these parameters the implicit message is
  that the sender would be satisfied by a reservation with lower
  parameter values than specified in QoS Desired.

Differentiating this overloading from a case where the QNI does not support Minimum QoS
is not straightforward to this reader, or how this would change the behavior of a QNE
processing the message.

[Ballot discuss]
Section 3.2, the first three objects are characterized as read-only or read-write.  The text
describing Minimum QoS implies that it is read-only, but it is not stated.  The text for the
QoS Desired and QoS Available messages note which NSLP messages these objects can appear
in, but this is unspecified for QoS Reserved and Minimum QoS.  I would guess that QoS
Reserved can only appear in RESPONSE and perhaps NOTIFY, and that Minimum QoS can
appear in any of the messages?

The implications of making Minimum QoS optional are not clear to me.  Does a QNE that does
not support Minimum QoS ignore this object or reject the message?  If the object is ignored,
the QNI could receive a RESPONSE where QoS Reserved is less than Minimum QoS.  If the
message is rejected, the QNI may be denied service where acceptable levels of service were
available.

Section 4.3.2, Case 3 implies an overloading of the QoS Available semantics in the absence of
a Minimum QoS object:

  Some parameters in the QoS Available object may the same as in the
  QoS Desired object.  For these parameters the implicit message is
  that the sender would be satisfied by a reservation with lower
  parameter values than specified in QoS Desired.

[Ballot discuss]
Section 3.2, the first three objects are characterized as read-only or read-write.  The text
describing Minimum QoS implies that it is read-only, but it is not stated.  The text for the
QoS Desired and QoS Available messages note which NSLP messages these objects can appear
in, but this is unspecified for QoS Reserved and Minimum QoS.  I would guess that QoS
Reserved can only appear in RESPONSE and NOTIFY, and that Minimum QoS can appear in any
of the messages?

The implications of making Minimum QoS optional are not clear to me.  Does a QNE that does
not support Minimum QoS ignore this object or reject the message?  If the object is ignored,
the QNI could receive a RESPONSE where QoS Reserved is less than Minimum QoS.  If the
message is rejected, the QNI may be denied service where acceptable levels of service were
available.

[Ballot discuss]
Because this document defines bits on the wire, RSVP behaviors etc, it feels much more like it should be PS than EXP. I realize that the IETF has published protocol documents as experimental before (e.g., PIM). However, I don't think that that was very wise on our part.

[Ballot discuss]
The Gen-ART Review of this document was performed by Joel Halpern,
  and Joel raised an issue in IETF Last Call that was not really
  resolved, at least not from my perspective.

  The document talks about standard NSLP behaviors; it talks about
  standard QSPECs; it defines bits on the wire; and, it defines rules
  that other documents MUST follow.  So, the document looks like a
  standards-track document.  The document requires a standards-track
  document to modify "standard" NSLP behaviors.  This seems like an
  serious inconsistency with the intent to publish this document as
  an Experimental RFC.

IANA has several questions about this document.

ACTION 1:

IANA will create the following registry at
http://www.iana.org/assignments/TBD

Registry Name:
Registration Procedure:
0-63: Specification Required


Value Description Reference
----- -------------- ---------
0 QoS Desired [RFC-nsis-qspec-22]
1 QoS Available [RFC-nsis-qspec-22]
2 QoS Reserved [RFC-nsis-qspec-22]
3 Minimum QoS [RFC-nsis-qspec-22]
4-63 Unassigned
64-127 Private/Experimental Use [RFC-nsis-qspec-22]
128-4095 Reserved [RFC-nsis-qspec-22]

QUESTION: The document assigns 0-3 values and defines the registration
rules for values 5-4095. The value 4 is not clearly defined. We assumed
4 is unassigned and under the registration rules for 4-63. Please confirm.


ACTION 2:

IANA will create the following registry at
http://www.iana.org/assignments/TBD

Registry Name: NSIS QSPEC Version
Registration Procedures: Specification Required

Value Description Reference
----- -------------- ---------
0 Version 0 QSPEC [RFC-nsis-qspec-22]
1-15 Unassigned


ACTION 3:

IANA will create the following registry at
http://www.iana.org/assignments/TBD

Registry Name: NSIS QSPEC Type
Registration Procedure: Specification Required

Value Description Reference
----- -------------- ---------
0 Default [RFC-nsis-qspec-22]
1-12 Unassigned
13-16 Local/Experimental Use [RFC-nsis-qspec-22]
17-31 Reserved [RFC-nsis-qspec-22]

QUESTION: The document defines a registration rule for code points from 0
up to 32. However, the range of the field is 5 bits, which implies 0 to
31. Is the maximum 31 or 32?


ACTION 4:

IANA will create the following registry at
http://www.iana.org/assignments/TBD

Registry Name: NSIS QSPEC Procedure
Registration Procedure: Specification Required

MSG.|OBJ.|OBJECTS INCLUDED |OBJECTS INCLUDED |OBJECTS INCLUDED
SEQ.|COM.|IN QUERY MESSAGE |IN RESERVE MESSAGE |IN RESPONSE MESSAGE|
Reference
-------------------------------------------------------------------
0 |0 |N/A |QoS Desired |QoS Reserved
[RFC-nsis-qspec-22]
0 |1 |N/A |QoS Desired |QoS Reserved
[RFC-nsis-qspec-22]
0 |1 |N/A |QoS Available |QoS Available
[RFC-nsis-qspec-22]
0 |2 |N/A |QoS Desired |QoS Reserved
[RFC-nsis-qspec-22]
0 |2 |N/A |QoS Available |QoS Available
[RFC-nsis-qspec-22]
0 |2 |N/A |Minimum QoS |
1 |0 |QoS Desired |QoS Desired |QoS Reserved
[RFC-nsis-qspec-22]
1 |1 |QoS Desired |QoS Desired |QoS Reserved
[RFC-nsis-qspec-22]
| |Minimum QoS |QoS Available |QoS Available
[RFC-nsis-qspec-22]
| | |(Minimum QoS) |
1 |2 |QoS Desired |QoS Desired |QoS Reserved
[RFC-nsis-qspec-22]
| |QoS Available |QoS Available |
2 |0 |QoS Available |N/A |QoS Available
[RFC-nsis-qspec-22]


QUESTION: Apart from the Mes. Seq. number and the Obj. Com. number, the
table shown in the document lists 3 additional columns titled "OBJECTS
INCLUDED IN ... MESSAGE". Should the registry contain these additional
columns?


ACTION 5:

IANA will create the following registry at
http://www.iana.org/assignments/TBD

Registry Name: NSIS QSPEC Error Code
Registration Procedure: Specification Required

Value Description Reference
----- ------------- ---------
0-127 Unassigned [RFC-nsis-qspec-22]
128-255 Private/Experimental Use [RFC-nsis-qspec-22]
255-65535 Reserved [RFC-nsis-qspec-22]


ACTION 6:

IANA will create the following registry at
http://www.iana.org/assignments/TBD

Registry Name: NSIS QSPEC Parameter ID
Registration Procedure: Specification Required

Value Description Reference
----- ------------- ---------
1 TMOD-1 [RFC-nsis-qspec-22]
2 TMOD-2 [RFC-nsis-qspec-22]
3 Path Latency [RFC-nsis-qspec-22]
4 Path Jitter [RFC-nsis-qspec-22]
5 Path PLR [RFC-nsis-qspec-22]
6 Path PER [RFC-nsis-qspec-22]
7 Slack Term [RFC-nsis-qspec-22]
8 Preemption Priority & Defending Priority [RFC-nsis-qspec-22]
9 Admission Priority [RFC-nsis-qspec-22]
10 RPH Priority [RFC-nsis-qspec-22]
11 Excess Treatment [RFC-nsis-qspec-22]
12 PHB Class [RFC-nsis-qspec-22]
13 DSTE Class Type [RFC-nsis-qspec-22]
14 Y.1541 QoS Class [RFC-nsis-qspec-22]
15-255 Unassigned
256-1024 Private/Experimental Use [RFC-nsis-qspec-22]
1025-4095 Reserved [RFC-nsis-qspec-22]


ACTION 7:

IANA will create the following registry at
http://www.iana.org/assignments/TBD

Registry Name: NSIS QSPEC Y.2171 Admission Priority Parameter
Registration Procedure: Specification Required

Value Description Reference
----- -------------------------- ---------
0 best-effort priority flow [RFC-nsis-qspec-22]
1 normal priority flow [RFC-nsis-qspec-22]
2 high priority flow [RFC-nsis-qspec-22]
3-63 Unassigned
64-255 Reserved [RFC-nsis-qspec-22]


ACTION 8:

QUESTION: The document states the following:

RPH Namespace Parameter (16 bits):
Note that [RFC4412] creates a registry for RPH Namespace and Priority
values already (see Section 12.6 of [RFC4412]), and an extension to
this registry is created in [EMERGENCY-RSVP], which will also be used
for the QSPEC RPH parameter. In the extended registry, "Namespace
Numerical Values" are assigned by IANA to RPH Namespaces and
"Priority Numerical Values" are assigned to the RPH Priority.

The instructions are not clear to what IANA should do. Please
provide a more detailed explanation.


ACTION 9:

IANA will create the following registry at
http://www.iana.org/assignments/TBD

Registry Name: NSIS QSPEC Excess Treatment Parameter
Registration Procedures: Specification Required

Value Description Reference
----- -------------------------- ---------
0 drop [RFC-nsis-qspec-22]
1 shape [RFC-nsis-qspec-22]
2 remark [RFC-nsis-qspec-22]
3 no metering or policing is [RFC-nsis-qspec-22]
permitted
4-63 Unassigned
64-255 Reserved [RFC-nsis-qspec-22]


ACTION 10:

IANA will create the following registry at
http://www.iana.org/assignments/TBD

Registry Name: NSIS QSPEC Remark Value
Registration Procedure: Specification Required

Value Description Reference
----- -------------------------- ---------
0-63 Unassigned [RFC-nsis-qspec-22]
64-127 Private/Experimental Use [RFC-nsis-qspec-22]
128-255 Reserved [RFC-nsis-qspec-22]

QUESTION: This registry do not seem to have any initial assignments.
Please confirm.


ACTION 11:

IANA will create the following registry at
http://www.iana.org/assignments/TBD

Registry Name: NSIS QSPEC Y.1541 QoS Class Parameter
Registration Procedure: Specification Required

Value Description Reference
----- -------------------------- ---------
0 Y.1541 QoS Class 0 [RFC-nsis-qspec-22]
1 Y.1541 QoS Class 1 [RFC-nsis-qspec-22]
2 Y.1541 QoS Class 2 [RFC-nsis-qspec-22]
3 Y.1541 QoS Class 3 [RFC-nsis-qspec-22]
4 Y.1541 QoS Class 4 [RFC-nsis-qspec-22]
5 Y.1541 QoS Class 5 [RFC-nsis-qspec-22]
6 Y.1541 QoS Class 6 [RFC-nsis-qspec-22]
7 Y.1541 QoS Class 7 [RFC-nsis-qspec-22]
8-63 Unassigned
64-255 Reserved [RFC-nsis-qspec-22]

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd is Martin Stiemerling (NSIS WG co-chair).
I have reviewed the document and see it ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has received extensive reviews from NSIS WG
members and also from external reviewers.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

Nothing needed.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The document has been reviewed multiple times and has been
extensively discussed within the WG with finally reaching
consensus.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The current document has no issues caught in the idnits
review'; i.e., the document passes all the idnits checks.
However, there are some erroneous idnits 'warnings', where
idnits does not recognize references, although they are
present.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References are properly split into normative and
informative. There are no normative references to documents
not ready for advancement.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

There is an IANA section and its defines the required
registries.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Not applicable for this document.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
The QoS NSLP protocol is used to signal QoS reservations and is
independent of a specific QoS model (QOSM) such as IntServ or
DiffServ. Rather, all information specific to a QOSM is encapsulated
in a separate object, the QSPEC. This document defines a template
for the QSPEC including a number of QSPEC parameters. The QSPEC
parameters provide a common language to be re-used in several QOSMs
and thereby aim to ensure the extensibility and interoperability of
QoS NSLP. The node initiating the NSIS signaling adds an initiator
QSPEC, which indicates the QSPEC parameters that must be interpreted
by the downstream nodes less the reservation fails, thereby ensuring
the intention of the NSIS initiator is preserved along the signaling
path.


Working Group Summary
There have been several WGLC on the document, plus several pre-WGLCs
on the document. The editors have gotten extensive feedback from the WG
and outside of the WG.



Document Quality
This document was reviewed by the working group chair as well as the
WG. We feel that this document is ready.