Hi John -

A few comments regarding your input to the Notify doc... In general, I had considered some of these but chose to ignore in order to start simply. 

1.  Yes, agree that there should be some registration identifier returned in the notify repsonse that can be used for canceling a notify later on.  Definately a good idea.

2.  Yes, more informative error code(s) could be returned.  But my concern is to not expose unauthorized information by merit of error codes.  But as long as it is fairly innocuous, I agree that more informative error codes can be more helpful.   In general though, error codes are second order issues since they normally should not happen:-)   For simplicity, I suggested we simply say "Yes you are registered for that event" or "No, your registration failed."  Minimally speaking, thats all you really need:-)

3. My concern about wildcards is not that they can't be implemented or that they don't scale, but that they incur substantial overhead since the code must check the condition *very time* one of the parameters change.   My only real reason for suggesting wildcards not be allowed was to start simply.  I believe the issue of monitoring state to detect qualifying events could incur *substantial* runtime overhead, and wll defintately make implementation far more complex.    We should be cautious about what we decalre to be "notifiable".   Defining the event conditions is easy, detecting when all the conditions that make up the event click together is hard. For example - everytime a parameter changes value, any and all condition it is part of must be evaluated.  Therefore, every time you update a parameter there must be a check made to see if any conditions are attached to the parameter, if there are then evaluate it, and then evaluate the event that condition is part of as well.    This must be done everytime any notifiable paramter is modified.   For this reason, I suggest we limit the set of parameters that can be used to define an notification event.

4. regarding a Notify Acknowledge...I didn't think an Ack was necessary on the assumption that the underlying transport was guaranteeing delivery of the message.  There are times when an NSA should acknowledge a message - specifically, when it incurs a commitment or cost not previously acknowledged.   But the Notify() action was already requested and registered, and if the transport layer still believes the target NSA is still reachable, then just sending the message should be (IMO) sufficient.  So I just didn't think an acknowledge was necessary...  If you require an Ack, then you need timers to handle a case where the Ack doesn;t come or takes too long, and ultimately, if it doesn't come - what would/should the PA do?

Summary questions on Notify() - These are all *Excellent* observations.  And I agree, they must be resolved before the Notify() can or should be specified as a NSI primitive.  And resolving these will take some time and discussion...and IMO make the protocol still more complex (read: error prone :-()    I sound like a stuck record, but I concur that all these questions should be answered before we can say they function in a clear and deterministic manner.


Regarding the size of messages in the QueryResp() message...  I agree there are many protocols that can support essentially unlimited size messages... If we need to do this, then we need to specify that protocol explicitly.  And we need to understand how we combine responses filtering up the tree...this is not done by the transport protocol but must be specified as part of the NSI protocol.     

Many good points John...thanks for looking it over.

We should also keep in mind a couple other things: 
--- Can the NSI CS Protocol work properly to manage the lifecycle of a connection if there is no Notify primitive or no Query primitive?     If we can, then maybe these are part of another NSI "service" and should not be part of the NSI CS primitives...?

--- How long will it take to resolve the Notify and Query primitive functionality ...do we want to wait that long to complete the  NSI V1.0 waiting for these primitives?   Perhaps these are good V2.0 features...?   (I think it might be best to do so in the interest of time.)

--- Since these are similar primitives, and one is highly similar to an SQL interface, perhaps we should try to define both as SQL interfaces to a well defined Relation DB schema that holds the information?   IMO, this sounds more and more like a separate NSI service....(but I could be wrong:-)

--- These primitives if fully functioned will be complex to implement, and costly to support in the code.  How might we reduce the complexity or enhance the run time efficiency?  

Talk to you all tomorrow!
Jerry

John MacAuley wrote:
Jerry,

I added a bunch of comments in red to the document.  We can discuss at the meeting tomorrow morning.

Thank you,
John.




On 2010-11-09, at 12:09 PM, Jerry Sobieski wrote:

Hi all-

I was to write up something on the Notify and Query Primitives...  here it is - at least a rough draft.   As usual, as we think these things through there are lots of considerations,   I tried to keep it simple to start.    I put down about 3 pages on Notify, and about 2 pages on Query.   High level stuff so it should not take you long to look it over.   I can summarize on the call Wednesday.

Best regards
Jerry
<NotifyQuery.docx>_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg

= 

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg