Subject: [NSIS] QSPEC2: State machine text part in QSPEC I-D

From: Martin Stiemerling <[email-masked]>
Date: Tue, 6 Feb 2007 14:55:24 +0100

Well, I have not yet seen consensus about this issue.

Georgios proposed this text:

"QOSMs all utilize the state machines of the underlying NSIS  
protocols and are not  expected  to re-define or extend these in any  
way. Note that a QOSM can however, extend the RMF triggers to/from  
the QOS-NSLP functionality, which might affect the QoS-NSLP state  
machine."

I personally also see that sentence 1 and 2 are contradicting each  
other at least partially. The first sentence is not allowing to  
extend the state machinery of the underlying NSIS protocols, where  
the second sentence is is opening the door for extending it.

However, I don't see any real technical issue here, but more a  
wording issue.

I'm not a good wording expert here, but the base lines seems to be:
1) QOSMs cannot change the semantics (and thus state machine) of the  
underlying QoS NSLP and GIST. (A standards track document is required  
for doing so).
2) QOSMs can send triggers to the QoS NSLP. These trigger can cause  
the QoS NSLP to run its semantics. Basically the " affect the QoS- 
NSLP state machine." is not very clear to readers. Yes, it affects  
the state machine, but only by giving a reason for an initial state  
transition (e.g., send RESERVE).

So, I'm now waiting for the big, loud scream of what is wrong here. :-)

   Martin

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis