QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)
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 -)
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.
(Russ Housley) (was Discuss) No Objection
(Cullen Jennings) No Objection
Comment (2010-01-20 for -)
I would object to this moving forward as standards track. I don't understand the argument it can not be experimental.