[Forces-protocol] Re: Section 6 update

avri@psg.com Fri, 22 October 2004 17:45 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23958 for <forces-protocol-web-archive@ietf.org>; Fri, 22 Oct 2004 13:45:57 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3h5-00032o-OJ for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 13:59:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3QV-0001m8-LI; Fri, 22 Oct 2004 13:42:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3Lr-0008H4-9t for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 13:37:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23454 for <forces-protocol@ietf.org>; Fri, 22 Oct 2004 13:37:16 -0400 (EDT)
From: avri@psg.com
Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3Yf-0002uR-5Y for forces-protocol@ietf.org; Fri, 22 Oct 2004 13:50:34 -0400
Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9MHCrep027294; Fri, 22 Oct 2004 19:12:54 +0200
In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02FD8F7D@orsmsx408>
References: <468F3FDA28AA87429AD807992E22D07E02FD8F7D@orsmsx408>
Mime-Version: 1.0 (Apple Message framework v619)
Content-Type: text/plain; charset="WINDOWS-1252"; format="flowed"
Message-Id: <FF33DAB0-2450-11D9-9DB1-000393CC2112@psg.com>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 22 Oct 2004 13:37:08 -0400
To: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
X-Mailer: Apple Mail (2.619)
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb
Content-Transfer-Encoding: quoted-printable
Cc: ram.gopal@nokia.com, "Wang, Weiming" <wmwang@mail.hzic.edu.cn>, forces-protocol@ietf.org, hadi@znyx.com, Ligang Dong <donglg@mail.hzic.edu.cn>, Robert Haas <rha@zurich.ibm.com>
Subject: [Forces-protocol] Re: Section 6 update
X-BeenThere: forces-protocol@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: forces-protocol <forces-protocol.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/forces-protocol>
List-Post: <mailto:forces-protocol@ietf.org>
List-Help: <mailto:forces-protocol-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/forces-protocol>, <mailto:forces-protocol-request@ietf.org?subject=subscribe>
Sender: forces-protocol-bounces@ietf.org
Errors-To: forces-protocol-bounces@ietf.org
X-Spam-Score: 0.3 (/)
X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412
Content-Transfer-Encoding: quoted-printable

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