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

Note: This ballot was opened for revision 24 and is now closed.

(Magnus Westerlund) Yes

(Ron Bonica) (was Discuss) No Objection

(Ross Callon) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

Comment (2010-01-21 for -)
No email
send info
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
...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.

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) No Objection

Comment (2010-01-20 for -)
No email
send info
I would object to this moving forward as standards track. I don't understand the argument it can not be experimental.

(Tim Polk) (was No Record, Discuss) No Objection