[Forces-protocol] Re: Section 6 update

ok, so once i get a section 6 from you that says - insert this - i will 
do the xml edit and will make that available to Robert - should he want 
it.

it would help, however, if you can send a diff between the 01-1 i sent 
out and what you do.  but if you are unable to do that, i will do it 
myself.

a.

On 22 okt 2004, at 13.50, Khosravi, Hormuzd M wrote:

> I think it would help in terms of readability to put in changes from 
> both Weiming and myself.
> I have sent an email to Robert to clarify his status as well...in any 
> case I will be making a few updates to section 6 to incorporate 
> Robert's comments.
>
> Thanks Avri,
> Hormuzd
>
> -----Original Message-----
> From: avri@psg.com [mailto:avri@psg.com]
> Sent: Friday, October 22, 2004 10:37 AM
> To: Khosravi, Hormuzd M
> Cc: hadi@znyx.com; Wang,Weiming; Ligang Dong; Robert Haas; 
> forces-protocol@ietf.org; ram.gopal@nokia.com
> Subject: Re: Section 6 update
>
> Am I supposed to integrate Hormuzd's  Section 6 update and then Robert
> will work on it?  Or is Robert going take it and and then I will
> integrate the reviewed/integrated Section 6?
>
> I was planning to do the later, but if necessary will do the
> intermediate integration - i.e. will put the changes into XML.  though
> I may not get to it for a few hours yet.
>
> a.
>
> On 22 okt 2004, at 12.37, Khosravi, Hormuzd M wrote:
>
>> No, I sent out the text directly. BTW, once Avri sends out an update I
>> can take care of making any more changes on section 6, if that is fine
>> with you.
>>  
>> Any update on the protocol LFBs ? Let me know if I should start of any
>> of the other sections, Header, State Machine ??
>>  
>> Thanks All !
>> Hormuzd
>>
>>
>> From: Robert Haas [mailto:rha@zurich.ibm.com]
>>  Sent: Friday, October 22, 2004 9:31 AM
>> To: Khosravi, Hormuzd M
>> Cc: Wang,Weiming; Ligang Dong; hadi@znyx.com; avri@psg.com;
>> ram.gopal@nokia.com; forces-protocol@ietf.org
>> Subject: Re: Section 6 update
>>
>> Hormuzd,
>> Do you have the xml for the update you posted ?
>> Thanks,
>> -Robert
>>
>> Khosravi, Hormuzd M wrote:
>>
>> Yes, having a new section for FE LFB, etc is a good idea.
>> Also, we can have a new section for the protocol State Machine (after
>> Protocol Messages)
>>  
>> regards
>> Hormuzd
>>
>>
>> From: Robert Haas [mailto:rha@zurich.ibm.com]
>>  Sent: Friday, October 22, 2004 2:33 AM
>> To: Wang,Weiming
>> Cc: Khosravi, Hormuzd M; Ligang Dong; hadi@znyx.com; avri@psg.com;
>> ram.gopal@nokia.com; forces-protocol@ietf.org
>> Subject: Re: Section 6 update
>>
>> Weiming.
>> I suggest we make a  new section "FE LFB and FE Protocol LFB" just
>> before Section 5 "Common Header", instead of leaving this to section
>> 3.3.2. This will reflect the importance of those two LFBs in the
>> operation of the protocol.
>>
>> I'll post my text when ready, please do the same, and we'll merge.
>>
>> -Robert
>>
>> Wang,Weiming wrote:
>>
>> Robert,
>>   
>> Don't worry too much about the FE LFB and Protocol LFB, I think it can
>> be fit it well in the sections.
>>  
>> Actually I can do something for Protocol LFB and FE LFB if you think
>> possible.
>>  
>> Regards,
>> Weiming
>>  
>> ----- Original Message -----
>>  From: Khosravi, Hormuzd M
>> To: Robert Haas
>> Cc: Ligang Dong ; hadi@znyx.com ; avri@psg.com ; ram.gopal@nokia.com ;
>> Weiming Wang ; forces-protocol@ietf.org
>> Sent: Friday, October 22, 2004 4:35 PM
>> Subject: Section 6 update
>>
>>
>> Hi Robert, All
>>
>>  
>>
>> Here you go...I have updated sections 6.1, 6.3, 6.6 (remove), 6.7
>> (same). I have directly used the text that Jamal sent out wherever
>> applicable.
>>
>> You can update sections 6.2, 6.4, 6.5 -> however, I would check with
>> Weiming first as courtesy since he is working on these sections.
>>
>>  
>>
>> BTW, there were lots of things in the todo list I sent out...
>>
>>  
>>
>> Header Section - Jamal/Robert/Weiming?
>>
>> Protocol LFB - Robert/Others?
>>
>> FE LFB - Robert/Others?
>>
>> CE LFB - ?
>>
>> State Machine for Protocol - Ligang (taken)
>>
>>  
>>
>> Will you be working on any of these ??
>>
>>  
>>
>> Pls do let us know...I will start working on whatever hasn't been
>> claimed by tomorrow morning my time.
>>
>>  
>>
>> Thanks
>>
>> Hormuzd
>>
>>  
>>
>>
>> From: Robert Haas [mailto:rha@zurich.ibm.com]
>>  Sent: Friday, October 22, 2004 12:39 AM
>> To: Khosravi, Hormuzd M
>> Cc: Ligang Dong; hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com;
>> Weiming Wang; forces-protocol@ietf.org
>> Subject: 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
>>
>> -- 
>> 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
>>
>> -- 
>> 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
>
>

_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol