[Forces-protocol] Re: Applying changes to Section 6 (Protocol Messages)

Hormuzd,
Could you please pass the token on section 6 together with your latest 
version so I can start editing it ?
Thanks,
-Robert

Khosravi, Hormuzd M wrote:

> Robert,
>  
> As I said, your note mostly looks...I have put some more comments below...
> (It would help a lot if you start defining the FE, Protocol LFBs...)
> ------------------------------------------------------------------------
> From: Robert Haas [mailto:rha@zurich.ibm.com]
>
> All: below is a rough list of changes and pending issues regarding 
> section 6. Please review.
>
>  6.1.1 Association: The CE could obtain the HBI with a 
> Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg 
> strcutrue, we have to remove HBI from the Assoc Setup msg.  [Agreed, 
> this would be part of ProtocolLFB even if it is in this message] 
>
>  6.1.2 How has the srcID=0 case been handled in the interop tests ? Is 
> this really feasible ?  [Yes it worked fine during Interop] 
>
>  6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into 
> the FEProtocolLFB.  [Agreed it would be in some LFB, but not sure 
> which LFB this would be part of...?] 
>
>  6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note 
> that for the sake of symmetry, we should introduce a CEProtocolLFB.  
> [Sure, why dont you start defining some of these objects...then we can 
> discuss more in detail] 
>
>  6.6 State Maintenance: FE Activate/Deactivate/Shutdown become 
> settable attributes in the FEProtocolLFB.  [Yes, these messages will 
> be part of Events or Config...we need to specify this] 
>
>  6.7 HB remains as is.  [Agreed] 
>
> In summary, we have the following operations defined for each message 
> type ( I broke the table into 3 parts):
>  [looks good!] 
> OPERATION       APPLICABLE MESSAGE TYPES
>
>                 Assoc-Setup  Assoc-Setup-Resp Assoc-Teardown Heartbeat
>
> no operations
> defined
>
>
>                 Query  Query-Resp  Config  Config-Resp
> SET, DEL, UPDATE                     x          x
> GET               x         x
> EV_S, EV_U                           x          x
>
> (for event subscribe/unsubscribe)
>
>
>                 Packet-Redir
>
> PAYLOAD            x
>
>
>                 Event-Notif  Event-Notif-Resp
> EVENT              x                x
>
> Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we 
> have each time only one operation. Looks a bit redundant. Ideas ?  
> [These are all very different, lets leave them as is, its not 
> necessary to have multiple operations in all messages] 
>
> Regards,
> -Robert

-- 
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