Re: [Forces-protocol] RE: sync with BNF as discussed with model folks

I hope my note makes it before Jamal's noon ... Finally I got a 3 hours 
slot on a train ride (with phone off and no email access) to read the 
threads ...

In summary:

- I think it is good to keep the query separate from config. Reasons 
given by Steve/Zsolt sound very valid to me.

- I am glad to see the "consolidation" into FE Protocol LFB operations 
of FE attributes config, FE events, and association maintenance messages.

- The heartbeat message is currently not "targeted" at the FE protocol 
LFB. It is an exception to the rule. The reasoning was to keep such 
messages as short and simple as possible. Basically, you have the choice 
between a heartbeat to look like this:

main hdr (eg type = heartbeat)
      |
      |
      +--- T = LFBselect
               |
               +-- LFBCLASSID = FE Protocol LFB Class (=0x01)
               |
               |
               +-- LFBInstance = FE Protocol LFB Instance(=0x01)

or like this:

main hdr (eg type = heartbeat)

The difference is only 6-8 bytes (I don't remember what was the final 
consensus for the T in the TLV). But as the values in the LFBSelect TLV 
must ALWAYS be 0x01 and 0x01 (we have statically defined the class and 
instance ID of the FE protocol LFB), it is a waste to transmit them. And 
if you do, then someone might use wrong values and then you have to 
decide how to deal with such cases.

Regards,
-Robert

Jamal Hadi Salim wrote:

>On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote:
>
>  
>
>>Is there a reason you want to keep that type=query?
>>[HK] The responses will be more involved for query, 
>>also the request <path> might be more involved. 
>>    
>>
>
>This is true. But i dont know how you escape it with any scheme.
>If you ask to get, you must specify a path whether you use query or 
>config. I would think the response will also have a path and the
>requested data for that path.
>
>  
>
>>The other reason is that 
>>I have never seen query bundled with SET/DEL in practice...
>>    
>>
>
>I dont either; dont wanna rule it - but the more i think about it the
>more i am concluding its just about sending bundled commands. I think
>you can not possibly make it any simpler by introducing type=query.
>
>  
>
>>Is this a requirement from
>>Joel or the Model team ? I didn't get that impression, but I might have
>>missed it.
>>
>>    
>>
>
>I cant remember where it came or where the discussion took place.
>However, it does make logical sense given now that "everything is an
>LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to
>the same way: FE->LFBclass->LFBinstance->path
>Other than the operator, the operand to a GET is _exactly_ the same
>as a DEL. ADD has one extra operand.
>So its not really an issue of requirements; but one of a natural fit (as
>in the case of SNMP for example)
>If you can show that you can get an object easier with type=query i
>think that would help. Otherwise we would have an additional unneeded
>message.
>
>  
>
>>>6.3 -> looks good...we might still need the Flags, also the Event Type
>>>is needed since Event Subscribe, UnSubscribe are currently part of
>>>      
>>>
>>this
>>    
>>
>>>message.
>>>      
>>>
>>Probably makes sense to keep event subscription under config. Sorry
>>I missed that in my quick scan and thought it belonged to type=event in
>>6.4.
>>Do we then need operation = Event_un/subscribe [HK] Yes
>>I suspect that events will end up being defined in the LFB XML
>>definition and therefore will have a path to them (eg link event in port
>>LFB being path 1.2.3 etc).
>>In which case, the value of the Event_un/subscribe will be to the
>>event.
>>Thoughts? [HK] We could simplify this for generic events, but what
>>you're suggesting seems reasonable.
>>    
>>
>
>I think its safer to have the XML define what those events are. I sent a
>query to Joel who will forward it to the model team. He seems to be in
>agreement. Note this will be equivalent to SNMP traps (which is defined
>in the mib together with other attributes).
>As far as i can see, the event is another attribute. So it would look
>like:
>Operation = subscribe; operand = eventpath
>In our case we should go ahead and choose events that are necessary for
>the protocol to function and put them in eitehr the FE object or FE
>protocol LFB. The model team can them adapt from them
>  
>  
>
>>>6.6 -> Fine...I am assuming the States will be exchanged in Event msgs
>>>      
>>>
>>?
>>
>>Since everything is an LFB, then its per LFB event - in this case i
>>would guess the states will belong to the FE Object LFB? 
>>
>>[HK] Yes they would, I have no objection to FE Object or everything
>>being a LFB. The FE States would be part of the FE object sent in Event
>>msgs.
>>
>>    
>>
>
>Sounds reasonable.
>
>  
>
>>>6.7 -> remains the same (I assume)
>>>      
>>>
>>I missed that one, sorry.
>>Again my take is this is gone. I would think this would per FE
>>heartebats belong to the FE Protocol LFB.
>>[HK] No, this doesn't need to go, its just a header anyways, it doesn't
>>have any TLVs...its a very light weight msg, remember? I think you are
>>confusing this with the FE Protocol Object, that doesn't have any effect
>>on this msg.
>>    
>>
>
>But who is the target for this message now?
>Remember, there MUST be an LFB as the end target.
>
>  
>
>>I think that the two FE LFBs deserve speacial attention now.
>>We need to describe what they are expected to do in more detail. We also
>>need to sync on them with the model people.
>>[HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead
>>on defining this
>>
>>    
>>
>
>We may all have to be involved in these two. I think they are very
>important that we all need to be involved.
>
>BTW, Heres a suggestions:
>
>If we dont hear from anybody by Tuesday(I know Weiming mentioned
>something about being back Monday), lets start assuming noone will
>and move towards updating the draft to beat the deadline.
>I dont think people will mind if they are busy.
>
>cheers,
>jamal
>
>
>
>
>_______________________________________________
>Forces-protocol mailing list
>Forces-protocol@ietf.org
>https://www1.ietf.org/mailman/listinfo/forces-protocol
>
>
>  
>

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha