From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 03 10:26:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KCI-0001XU-AE for forces-archive@megatron.ietf.org; Wed, 03 Aug 2005 10:26:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21526 for ; Wed, 3 Aug 2005 10:26:16 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Kik-0003xK-Pi for forces-archive@IETF.ORG; Wed, 03 Aug 2005 11:00:06 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010BD8AF@cherry.ease.lsoft.com>; Wed, 3 Aug 2005 10:25:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81292300 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 3 Aug 2005 10:25:53 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 3 Aug 2005 10:25:53 -0400 Received: from [86.255.10.220] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11717739 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 03 Aug 2005 10:25:52 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050803102501.02f70fd8@localhost> Date: Wed, 3 Aug 2005 10:25:54 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Fwd: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to Proposed Standard To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable For peoples information, DCCP is now approved for publication as a PS. Yours, Joel >From: The IESG >To: IETF-Announce >Date: Wed, 03 Aug 2005 10:13:54 -0400 >Subject: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to= =20 >Proposed Standard > >The IESG has approved the following document: > >- 'Datagram Congestion Control Protocol (DCCP) ' > as a Proposed Standard > >This document is the product of the Datagram Congestion Control Protocol >Working Group. > >The IESG contact persons are Allison Mankin and Jon Peterson. > >A URL of this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-dccp-spec-11.txt > >*=C2 =C2 Technical Summary > >The Datagram Congestion Control Protocol (DCCP) is a transport >protocol that provides bidirectional unicast connections of >congestion-controlled unreliable datagrams.=C2 DCCP is suitable for >applications that transfer fairly large amounts of data, but can >benefit from control over the tradeoff between timeliness and >reliability.=C2 TCP is not well-suited for these applications, since >reliable in-order delivery and congestion control can cause >arbitrarily long delays.=C2 UDP avoids long delays, but UDP applications >that implement congestion control must do so on their own.=C2 DCCP >provides built-in congestion control, including ECN support, for >unreliable datagram flows, avoiding the arbitrary delays associated >with TCP.=C2 It also implements mechanisms for reporting loss, reliable >connection setup, teardown, and feature negotiation.=C2 The congestion >control mechanisms are defined in Congestion Control Profile >documents, known as CCIDs. > >=C2 =C2 =C2 =C2 *=C2 =C2 Working Group Summary > >There is a strong working group consensus to develop this protocol. >The applicability of DCCP to interactive real-time multimedia flows has >been somewhat controversial in the working group. The DCCP protocol >specification has been developed with just two initial congestion control >profiles, companions to this publication, draft-ietf-dccp-ccid2, and >draft-ietf-dccp-ccid3. However, the modular nature of the protocol >enables the core specification to be completed while work proceeds >on congestion control profiles for interactive real-time applications. >There is clear and strong support for applying DCCP to non-realtime >streaming and growing interest in other applications as well. > > >=C2 =C2 =C2 =C2 *=C2 =C2 Protocol Quality > >DCCP has received extensive transport and cross-disciplinary review. >Written "expert reviews" were conducted by Eric Rescorla (a security >expert), Magnus Westerlund (a multimedia expert and AVT wg chair), and >Greg Minshall (a TCP expert), generating many detailed comments and >substantive improvements in the protocol.=C2 The expert review was >followed by a working group "design review" at IETF-57 where the >working group and invited experts -- Magnus Westerlund (multimedia), >Steve Bellovin (security), and Rob Austein (architecture) -- walked >through the spec in detail resulting in additional comments and >substantive changes.=C2 Additionally, formal modeling was performed >showing that DCCP is deadlock-free.=C2 The protocol is as mature as is >possible without significant implementation experience.=C2 The three >known implementations were started early in the life of the >specification and one (from ICIR) resulted in some relatively major >changes to the spec.=C2 Recently, it has become known that Kame FreeBSD >contains an implementation of DCCP, albeit not matching the final >version of the spec.=C2 It is expected that feedback from implementors >and users will result in further improvements and revisions. > >The IESG review of the specification was done by Allison Mankin. >The WG Chair shepherd was Aaron Falk. > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 03 19:48:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0SyO-0007sJ-3i for forces-archive@megatron.ietf.org; Wed, 03 Aug 2005 19:48:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26550 for ; Wed, 3 Aug 2005 19:48:29 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0TV5-0002HQ-4S for forces-archive@IETF.ORG; Wed, 03 Aug 2005 20:22:24 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010BDEAD@cherry.ease.lsoft.com>; Wed, 3 Aug 2005 19:48:25 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81337186 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 3 Aug 2005 19:48:24 -0400 Received: from 209.119.0.160 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 3 Aug 2005 19:48:24 -0400 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <12.00910B71@almond.ease.lsoft.com>; Wed, 3 Aug 2005 19:48:24 -0400 Message-ID: Date: Wed, 3 Aug 2005 19:48:24 -0400 Reply-To: Dong Ligang Sender: Forwarding and Control Element Separation From: Dong Ligang Subject: Re: Fwd: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to Proposed Standard To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Yes, it is probably time to replace TCP-TCP using TCP-DCCP . The performance evaulation is required to use it in TML. From owner-ietf-pkix@mail.imc.org Wed Aug 03 20:12:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0TLf-00075e-2W for pkix-archive@megatron.ietf.org; Wed, 03 Aug 2005 20:12:35 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27405 for ; Wed, 3 Aug 2005 20:12:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73NTMoP096819; Wed, 3 Aug 2005 16:29:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j73NTM5H096818; Wed, 3 Aug 2005 16:29:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j73NTLaR096812 for ; Wed, 3 Aug 2005 16:29:21 -0700 (PDT) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1E0Sfn-00084C-8U; Wed, 03 Aug 2005 23:29:20 +0000 Message-ID: <42F1534F.8050706@drh-consultancy.demon.co.uk> Date: Thu, 04 Aug 2005 00:29:19 +0100 From: Stephen Henson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pg@futureware.at CC: "'ietf-pkix@imc.org'" Subject: Re: Qualified Certificate Requests - Signature vs. Certificate References: <200508022213.56523.pg@futureware.at> <200508032352.26083.pg@futureware.at> <42F1413B.1090905@drh-consultancy.demon.co.uk> <200508040039.37080.pg@futureware.at> In-Reply-To: <200508040039.37080.pg@futureware.at> Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id UAA27405 Philipp G=FChring wrote: >=20 >>>Including a certificate as an OCTETSTRING into a CSR? >> >>Note the "or a reference to one" including a URI where it could be >>downloaded would have a smaller overhead. >=20 >=20 > The problem is that the scenario is a normal user requesting a qualifie= d=20 > certificate.=20 > The keypair is generated directly before the request is sent. If it wer= e=20 > generated by the vendor before, it would make sense to put the certs on= a=20 > server. But that=B4s not the case. > And the request should be processed as fast as possible. I don=B4t see = where a=20 > normal user has a webserver available, where the PKCS#11 driver or CSP = could=20 > upload the certificate. And I don=B4t think that the user will be happy= doing=20 > that himself. > So referencing an external certificate is not an option, I would say. >=20 I should've qualified the statement. Its clear now I've read the full details that a certificate isn't appopriate to sign the public key of a smart card key. Where it might be appropriate is in signing the vendor's key for trust purposes, see below. >=20 >>Ah now that's another issue. Would this "vendor key" be the same on eac= h >>smartcard or different for each one? Presumably it would have to be >>different for each vendor? >=20 > Every vendor has his own key, or a couple of keys, perhaps one for each= kind=20 > of device the vendor produces. Let=B4s say normally a vendor should hav= e <10=20 > keys. But definitly not for every single device. >=20 So how does a CA processing the CSR and vendor key know that it can trust the vendor's key? That's a case where I believe certificates could have a role. An authority could certify each vendor key and the vendor would include references to this information in the form of a URI on its site. Steve. --=20 Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 03 20:10:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0TJd-0006cj-TV for forces-archive@megatron.ietf.org; Wed, 03 Aug 2005 20:10:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27330 for ; Wed, 3 Aug 2005 20:10:26 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0TqM-0002zj-HA for forces-archive@IETF.ORG; Wed, 03 Aug 2005 20:44:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010BDD48@cherry.ease.lsoft.com>; Wed, 3 Aug 2005 20:10:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81338979 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 3 Aug 2005 20:10:24 -0400 Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 3 Aug 2005 20:10:23 -0400 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j740A9CT012993; Thu, 4 Aug 2005 00:10:09 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j740A6VV009008; Thu, 4 Aug 2005 00:10:09 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005080317100629433 ; Wed, 03 Aug 2005 17:10:06 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 17:09:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Fwd: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to Proposed Standard Thread-Index: AcWYhdonrxDE1CHbQjaIM+Rz7Hs9zQAAqY/A X-OriginalArrivalTime: 04 Aug 2005 00:09:58.0708 (UTC) FILETIME=[D9CE5740:01C59888] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Khosravi, Hormuzd M" Message-ID: <468F3FDA28AA87429AD807992E22D07E0637C633@orsmsx408> Date: Wed, 3 Aug 2005 17:09:57 -0700 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Fwd: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to Proposed Standard Comments: To: Dong Ligang To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Yes indeed. And in order to do a performance evaluation we need a stable implementation of this protocol (preferably on Linux) that can be tested against TCP. I have been looking for one for more than a year now and haven't had any luck. I know that Jamal was guiding someone in the Linux community to work on this but not sure if that resulted in a stable DCCP implementation. If anyone has more info on this pls do let us know. Thanks Hormuzd=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Dong Ligang Sent: Wednesday, August 03, 2005 4:48 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Fwd: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to Proposed Standard Yes, it is probably time to replace TCP-TCP using TCP-DCCP .=20 The performance evaulation is required to use it in TML. From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 04 00:38:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0XV1-0006dA-2u for forces-archive@megatron.ietf.org; Thu, 04 Aug 2005 00:38:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07791 for ; Thu, 4 Aug 2005 00:38:28 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Y1p-0003iF-8B for forces-archive@IETF.ORG; Thu, 04 Aug 2005 01:12:26 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.010BE289@cherry.ease.lsoft.com>; Thu, 4 Aug 2005 0:38:28 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81353766 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 4 Aug 2005 00:38:28 -0400 Received: from 209.119.0.160 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 4 Aug 2005 00:38:28 -0400 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.009114A0@almond.ease.lsoft.com>; Thu, 4 Aug 2005 0:38:27 -0400 Message-ID: Date: Thu, 4 Aug 2005 00:38:14 -0400 Reply-To: Dong Ligang Sender: Forwarding and Control Element Separation From: Dong Ligang Subject: Re: Fwd: Protocol Action: 'Datagram Congestion Control Protocol (DCCP)' to Proposed Standard Comments: To: Hormuzd Khosravi To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Yes, if anyone get a copy of DCCP implemenation, please share with us. I would like to spend time on this experiment. Besides, I think TCP-UDP+schedule can have similar effect. From owner-forces@PEACH.EASE.LSOFT.COM Fri Aug 05 08:39:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E11UG-0004Wn-Tx for forces-archive@megatron.ietf.org; Fri, 05 Aug 2005 08:39:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07725 for ; Fri, 5 Aug 2005 08:39:43 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E121I-0006IE-3f for forces-archive@IETF.ORG; Fri, 05 Aug 2005 09:13:56 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010BFCBE@cherry.ease.lsoft.com>; Fri, 5 Aug 2005 8:39:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81512433 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 5 Aug 2005 08:39:38 -0400 Received: from 209.119.1.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 5 Aug 2005 08:39:38 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <13.0058C00E@grape.ease.lsoft.com>; Fri, 5 Aug 2005 8:39:38 -0400 Message-ID: Date: Fri, 5 Aug 2005 08:39:33 -0400 Reply-To: Dong Ligang Sender: Forwarding and Control Element Separation From: Dong Ligang Subject: A old suggestion. Welcome your comments. To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 1) [Page 14] Remove the definition of ACID, as ACID is a well known concept. In this ForCES Specification, we do not provide new information about the definition of ACID. From owner-forces@PEACH.EASE.LSOFT.COM Fri Aug 05 09:13:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1212-0004i5-S6 for forces-archive@megatron.ietf.org; Fri, 05 Aug 2005 09:13:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09191 for ; Fri, 5 Aug 2005 09:13:34 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E12Y8-0007Ar-C5 for forces-archive@IETF.ORG; Fri, 05 Aug 2005 09:47:48 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010BFCDD@cherry.ease.lsoft.com>; Fri, 5 Aug 2005 9:13:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81513946 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 5 Aug 2005 09:13:29 -0400 Received: from 209.119.0.160 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 5 Aug 2005 09:13:29 -0400 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.00913B7D@almond.ease.lsoft.com>; Fri, 5 Aug 2005 9:13:29 -0400 Message-ID: Date: Fri, 5 Aug 2005 09:13:29 -0400 Reply-To: Dong Ligang Sender: Forwarding and Control Element Separation From: Dong Ligang Subject: about transaction To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Transaction's discuss in the ForCES Protocol has lasted for a long time. Till now there exist "TBD" and "not sure"in the protocol. Why not we temporarily impose some limitations to reduce the complexity. For examples, we let transaction exist only in the situation of one CE vs. one FE. In other words, we will not consider the transaction in multicast/broadcast. From owner-forces@PEACH.EASE.LSOFT.COM Fri Aug 05 19:23:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E1BXb-0000bb-DZ for forces-archive@megatron.ietf.org; Fri, 05 Aug 2005 19:23:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10064 for ; Fri, 5 Aug 2005 19:23:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1C4e-0006HM-LU for forces-archive@IETF.ORG; Fri, 05 Aug 2005 19:58:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010C0902@cherry.ease.lsoft.com>; Fri, 5 Aug 2005 19:23:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81566143 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 5 Aug 2005 19:23:40 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 5 Aug 2005 19:23:40 -0400 Received: from [64.241.37.140] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11752030 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 05 Aug 2005 19:23:39 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050805192133.03007650@localhost> Date: Fri, 5 Aug 2005 19:23:38 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: A old suggestion: ACID text removal To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 2.9 (++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Actually, I like having the definition in the document. It does not take up much space, and is very helpful to the reader. Remember that the average reader probably will not be a database or transaction processing oriented person. Heck, until we started this discussion I could not have reconstructed what ACID properties of transactions were, and I have seen them before. Yours, Joel At 08:39 AM 8/5/2005, Dong Ligang wrote: >1) [Page 14] Remove the definition of ACID, as ACID is a well known >concept. In this ForCES Specification, we do not provide new information >about the definition of ACID. From owner-forces@PEACH.EASE.LSOFT.COM Mon Aug 08 21:32:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Iyy-00054b-Qv for forces-archive@megatron.ietf.org; Mon, 08 Aug 2005 21:32:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10670 for ; Mon, 8 Aug 2005 21:32:42 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2JWi-0005zp-B5 for forces-archive@IETF.ORG; Mon, 08 Aug 2005 22:07:41 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010C4F3D@cherry.ease.lsoft.com>; Mon, 8 Aug 2005 21:32:35 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81880453 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 8 Aug 2005 21:32:34 -0400 Received: from 209.119.0.160 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 8 Aug 2005 21:32:34 -0400 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <9.00916A19@almond.ease.lsoft.com>; Mon, 8 Aug 2005 21:32:34 -0400 Message-ID: Date: Mon, 8 Aug 2005 21:32:34 -0400 Reply-To: Dong Ligang Sender: Forwarding and Control Element Separation From: Dong Ligang Subject: Re: A old suggestion: ACID text removal Comments: To: Joel Halpern To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Joel, thank you for your reply. The draft has already provided the reference of ACID. Even you do not konw the meaning of ACID, you can still understand the draft. I think simpler is better. From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 09 07:55:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ShH-0003Wb-CO for forces-archive@megatron.ietf.org; Tue, 09 Aug 2005 07:55:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00755 for ; Tue, 9 Aug 2005 07:55:05 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2TFA-0004qp-HB for forces-archive@IETF.ORG; Tue, 09 Aug 2005 08:30:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010C57B4@cherry.ease.lsoft.com>; Tue, 9 Aug 2005 7:55:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81941133 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 9 Aug 2005 07:54:59 -0400 Received: from 195.212.29.134 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 9 Aug 2005 07:54:59 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j79BsvJP290048 for ; Tue, 9 Aug 2005 11:54:57 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j79Bsvbo264912 for ; Tue, 9 Aug 2005 12:54:57 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j79BsvsU015362 for ; Tue, 9 Aug 2005 12:54:57 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j79BsuJu015347 for ; Tue, 9 Aug 2005 12:54:56 +0100 Received: from [127.0.0.1] (dhcp69-10.zurich.ibm.com [9.4.69.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA65632 for ; Tue, 9 Aug 2005 13:54:56 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.uk.ibm.com id j79BsvJP290048 Approved-By: Robert Haas Message-ID: <42F8998F.9060109@zurich.ibm.com> Date: Tue, 9 Aug 2005 13:54:55 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: ForCES WG meeting minutes, IETF 63, Paris, Aug 1 2005. To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: quoted-printable Hi All, Below are the minutes of the Aug 1st 2005 ForCES WG meeting in Paris. Presentations are available at: http://www.zurich.ibm.com/~rha/forces-ietf63-presentations.zip Regards, -Robert IETF ForCES wg meeting, ietf63, Paris, Aug 1, 2005, 10h30-12h30. Robert Haas and Alex Zinin chairing the meeting. 1) administratrivia (Robert Haas, 4 min) Presentation: forces-ietf63-chairing-haas.ppt Consider last call for protocol and model drafts before ietf-64. Attendance/list is asked to participate in preparing the MIB draft(s) and LFB library draft(s). Also, existing or in-progress implementations should be reported to the list. 2) Flexinet presentation (Robert Haas, 6 min) Presentation: forces-ietf63-flexinet-haas.ppt Description of the basic and extendable function blocks in the Hitachi modular router. Packets received by the NE are directed to one or more other FEs for packet treatment, which requires metadata exchange among FEs (future scope). Description of the ForCEG (ForCES CE Gateway) used to gateway between services such as AAA Proxy and QoS and the FEs, ensuring consistency and appropriate demultiplexing to those services. Implementation status. 3) ForCES protocol updates presentation (Robert Haas, 33 min). Presentation: forces-ietf63-protocol-updates-haas.ppt Review of all technical issues in the tracker: http://www.mip4.org/issues/tracker/forces/ Issue 6: DATARAW and PACKED-DATARAW. Necessary due to existence of optional fields. Need to introduce to ILVs (Index-Lengh-Value). Question by Alex Zinin to verify if the consensus was indeed agreed on the list. Accept. Issue 11: Heartbeat piggybacking used to skip sending heartbeat during protocol activity (shows that both FE and CE are alive), need to add a flag in the FE Protocol LFB. Accept. Issue 12: Message obsoleting at TML. Not supported by most transports. Reject. Issue 22: Response formatting. Use of RESULT-TLV. Accept. Joel comment: depending on the execution mode (do all, up to error), each request in the config message can report its result, or a single result can be reported if the execution is stopped at the first error. Accept. Issue 23: Common Header: no windowing at ForCES level. CE-FE is master-slave relationship. Atomicity and batch flags remain in the common header. Accept. Issue 24: Abandon the CE LFB. Accept. Issue 25: Association setup with FE ID left to 0 for CE to assign dynamically does not cause issues with mcast IDs. Accept. Issue 26: Teardown reason TLV. Accept. Issue 28: Multiple LFB instances select (under the same LFB-select TLV). Reject. Joel comment: not needed at this time. Jamal comment: corresponds to xcast. Can use multiple LFB-select TLVs instead. Issue 30: All event are subscribable. Accept. Issue 31: special Notification Response Message (from CE to FE). Can use ACK flag instead. Reject. Issue 32: Packet redirect with two LFBs: sink and tap. Encapsulation of redirected packet in a Redirect Message and TLVs. Static metadata assignment, with metada transcoding. Accept. Issue 33: Command pipelining is inherently permitted ny the protocol. Correlators may be used to match responses with requests. Accept. Issue 34: Header flags: text will be provided to set the precise meaning of the ACK, priority flags. Throttle flag will be dropped. Pending. Issue 36: FE/CE failover. CE failover policy determines if the FE should continue or stop forwarding packets after an association is lost. FE failover policy determines how the FE should behave after it regains an association, currently: start from default state again (no fast recovery). Accept. Issue 37: Remove requirement for the FE Protocol LFB. Instead, global defaults must be used. Heartbeat at 300 ms, with a Association Expiry timer of 900 ms. Accept. Issue 40: BLOCK operations. May include in a future release of the protocol. Reject. Issue 47: PL sequence number and correlator. Convert the sequence number and the correlator into a 64-bit correlator. Correlator used in Config and Query messages. Must be set to 0 for Notifications. Joel comment: use a 64-bit correlator field, left to the CE to split it how it wants. Accept the introduction of correlator. Accept the 64-bit correlator to replace sequence number and correlator. Issue 52: Association Setup. Unsolicited information can be transmitted in the Association Setup message from the FE, using GET-RESPONSE. CE can set attributes with the Association Setup Response using SET. Accept. Issue 55: Recovery of transactions in intermediate state after association comes back up. Relates to issue 36. Reject. Issue 56: Association Setup Result TLV. Accept. Issue 57: Operation types. Joel comment: No Event Notification Response message needed. Avri comment: some of the operations are historically here still. Joel coment: Need to have set and delete. The rest of the operations (add, update, replace, del all, cancel are not needed). Accept. 4) Model updates (Joel Halpern 11 min). No slides. Comments about the draft from the working group are awaited. LFB=20 definitions are needed, contributions from the working group are awaited. Three noticeable changes: a) addition of properties information (information about the elements in the LFB): there is a flag in the protocol to reference properties instead of data itself. Model includes property information such as is the element readable/writable, array information (how many elements exist, highest/lowest subscript). Properties allow the capabilities information to be linked to the elements themselves. b) aliases: for a given LFB instance to be able to reference information in another LFB instance, so that data does not have to be duplicated. For instance, the ARP LFB needs the MAC address field from the=20 Ethernet-port LFB. Properties information tell which field of which LFB=20 is referenced using PATH notation. Most LFBs won=92t need aliases. c) events: event declaration added to the model. Declares an ID for the path to the base of all events in an LFB, and all events declared within that. Allows a subscribe-to-all events. Event declaration contains: event ID, target variable (to indicate which element in the LFB is causing the event), condition, information to report (value that change, subscript, etc). Base on a nested XML structure with field names or variable names that can be used to represent array subscripts. Event properties contain a threshold value, if the event is subscribed, and an hysterisis (FE not required to support hysterisis, but important to suppress oscillations and DoS=92ing the CE). Key and Keyref parts of the XML should be validated. No questions. 5) LFB examples (Jamal Hadi Salim, 25 min). Presentation: forces-ietf63-LFB-examples-jamal.pdf Netdevice LFB (aka Port LFB). Abstracts layer 1 processing. Example of Netdevice with ingress/egress parts, each with wire/upstream/downstream LFBs ports. Joel question: why does ingress has an upstream LFB port ? Jamal: Used to route back packets to other ports, applicable if netdevices are virtual ports. Joel question: need of a loopback device in the model ? Jamal: loopback is a bad example. Tunnel device that validate headers. Description of the Netdevice LFB: capabilities, topology constraints, MIB-derived info, etc. More specific description of the attributes of the Ethernet Netdevice. Robert question, Joel answer: events are created whenever an LFB is instantiated. So the CE is aware of LFBs that are autonomously created by the FE. Sample topologies of Netdevices, with Ethernet, bridge, ipv4/v6, forwarding LFBs. XML model for the Netdevice LFB with capabilities, events, and attributes. The LFB contains a table of netdevices. Existing implementation of Ethernet netdevices. Joel comment: change name from IPv4 LFB to IPv4 validation LFB (TTL decrement, checksum, header validation. Only output is either valid or non-valid) LFB. Joel comment: The IPv4 LFB should not own the locally-terminated IPv4 addresses (the router=92s IPv4 addresses). IPv4 addresses should not be attributes of the IPv4 validation LFB. They should be handled by a separate classifier LFB (model rule is to not fold a classifier into the IPv4 validation LFB, use more LFBs instead). On the other hand, the netdevice may include the classification based on the Ethertype, as it is a desperately common case (alternatively, the netdevice may pull out the Ethertype as metadata and give it to a classifier LFB). Use =93thin=94= LFBs. Short overview of the IPv6 LFB. 6) Updates to TCP TML (Jon Maloy, 19 min) Presentation: forces-ietf63-tcp-tml-maloy.ppt Jamal, Joel comment: multicast model for TCP is multi-unicast. TCP no longer specified for the data channel, issues with transporting TCP fragments over TCP. Possibility of using DCCP or GRE tunnels. PL layer knows only FE and CE IDs, does not see channel descriptors anymo= re. In the High Availability case, FE TML not responsible to decide which CE to open channels to. Complete removal of TML messaging and modifications to channel setup. Multicast model: TML maintains mapping between mcast IDs and channels. Description of the TML Service Interface used by the PL. Robert question: Is the FE Protocol LFB used to set in the FE the mcast IDs the FE belongs to ? Jon: a specific PL-message MC Grp Join Req is to be used. Examples of unicast channel setup, and mcast group join and leave. Robert question: McId shown on slide 13 is a regular PL mcast ID ? Jamal: This document contains more PL-TML APIs than before. Was the PL-TML API not supposed to be published in a separate document, according to consensus from previous ietf meeting ? Joel: there is no other wg document now that contains this. Jon: the PL-TML API can be moved to a separate document. Open issues: which protocol to select for data channel ? Security: IPSec, and/or TLS ? Question by Toshiaki Suzuki: to ensure HA, one FE may be connected to two CEs. Joel: currently out of the scope of the charter to support multiple CEs for load-balancing reasons. Robert: mcast IDs at PL level can be used for such purposes. Failover to a CE in standby mode is in the scope of the charter. Jon: There is a Service Availability Forum model to make HA clusters. 7) TIPC TML (Jon Maloy, 14 min) Presentation: forces-ietf63-tipc-tml-maloy.ppt TIPC is a lightweight protocol, potentially better performance than TCP. TIPC sses the same addressing as PL IDs. A reliable connection for control and a best effort connection for data. Description of the address mapping for unicast and mcast. No security, only for closed LANs. Congestion controlled. No Nagle (immediate delivery). TIPC support for failover over parallel links. 4 priorities only in TIPC. Need to map from the up to 8 priorities. Joel question: in case of congestion on the data channel, messages are dropped by TIPC. --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 09 09:55:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2UZl-0001Ge-0r for forces-archive@megatron.ietf.org; Tue, 09 Aug 2005 09:55:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07960 for ; Tue, 9 Aug 2005 09:55:26 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2V7f-00007b-3l for forces-archive@IETF.ORG; Tue, 09 Aug 2005 10:30:32 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.010C59E6@cherry.ease.lsoft.com>; Tue, 9 Aug 2005 9:55:26 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 81948050 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 9 Aug 2005 09:55:25 -0400 Received: from 209.119.0.160 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 9 Aug 2005 09:55:25 -0400 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by almond.ease.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <2.0091805B@almond.ease.lsoft.com>; Tue, 9 Aug 2005 9:55:25 -0400 Message-ID: Date: Tue, 9 Aug 2005 09:55:16 -0400 Reply-To: Dong Ligang Sender: Forwarding and Control Element Separation From: Dong Ligang Subject: Re: ForCES WG meeting minutes, IETF 63, Paris, Aug 1 2005. Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Great! Thank you From hohenemser@yahoo.com Thu Aug 11 05:49:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E39gg-0002qk-JB for forces-archive@megatron.ietf.org; Thu, 11 Aug 2005 05:49:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20092 for ; Thu, 11 Aug 2005 05:49:20 -0400 (EDT) Received: from anancy-151-1-56-115.w83-196.abo.wanadoo.fr ([83.196.43.115] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E3AEx-0007Wn-Jm for forces-archive@ietf.org; Thu, 11 Aug 2005 06:24:48 -0400 Date: jeu., 11 août 2005 11:49:00 +0100 From: "Gelbman" To: Subject: Why seek? Choose any love pi11 you want Message-ID: <000a01c59d80$883b0070$0100a8c0@msge> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0006_01C59D99.ABD642B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.5 (++) X-Scan-Signature: d9238570526f12788af3d33c67f37625 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C59D99.ABD642B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0007_01C59D99.ABD642B0" ------=_NextPart_001_0007_01C59D99.ABD642B0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_0007_01C59D99.ABD642B0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
3D""=20
------=_NextPart_001_0007_01C59D99.ABD642B0-- ------=_NextPart_000_0006_01C59D99.ABD642B0 Content-Type: image/gif; name="erec.gif" Content-ID: <000501c59d80$8686c0c0$0100a8c0@sanya> Content-Transfer-Encoding: base64 R0lGODlhWAIsAdUAAP//////zP/MzP/Mmf/MZv/MAMz//8z/zMzM/8zMzMzMmczMZszMAMyZM8yZ AMxmM8xmAJnM/5nMmZmZM5lmAJkzZpkzM5kzAGbM/2bMzGbMAGaZmWZmzGZmZmYzZmYAZmYAM2YA ADOZzDOZADNmzDNmZjNmADMzmTMzMzMzADMAZjMAMzMAAABmzABmZgBmAAAzmQAzAAAAZgAAMwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAABYAiwBQAb/QIBw SCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKD hIWGh4iJiouMjVMBHwYBFy6RkyJFl0UDKxFCAyoGTAEhmJyeAKQYBDAGDS0AECKaUKSYtEUNLiGw SapCBDKiwMKbncaoRLZWp6dCv0+gE6siFZIhGM8X2Zesw0fOAKAG4dBH5uLHqdi+FyLe6aiq0BCw 6Ezh5di42r31ROGQ5At1LZsydrFgqRt3ENM6g5/UzUM4hJ+ji0S2ATxxgOKae7U81mGIBaQfSMMa FMPIsqXLjyJfyjxjcqbNmziNEGhBShgE/wzQJgF1J6RBqyXliIoL9XAUwlO0xukD+lRdPG0OSRoh lUHjM4RCp74K4MGDK4dL/kFrJnEfwldfIbZzaJRcW6oG4dZEEmxYUI0m+wJrBVdWkX9NKyrVKtAq sW/oojIVYjinZYwEZsi7QIOG5iqZk52LeWhS588zGSdSfbl1zsAwHogGIBig460hhA1AceJbbQEI 4iYWCqABauFEgCMffeuCvZjGZzNP5dy2vNzkeF9r3ov2jBQGlSeePum5XOp0hWlqQMO8tqHPV55T irWo/CLif5GyVx1k9IbU8RffN5mItF57tBEGiyy0qFQQfsENh51rFFZo4YUYZqjhhhx26P/hhyDi c8ICLVyQgQURkNLZadJFhIpWtS0lCYrrrOhZi48RV9tEeXU3mlx/UWXjcXzdNwALCA5xZJLQ6BXC kPLQ6MsHB1yAgggDkKDNis/RcNRXULbDZRK1edOkjzsa+OSXUyzZi4oranbPmeOBGSeO1I0Z5EAE 5tLcLezsVwQBXnYEEVRqGoTSEIjV2NlRNUHAJm5oLQdVJCodYMmTLBJR2Xj1wOmlKChlGgmjPlJW aQN/1hnIXm8EBAyRa7BWRmghjmErG7j6QppLu0oBax6kdPDoMITSIIKT5xW1onpgaZTsDBKw0MKS na16p5g0FBOkkrelqahX7HXK12nV8hT/LTdPyqDAZLg1W9y283a2Urk3DhEjdZPiS2smF7BpWrfI ZstsE6IimPCbnCrc8KiLFgfts6Q+3Iqok+LW7bsPDmowwxuHgq2yStQUo4ruhvItbStWekSyJOdJ 8BKTCMzZzCwrezDC7XIs80oDe0vakS6fBEIK9liilINI9CSKpNfIKeVjyC0qAKlLEyluEkzXJQ4L GDjjdCwXLw3teXSSIjUqXWdM85PsDpVenwfJWyYNGERnWNt0q0q2ATsBcDV6rrrK99+x3NfE4Jqo GDfiECjuRaNrqfxrgY/PSd9hqcabY6DVMYpWoxUZuLlikuf6xbBiQICzFqyrLvvstNdu//vtuOeu ++689+7778AHL/zwVDCtzGKWjyv3J8kX6dfpZB47HqLyJlRyKWSmTrqstAEdcN9IuF6p6/8aQX6U KXrVdFXpZ9W8UwZJdVfNBErm19TE56///vz37///AAygAN8AAdQEIELlEhoGXJekegmtK/kKGoHw 5bZPWGsICfiZbyhmnS29Dlvl0xcMFKClrUCvdAbpCzT2dZAMPOk4CawYBEPowQ0wRYIWNJcDIaO+ Afrwhx6KHRCHSMQiGvGISLwVDfnQKzXgqzsM7Jz5pKcksMUKXlcQYhK3qASY4c1ZLFqZv1L0q33h K3WOwhnMHBIpKZowYzGaVrpqlLKOEf9BjhdEwhm/EcXS3QdfaOshbow1qiGMUYgo8xkOR6YtcxGN i5CMpCQnScnZFeCSmMykJjfJyU56EpOVDKXupmKRIJWyjN4rWhLqAZc7es8fsOCT5mBZhE6aoAAx YEABQqABTNJAl56EQC8zyUtMsgCYl6xbjk4XOz5NBUAWEaU0p0nNalrzmtjMpja3yc1uevOb4Ayn OMdJznKa85zoTKc618nOdrrznfCMpzzn6U21eSJiMTSkvZ7XGRuC72vmwiErKECDrqAmn0kAYTLy +UiJgY8rL7znzRTHvYAoVCcVJBzA9lmLHg6AI9iIIj+8Np/OlOCGE/0nA1c0Lo7OZ1X/ZeNo2kIw QzyBKxk4BGMhYWak25iwnwThCmc+k7abnVQUF11pZ1o6M6HmC4ySgwc9CaHFO1TVCSRFWOjSkNUQ lWeqmxhRiU5ERuV1TxKCvCMMFiCCn8hGZg10EwoPEqb12W0l3ijMLB5Gw4E5THl8Wl9d6TfXwh5v THxRUCzeATS3KC9hn1Gh+rgHVmleFRw+vQNl4deGy/qhiVIAbRq418RoakyHlU1D5K7hHuqMK6PI IMIYgdEyXxGSTbPFYbGo6CLZ0stzk5DTujRIGQF1EV3WCgAIJkDFnCZrWd1ZI82+pxiXPndnTtia a2mbLVciS7GGwWMvpKvTJV7Fu4bV/6e5CFW91JJhTmA5FdU6uEpMQC1w84XvF3/BN3sGgEZCZBxR /CulwyFBwJUKh2HuCwsEnzUuAcYaoNamUQfNdL/sgFri/hkZsz1UTcWAGoHZVgyvORhyaBxxYuDC Xr3NwsMq9qx7x+k6NGZIxjPOsY53bBOP9uYmkbmcHWBFCkjxwlft5QOOGxEsfvmlYY3dFnnhqygq 3cxGMOiIjQB1ntUyKqOicsiUsZeKTWH5GjbqkkwfBig2WtlGj9IyYp28nD9IFQxLjuSdv/DRf/JY Q2vpxEwD6bKVoYrOinEf+Eg53N6idzjbsF8T1LKuyn2Y0MxDa6GR5xv5tJJVGt1Vg/9awegeFe5H 4WMjmZWpjA8oAGyLStaXqHxoVMuI1sVp7TgI+7bqaXfXw40dOp750qKQen5vaW2vMz2VUp8Dfx8S LRelHYgmb8Haf/7Doo6kHg+vz7gmuw8r3roO7jirWZkBzxL+490jsQvcHs4P6DDBHmUbklZju95j vd20E5YJvPQ27zp0o51lfFXe43IZu/sx8IrZ+CvmNmV/JpTvr9yn4mnpjqWF/ZazZYID+pIP6Ww9 V3d7Ci1HmtScQJ7fCzw82zCPucxnTvOa2/zmeKD2ZwV+Xn3x/AhP5G4Dz9WZVJncDdh2Qp5xPhMv 5uVOYoQ6KifIwdFUfczVG7nVi/7/6JxRK489ny8j1131oFuc6lw/XpJ3W8jyllXpPUMpR8eu3qc2 lOl4z7ve9873HZOSmZUGvK9TOemM7ih02wuX5JaBFBLsOddI/lwKU4wQyRZayDdl9l2gecK+e/7z oA+96GtuvERnWuKKDvfzVPky6ZmDeuFzo2yP8qkHm0/X74s9E8SX38tp2HVAQRFxIh8P+3E8fiKb H3VNL6NnQHv00I++9KdP/fwVUB4IXPMC077DddSUuHU3PNCEn1J9VX1gR3Uqanjap03m8paYLOYl f/lJTI4Akw54wSXzr8kWRlS9DzRUNjUw/gR+FwVVPJRk1SdzX0UF9feAEPiArLaA/xRYgRZ4gRiY gRq4gRzYgR74gSAYgiI4giRYgiZ4giiYgiq4gizYgi74gjAYgzIIc0nnCKJVUZlVOr/lBkt3E5vF DDkIDgShbQ3zcwIECa8GFEqTepxmaf02KVORVwvyYor2hPXDaUXxHayHHAHBQji4GRVUe0T3JcSG VTxRFmeBesZ2aZp3He01bJtXbMVxbG44aFCQD8q3hdaTecQ3DnaEHHDxFCqzfOnlbMdThX4TSfh0 L/SSW3G3aEjSXR5UDFK4WG4nEJEYM253dOxRPWw3KV54G/mQiZXCXm9zfuXXcLsHbo3Ga74SMljj UtEjiTnVDjZjXR9zagllFbW4R/9eN0eO9op19IfcBV10xDF0J3RsVH4mMVsso4Bc1IN3oHNnUIMz +E2gBjWs4jgPoV3mY1+tEDgOBhL3YGAk92gtphl7U2KwNY5w0xS/Z2OH425luA4UJjgSFj15o45U aB9o9jh8441z6GfXqAjBFQGEcjGNlm5rhx270RsGVx0IVx+yxXOm9W+uMIXFIXAR2VpC8VUYlwu0 0hdHxw/wZW6JlZGL1SAet10L53PqVpAgUmMEOWM0KZOtUXs7oQoitTldZQSykk9K9UXr40JP1X3E BVFHGXYIZWvXx5NpJ0HD9wk/1npr9n1JmWyxAGee6JMx1VRaqX54klNQiSBDyQ3/qThQBXUBkcVB ZwmANZkUMnVl3NeUIlSTogcJE7AsG7ApZtUNsMWH0cQ6K9RtLmOIMZIUeohCGgZpYXMX0kAN1tBv tFSYdlGHCIEYwuYO8GCIlAaNj/YtgYFXANeAmukRprWLs3EyqNl5LviTZoBj0tgasImTuZIwi6ma YjCbIxGEjhAsvFkG1giDGDMMu4Y/oZgMSgULrMBWbpUM+yJXjglZbweUSCJ7HvRXBVJXJcV959Wc bYUBb+VX49Vth3Kd06UnIiEuduhagWVXoSlk0hlo1amD20Ke5yVqiVIUzAlw7Dk06GmbvROcjkCg AnqgCJqgCrqgDIpO1EgsmNcE/w+KBwaaBQ9aoYIwnDCXjYRBb+yoUrQnH9q1KOY4KI21PA5FJ8QH JgD5oUsgkK6iogY2lefwAXsJAA8gASXkjtnwKSWKH/lImU6movO1kaLxC2LIM81yOC85U/f4o8mR j9yIpCHqZz9xmpmzOQ14VrgWMXsYozHhbsqFJyO3pSp0NElDjKJTWJcwJ2haZnzUOWJ4pQwDmiXB lghZSC8ppBW3L+O2UD/HkBRpYURRbyWjpcO1p120EhM5kQfSC4qKMPIlDlrSkfD4JZFaICg5HSmn afOCJp5GlMLRmCFpBBNppLkgqoRjqP7BkdgDkoE3IHyhcY7ljwHAcmeFKwYXE/+IcWeUs59HoHWb wAKgSFSveircpqaJmBirNSfIygIiJ6dogV8PgaFdYHZgcJPh9HgNKghKaaymJpbhVxB9lDM4c4BI 2W/aV66ORpYhVZeyaJVguX1McjMFOBpYma4UlBJz6VJZVRl2eYizh1bax5/eJ4ArehgoB3YZBF9E tYSYE7Ebxi3+JK4qin5Mga648X21iLHkynVvGT5cOYkP5ZUEO68GK64UK3c4o1s0hbDvMQiWSQ/2 plFsGmmIlyoRmZvnxSMxG4y9t288a5oeuQ3v6TkCm7TMpxP3IQv4lZom9A5H4Zk1C5/BOjoZ46xo VQl9AnuslpqyBKz/cLTllrD/jxa2fxmhdVKPACO1SIVsBvGZTeBMkAm3jWCt7lSbw7Olu7lVcKC3 +sN4XnpOeAs7agsQWBQGGqp0dBlngohmtSVYa7ZldnIjjdt229kpxZlGTNIwgEK5aWSEtFMqMqAp gHOiVuu1TPsNx7kZ6olu5vmK9MJr9PlrAdqe9olanOVaMDqB6FiafIUj4PmccNUd0lkn1Em2WvW6 76G8k0OryAe5mAtcR7a5d4S5wkpXUckpilMZjKe908sygflDhbtshmuniluVvtNn3dq+7vu+8Bu/ 8ju/9Fu/9nu/+Ju/+mtO1/cM2Tev7JpPFpuKOgVmp6Orr/or2VtF3dGwBMx+//RVixqLUSQkh9OF FqySVv53lAL8skv5UzRQgDmFrk1Jo/sLhHUoeO9xSoO3elJwClulQgqMnYjzMq9UXPQVcnTzvQnl eBnTSkwwFo27hTOrwviwEMnnhpzHsycMfeXbxFAcxVI8xVRcxSwxoaHFc6Qlur6VdjBDw1s5dOzK BotrtVZ8B6VHkcAmtKc3dRR5PVvIQjjMhzqsDePrKZq4lUskLr3LhYLWhGpraX+ncliYCs93xnTg dG4XdWHkxnVnY6ICqhvkGcAYdraXjHpUdnMWkmM8xoPEW4d0uInEssWAyc54d4icyqq8yqzcyq78 ytfYv6nwvwoUwFeJsLVYL//hu7Szck8JnHU0vCPkJ4sQLDPp58HrV3WJVcHIIcc/WxsZ3JBGCUO3 /MEbFcKkbJyRSM2vY8Kw3K77YMQfacSr+8bR0Akx3JK3N2ktAMQtR0toCzC01HhmUnkvRwxVAmdE bM+e6ru6KSP1uLPffER8WwhPPNAIndAKvdCDEIEO/dCgxNCShMVRQNFZsEkOsCL6d0kMtNGe9DAe vVLIlExoUMbnKNFjkMah9j7jnHqODLW5QHulqD24p6y1NgSc5Dr3N3/IJH+e5ADDhEk3k0v9V1hQ AcigKcjKR8iI+F82hdJeoMi6LFxmNdX1aaJo9zrzAUciilxdUkcgIV5EoEn/Gb0iyNTRxER/+OfR ad0ZI10AB3Fb3xDKdjrKsTgzpkwvqAzVSATRfg2BfB3Ygj3YhF3Yhn3YiJ3Yir3YjN3Yjv3YkB3Z kj3ZlF3Zln3ZmJ3Zmr3ZnN3Znv3ZoB3aoj3apF3apn3aqJ3aqr3arN3arn1zJn0IvTIwBnQzXBwH B20ItP3UT7Db0ZC4eSe4k/rCwN0aX1gy8qXS4HvbcIe+q3O4cfCDVSDdQDmEz+3co5Dc9zxAyoU0 cOpQAwneXhOPbJi0DpKOEbCOoqC3/uGi9BiEY9OYtkfH4NxegFtK/OYECxaO6oJhq4C64VOlLMlh rTk3zgNhMBaWIXCPSqCY//6IqlFqs5ZsPlUaNSkCYFpJ3uRY4La64BdOYuvdL3fsQ6RrutSZvEjs Z9LJx8DLneBwu8Frx35Gn3Wcw0B7vBMePeEI4Nm1VuEpG98iWe3FJ31cZ0XOpdJyorg7t+rwn82C n/QNlClOjHSS4jkEvfGJF5nrSL5JRNsGretNK006cWjkqB5WiXsjcKe6pyRpRd8WIF0HtOd1qr2N q5b34KVaIAQHkQv5HWtH5v2s3Lw84F3k54NqmJ+qi42xGQbeiZznI9QNq8JA5YWKIIB+qiaZ4EvK 3CiY23ymvucLBdz6XtBtIaNexZ7OB9pKdt5pBqv+IdiabaluBhatuMWNE/+iwumGrZPqQq88YbIm JBd9VsxJNbIIuEoj61wwQFAGxTbxqhMcVJZvYq+3fuwN5SBvqbLF/DLLvpZExYzv2kAxNFKgOOKM vZPY8RNqGN5Ad4ZmAWqewh9Zy+HNZ8a/q5IMUsgZN52P22+IaBwpgBZBlmQLjOZYYreuZXxLwyZJ atl6yZd+GbOA+U+RSQDVgFbzXDqqBiSuKbFYPRj43o+jkLOO6bzmbEi7gOXpBedfilEhb4gtHbWn vtnNWr2tSIi614DihcnkZdXHJYnzZfCXSHRf1+sS/4hKMEacSJTSFdZenZJ6lZVV7Yyu+IyuDbg7 hvWiLZu2zds82PXCUur/XTDrSuT1fKHrVeDbd0Qk2GLuGehjhoIF1K3oZjD3J40GS0b2WRCceTb3 hKndeBl6HJqG76gKRx6Mh0OYE6Jh/ZXgIcYmAQGlo6pq/j3g+w04sueOnyFimm6wdB+0A+6kH84E aeLfp3Y3+5jemHBi5eiiDa54kCESJar10PdRJGIiwjdcQn7E1xEmih8/gha8Th6M+uDidCUw68Li zimeY3llutYJww95n79M2RD92CWhAE4co/ldIV+8dUadSAH76QX+Ob6AB5mQHTN8gsr79zYbMP0V xgXhh85aLI/4rtqjRsbGKeqQ2gEEAOFQGAiJAIFLKxliKp8XJKAhMyiR/w0aMyklfr+EWQpT9FKt WOq2WQa/hQRrMeRWltVguSEOMzSYIESMkKDMpoYaZiLg3gZWGIn2hozcEhcbMzU3OTs9P0FDRUdJ S01PwSpRQ1VHW1dhY2XfXmdtb3FzdXd5e31/PSFo5oDpLFnripVvhYmXn6Gjpaepq1HFIoces0Ox M2utT7fDcwdU+MhLzdHT293frcEb/IYElWiG2YXG4e6IBk4cuIDP2QAW+DBVEsZGiJZ8TTIMxATA IEJuevA9NBKRxsQ1DxsRyOiMIqQuxwAaEEnwypmGfip2vBhmJJ+NEiPd05iMypM6C7no3HAOzsKM dgaChBMzYYgMIWRCxP+ZiGWcmmbwDdVH5GbUVoAAEIBBgUbEhEnndJ3IdCY8t299gevZEFFYkiXb JmoRwIOHP4gmdaFHieedPOvAKRkczOexLlPWcYLAZZ/Jnnz9NqgLYPLjly0Xd+oMjl+lr43NYGgV uR/Pyjldf1GsbzWkxGdY10NNkSit2G0aMhH7J5CI0nVuh4a7nLkuuZxFEKAc5y6/pSomYCAgogK7 wFyPAD+Zh7Bj8Ju5LhEy+jf5b+o5T+dnLvv27obiHxouO3w/+OwdO041ngBMbb7efEPJsuf4K4Sn PW7bDL/ODtyqPP7c6Gw4sAQRkMEm0GtOxBFJMSIjGgabLYzqLGtkNPj/qEMnJhqmaMWfj2Qi7SB8 QpQEIQlY2Ou3hjLyCKOOgKTMuhe5WGmGJM0YbMYeh3AySbl0ImYlEcCy8QI8oJJBAQTfWIlGrJQC Y0o6OsCHnuccisrKIJsYZkwLjTmSS+H84LAQtGz6bU067iLR0EMRTTSXefBUFJYPHY1U0kkprdTS SzHNVNNNOe3U009BDVXUUUkt1dRTUU1V1VVZbdXVV2GNVdZZaa3V1ltxzVXXXXnt1VVvmoO0E2Bz EfYTY5chNkFUc/N1VUEk4cKhQtPDp4RzskSH0XqmmLZR9xjNVjywijqRBjAxAIqqNGUDVJsd14KX kdPWdebG1jAhIAYS/6yqqhUIJvI2EzOpJQyfDvygV9x1UbyCQCM5YateduJMmKcunZqKSHZp8vcn fIJKSquBXQABNjy8cC+sphx0zMYP2OksT/Bchm8/R+gUIoGV5w3PiIRgZhDamSFIo70QgI55uvU2 I6Dkk3mRzggrIFANNzJp3gfB78jVzDPevj2DUQ8vXhrDrMe7utEqiVGRkgtCU1jtIizIq4gPxlTg BAX4/YK9iCw5DOuizNbGsuHoZRsdlW8yjxO3D9G6JQnLFu9tyAZ/o8DxeGr2i5QiM1Gpld50bZvE CoNZtwvR/qIKCqgk5OzXAsCbBdWCHpJp1uNLzHbclQZj6H1OMCB03f9nqX0CLjcI2qVMKlScCEGk i/xxKfYjO8PCeRfPsOc3+Y4wylteLwoqNaldJSsG4HfCxiBIEXz/uJDZkcMt3l6StsFXSDlQZMe4 /hFoN5e7Xv12c4fo0SIpbnKYG8SHFxhB6Gh2UJ35umc5v3GvHnGbYBqc54LcOQ46rMOC71oiwuD5 DRE6cSCyUFE0h1EmThADj522RhLI4ciG6VnMwrZErpBkpHwn2VhUBkaMQQ0qLDwSYg0jYRD0qU8b fZuTkFAWsCLZ7YqNqAgMFkCPIE5HfHEyWhZ7VrB3EZEIUDziHMaoQYb1sF9PCpKXwIRDPN2rd1Cx SJ2q0kQe0eFEIQv/JAYJmRGLFXJ6HDQYyPp1piRcsAoP5A8jRdcwQL6Qks6wXya3wMfJgNKR1cAP LrblLHLczBYwVOUrP+XKXugEYspShud6YUtYdgKXz9Bl6zrVS2fJ8hfWsYYwXYU6Rm7SQSdyUI1U l8lFgLKZh9QEMtOBJeTNbjnYPNY23zE1PsTPknP5WQQCULeGGMlE6AKAAGySsiFVkgr/s14l22k5 Y9plcVBxJz1T+QZ4eiafqiAnZwp2znRGAqD0UMRFGuqdtqWODxGFQ2BMI7YzBqcJ01Rna0g4PPtl MAAgSMETnEc5lxVmfh0cp9E82jM3kOugMkSWQj8aI5ci1GHnAs5N/2OTB3qWaaJW69ZGzYk0dOZU c/SwqUYn1xCYLjUbfFxObdBZOdStFCkoy4iSDhIUP/6RqP0cUFcNdxGMsnRAJ6JjF77qvS8tMBVH c2tWV3pX6UluoZtEYln9sdazchSoIa1Rf27owEn+QQYHuKBVFqnYV4z0H5ZBTAU5usCKOJJBgakQ HuUI0v2ZNSRp+BI/jaEwcKZVcoIV7HP6KiIjROF8ayggVY6BxwCqRwAImNlDNyFUpN5rn4JNDRXe Or4uJPBLhhCnaF0HMS04Brh6IIlYHpCN6oZvDEg5alS1cNtGCA0RBolbe1RnkDRwQHFbXU9C1SPO CNl2uU2wQm9ntv+ssprBJ8M9rcr8Uxfhrm1lZLinabPAhpvGNwQIlmpU0VDOSBFzl5eiMK9YmYsM Q+PCvupwhSPVDAK/Mk6lPEWJqSFiELfjlysuRYu7mblZeNPFNf6GUhcLV44R5ileyZhX3FXPmCGB YBRTpEDqElAwCEyKD94IVCayMImpliMeEdg30wVJHavRKPjwKkjEQhazMNSa6UFJ8Yq8D3lxxlyW uLJQZDxEj2WZIXAe8Sk+2TlsrTZPapiv5kr5lfyBaHrlzRkAdvbndqnxVrVTwO3UJyDong55XJMW el4kIbHZ82usUUQKDuuGbXgIbrTRanvm5gk8Shq6K0LHhoojuEb/AQIzf9mgYLZSC1mvJs6b2Jxh 9HxnU+T5REhNnx+LeiTlULauKEONsoYmO25WSbEuVp8SVMjqZseosyShXsgQ+LX0RIfT4m6jC5ww sz1om9D/Ei+AVc1Wdk97r7CGDrzVhB3tcKcl4T5Pfs2NF8kd6z/MxQBdmUEZXkv4xhA09v2ywWx6 V6LJhd4pMNXUol1SMcJbXpsR2qTJbtOm1NRGUs7MuLiSawKKBpnpuUBebXExMY5w2qJ9RwzahclZ kjoNS5+Kc8S3MqmOSWKiIHvuRhOJiSjP1cQVdR6mO+EcPDpssLDzM7PLnojT0uwZ13tqTYljvBUi GcRY6zxWn4A9/5P2ugCjbUzvYijZFB9Ghd1bhfe4753vfff73wEfeMEPnvCFN/zhEZ94xS+e8Y13 /OMhH3nJT57ylbf85TGfec1vnvOd9/znQR960Y+e9KU3/elRn3rVr571LoaxW15PS7Um95p9oxSN W195M9Gew2PNFxv9CgOBmEuTvgF+KPb5YjHZ/t/BRew9SOgL3D+Oz7kHscuXPIdw+RM4EcUpN7jG e/eckoIhLeXYUSuEgbqnuMm+3r4c0Wtt9AYgAok+1Q/qfaXGtihOdXCE5cKijMj6/g6gvAyUpomt EBCvLsr9PEEkhM90bMP3uAH9CK0B2cGF5EPj0k/NGOKaSgCx6P8AfZTLa6xqdijtrpClQoyLIsIq kciK/wiw72So+9iJrZCLG0YOt4KLvWLEGwIIeSzQBe1prf5kA9WKGPArtIhgZ9pHiEaQUPZIBE8Q PGhrnXSw+pzr6gZsCb+C92YwDGWlfZRB78TwDNEwg9JwDdmwDd3wDeEwDuVwDumwDu3wDvEwD/Vw D/lQD19PFGIvKWoJDJeC+SRl+vrw83bPbqQhk0jQizhQ+fjGN9AnXDYNwpYBEY/t/hJx8LDPdbRv kf4pFB0mpkbrEhgRkfZL/eKpLtqPtN7PEAfuOmQEElgj+aSQMxyKFL8vE2rq//BpnkjxuDpx8QwQ 5tAuAbtqAXf/kAkbpLQysIGQ0NX+4QU3YQBCkHy8iP5skRvzAquYsfpY0P02CwaRSAaLEfFqUBW2 S67KoB2bcQ04kQjxxAjri7VO8Z18yxl1hiJIAAov0Ok+Q6gSpqXo4ApzEOPoB+e6cB+/MBXTMSLD gQyLwQwl8iL/ziIxciM5siM98iNBMiRFciRJsiRN8iRRMiVVcgb/8B1aEhco8vbkbyVjZRHdweuQ 7rC4bvjMxZ5GCiCTZfnaqCArESHhah51QRMbjiY55RPbiBe5jx2h0hT3KiHT53nI7+Ea6SqngJW+ Y/3O4BdLkapYMeDaBf5mERfFYxzq77TG6+p0saKmkixdxP8g/ywYzUMAq5ApKeUY22qLdCsZGXAV iQkCD0ACs+rmVmcTm+U7NFDgwAZLpPEasxFsXmO8RAYSTNAtJ20CVVAcLescWrAc/SrKmIovL2Ud kwEecZA1SYhrfCp9fJCfgNBnhNDEmqiWJuoI60u+joY3G8EJ/1FaiDIXt+1t7m+27tE1D4ghocoL L4YQUbMPN0wdZJEXNHI6tRMOUExRsnM7wTM8xXM8ybM8zfM80TM9F68A2LM93fM94TM+5XM+21M9 7VMZ6DM/9XM/2fM+PfIlPwFAT0E+TYA/DZQ+gUEp/dNXbDIdfhI3bQE+aYABCrQ9HSAGGKAALmAE +PMCNIA9L/80Qx3gBd4zQWeyE75zQQ/xdrKvokSx++ZSBsMPIvPAK50BLKdALHvxnVrxC+DzAmKg QtmTBTJ0SIuUPkPgSAsAKhgAQ0uUMOYg/2L0NP3GLgcsAIdxAFWUVfwyHJdRMJsRhiiOTBxzMj9r SB6TCAg0BDi0AIi0Pd+UPlNASSGgTYFUSdEmBQETNKNINMnRGheQbiByS0VFNd/xBtGKOVdRHofl r3xut67QN1cKOIfgPYvUBEYURJ10Q9uTSd9zTt/zAki0ABxgQt3TCpcTUZtTvp7TIaNzUAkVDauz Ewj0QG0VPhUyVs2zO0fhVn01P3NVV4VVE361WONzWJE1WZVFdVmZtVmd9VmhNVqldVqptVqt9Vqx NVu1dVu5tVu99VvBNVzFdVzJtVzN9VzRNV3VdV3ZtV3d9V3hNV7ldV7ptV4pJQgAADs= ------=_NextPart_000_0006_01C59D99.ABD642B0-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Aug 15 23:03:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4rja-00007O-8W for forces-archive@megatron.ietf.org; Mon, 15 Aug 2005 23:03:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02225 for ; Mon, 15 Aug 2005 23:03:24 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4sIk-0003lj-Gq for forces-archive@IETF.ORG; Mon, 15 Aug 2005 23:39:52 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010CD152@cherry.ease.lsoft.com>; Mon, 15 Aug 2005 23:03:16 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82684012 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 15 Aug 2005 23:00:58 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 15 Aug 2005 23:00:57 -0400 Received: from [220.192.116.237] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Tue, 16 Aug 2005 11:29:32 +0800 (CST) References: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <006401c5a20d$c952f9a0$3f73c0dc@WwmLapSamsung> Date: Tue, 16 Aug 2005 10:53:20 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: [Editorial #1] Abstract To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: base64 SGksDQoNCmZvbGxvd2VkIGlzIGEgc3VwcG9zZWQgZWRpdG9yaWFsIGNoYW5nZSB0byB0aGUgcHJv dG9jb2wgZHJhZnQuIFBscyBzZW5kIHlvdXIgY29tbWVudHMgaWYgYW55LiANCg0KVGhhbmtzLA0K V2VpbWluZw0KIA0KPE9SSUdJTkFMPg0KQWJzdHJhY3QNCg0KVGhpcyBzcGVjaWZpY2F0aW9uIGRv Y3VtZW50cyB0aGUgRm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24gcHJv dG9jb2wuICBUaGlzIHByb3RvY29sIGlzIGRlc2lnbmVkIHRvIGJlIHVzZWQgYmV0d2VlbiBhIENv bnRyb2wgRWxlbWVudCBhbmQgYSBGb3J3YXJkaW5nIEVsZW1lbnQgaW4gYSBSb3V0aW5nIE5ldHdv cmsgRWxlbWVudC4NCg0KDQo8L09SSUdJTkFMPg0KDQo8U1VQUE9TRUQgQ0hBTkdFPg0KQWJzdHJh Y3QNCg0KVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIEZvcndhcmRpbmcgYW5kIENvbnRyb2wg RWxlbWVudCBTZXBhcmF0aW9uIChGb3JDRVMpIHByb3RvY29sLiBGb3JDRVMgcHJvdG9jb2wgaXMg YSBtZXNzYWdlIGV4Y2hhbmdlIHByb3RvY29sIHRoYXQgaXMgdXNlZCBmb3IgY29tbXVuaWNhdGlv bnMgYmV0d2VlbiBhIENvbnRyb2wgRWxlbWVudCAoQ0UpIGFuZCBhIEZvcndhcmRpbmcgRWxlbWVu dCAoRkUpIGluIGEgRm9yQ0VTIE5ldHdvcmsgRWxlbWVudCAoRm9yQ0VTIE5FKS4gVGhpcyBzcGVj aWZpY2F0aW9uIGlzIGludGVuZGVkIHRvIG1lZXQgdGhlIEZvckNFUyBwcm90b2NvbCByZXF1aXJl bWVudHMgZGVmaW5lZCBpbiBSRkMzNjU0LiBCZXNpZGVzIHRoZSBGb3JDRVMgcHJvdG9jb2wgbWVz c2FnZXMsIHRoZSBzcGVjaWZpY2F0aW9uIGFsc28gZGVmaW5lcyB0aGUgZnJhbWV3b3JrLCB0aGUg bWVjaGFuaXNtcywgYW5kIHRoZSBUcmFuc3BvcnQgTWFwcGluZyBMYXllciAoVE1MKSByZXF1aXJl bWVudHMgZm9yIEZvckNFUyBwcm90b2NvbC4NCg0KPC9TVVBQT1NFRCBDSEFOR0U+DQoNCg== From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 16 03:47:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4wAP-00077F-Dr for forces-archive@megatron.ietf.org; Tue, 16 Aug 2005 03:47:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26133 for ; Tue, 16 Aug 2005 03:47:23 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4wjg-0001Gs-MF for forces-archive@IETF.ORG; Tue, 16 Aug 2005 04:23:54 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010CDE81@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 3:47:22 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82702738 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 03:47:20 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 03:47:17 -0400 Received: from [220.192.115.69] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Tue, 16 Aug 2005 16:15:41 +0800 (CST) References: <006401c5a20d$c952f9a0$3f73c0dc@WwmLapSamsung> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <009801c5a235$c0cb1bf0$3f73c0dc@WwmLapSamsung> Date: Tue, 16 Aug 2005 15:39:15 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: [issue 9] Fix LFB definition To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: base64 SGksDQpUaGlzIGlzc3VlIGlzIGFzIGJlbG93Og0KPElTU1VFIDk+DQpOZWVkIHRvIGRlZmluZSBM RkJzIGJldHRlciBub3cgdGhhdCB3ZSBoYXZlIHRoaW5ncyBsaWtlIGNvcmUgTEZCcy4NCkNhdWdo dCBieSBBbGlzdGFpciBNdW5ybywgdG8gcXVvdGU6DQoNCi0tLQ0KRGVmaW5pdGlvbnM6IExGQiB0 eXBlIGlzIGRlZmluZWQgYXMgYSAicGFja2V0IHByb2Nlc3NpbmcgZnVuY3Rpb24iIGJ1dCBzb21l IA0KTEZCcywgKGUuZy4gdGhlIHByb3RvY29sIExGQnMgaW4gMy4zLjIsIDYuMiAtIHRoZXNlIGFy ZW4ndCByZWFsbHkgDQoiZmluZS1ncmFpbiIgZWl0aGVyKSwgZG8gbm90IHByb2Nlc3MgcGFja2V0 cy4gUGVyaGFwcyBpdCBzaG91bGQgYmUgYSANCiJwcm9jZXNzaW5nIGZ1bmN0aW9uLi4uIGdlbmVy YWxseSBvcGVyYXRpbmcgdXBvbiBwYWNrZXRzLi4uIi4gUHJvYmFibHkgDQp0YWtlbiBmcm9tIHRo ZSBNb2RlbD8NCi0tLQ0KY2FwdHVyaW5nIGFzbyB3ZSBkb250IGxvb3NlIGl0Lg0KPC9JU1NVRSA5 Pg0KDQpJIHN1Z2dlc3QgdG8gc29sdmUgdGhpcyBpc3N1ZSBieSBtb2RpZnlpbmcgdGhlIExGQiBk ZWZpbml0aW9uIGluIGVpdGhlciB0aGUgRkUgbW9kZWwgYW5kIHRoZSBwcm90b2NvbCBkcmFmdCBh cyBiZWxvdzoNCmZyb206DQogICBMRkIgKExvZ2ljYWwgRnVuY3Rpb25hbCBCbG9jaykgQ2xhc3Mg KG9yIHR5cGUpIC0tIEEgdGVtcGxhdGUgICAgcmVwcmVzZW50aW5nIGEgZmluZS1ncmFpbmVkLCBs b2dpY2FsbHkgc2VwYXJhYmxlIGFuZCB3ZWxsLWRlZmluZWQgICAgcGFja2V0IHByb2Nlc3Npbmcg b3BlcmF0aW9uIGluIHRoZSBkYXRhcGF0aC4gIExGQiBjbGFzc2VzIGFyZSB0aGUgICAgYmFzaWMg YnVpbGRpbmcgYmxvY2tzIG9mIHRoZSBGRSBtb2RlbC4NCnRvOiANCiAgIExGQiAoTG9naWNhbCBG dW5jdGlvbmFsIEJsb2NrKSBDbGFzcyAob3IgdHlwZSkgLS0gQSB0ZW1wbGF0ZSAgICByZXByZXNl bnRpbmcgYSBmaW5lLWdyYWluZWQsIGxvZ2ljYWxseSBzZXBhcmFibGUgYW5kIHdlbGwtZGVmaW5l ZCAgICBwYWNrZXQgcHJvY2Vzc2luZyBvcGVyYXRpb24gaW4gdGhlIGRhdGFwYXRoLCBvciBhIGZ1 bmN0aW5hbCBibG9jayAgICBmb3IgcHJvdG9jb2wgb3BlcmF0aW9uIGluIEZFLiBMRkIgY2xhc3Nl cyBhcmUgdGhlIGJhc2ljIGJ1aWxkaW5nICAgIGJsb2NrcyBvZiB0aGUgRkUgbW9kZWwuQW55IGNv bW1lbnRzP1RoYW5rcyxXZWltaW5nDQogDQoNCg== From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 16 07:08:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4zJM-0001rC-2i for forces-archive@megatron.ietf.org; Tue, 16 Aug 2005 07:08:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03225 for ; Tue, 16 Aug 2005 07:08:48 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4zsa-0005nw-2g for forces-archive@IETF.ORG; Tue, 16 Aug 2005 07:45:22 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010CE652@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 7:08:44 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82750407 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 07:08:43 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 07:08:43 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005081604131062:40647 ; Tue, 16 Aug 2005 04:13:10 -0700 References: <006401c5a20d$c952f9a0$3f73c0dc@WwmLapSamsung> <009801c5a235$c0cb1bf0$3f73c0dc@WwmLapSamsung> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 08/16/2005 04:13:11 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 08/16/2005 04:13:14 AM, Serialize complete at 08/16/2005 04:13:14 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1124190518.6727.35.camel@localhost.localdomain> Date: Tue, 16 Aug 2005 07:08:38 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 9] Fix LFB definition Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <009801c5a235$c0cb1bf0$3f73c0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit On Tue, 2005-16-08 at 15:39 +0800, Wang,Weiming wrote: > Hi, > This issue is as below: > > Need to define LFBs better now that we have things like core LFBs. > Caught by Alistair Munro, to quote: > > --- > Definitions: LFB type is defined as a "packet processing function" but some > LFBs, (e.g. the protocol LFBs in 3.3.2, 6.2 - these aren't really > "fine-grain" either), do not process packets. Perhaps it should be a > "processing function... generally operating upon packets...". Probably > taken from the Model? > --- > capturing aso we dont loose it. > > > I suggest to solve this issue by modifying the LFB definition in either the FE model and the protocol draft as below: > from: > LFB (Logical Functional Block) Class (or type) -- A template representing a fine-grained, logically > separable and well-defined packet processing operation in the datapath. LFB classes are the basic > building blocks of the FE model. > to: > LFB (Logical Functional Block) Class (or type) -- A template representing a fine-grained, logically > separable and well-defined packet processing operation in the datapath, or a functinal block for > protocol operation in FE. LFB classes are the basic building blocks of the FE model. BTW, I am really suprised at the weak definitions of LFB; i just glanced at model and framework docs. Probably you want to emphasize the following: - it resides at the FE (since we killed CE based LFBs) - it _may_ process packets - it is managed/controlled by the CE i.e something along: "LFB classes are the basic building blocks that are operated on by the Forces protocol. The LFB is a well defined, logically separable functional block that resides in the FE and is controlled by the CE via forces protocol. The LFB may reside at the FEs datapath and process packets or may be purely a control entity that is operated on by the CE" cheers, jamal > Any comments?Thanks,Weiming > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 16 07:33:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4zhG-0004kI-Qr for forces-archive@megatron.ietf.org; Tue, 16 Aug 2005 07:33:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04001 for ; Tue, 16 Aug 2005 07:33:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E50Ga-0006Rh-Ec for forces-archive@IETF.ORG; Tue, 16 Aug 2005 08:10:05 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010CE5D5@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 7:33:32 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82751547 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 07:33:32 -0400 Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 07:33:31 -0400 Received: from localhost.localdomain ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2005081604380146:40666 ; Tue, 16 Aug 2005 04:38:01 -0700 References: <006401c5a20d$c952f9a0$3f73c0dc@WwmLapSamsung> <009801c5a235$c0cb1bf0$3f73c0dc@WwmLapSamsung> <1124190518.6727.35.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 08/16/2005 04:38:01 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 08/16/2005 04:38:02 AM, Serialize complete at 08/16/2005 04:38:02 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Approved-By: Jamal Hadi Salim Message-ID: <1124192009.6727.53.camel@localhost.localdomain> Date: Tue, 16 Aug 2005 07:33:29 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 9] Fix LFB definition Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1124190518.6727.35.camel@localhost.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit On Tue, 2005-16-08 at 07:08 -0400, Jamal Hadi Salim wrote: > BTW, I am really suprised at the weak definitions of LFB; i just glanced > at model and framework docs. To emphasize again: the definition in the model/protocol draft is weak. Weimings editing should fix that. But what about the Framework? or even the requirements RFC? Neither has any mention of LFB. Is there anything that can be done or is it unnecessary? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 16 09:56:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E51vw-0002W5-Ar for forces-archive@megatron.ietf.org; Tue, 16 Aug 2005 09:56:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12016 for ; Tue, 16 Aug 2005 09:56:50 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E52VD-0001lG-BB for forces-archive@IETF.ORG; Tue, 16 Aug 2005 10:33:24 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010CE6D1@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 9:56:46 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82760888 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 09:56:45 -0400 Received: from 209.119.1.39 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 09:56:45 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <14.0058E9F3@grape.ease.lsoft.com>; Tue, 16 Aug 2005 9:56:45 -0400 Message-ID: Date: Tue, 16 Aug 2005 09:56:45 -0400 Reply-To: Dong Ligang Sender: Forwarding and Control Element Separation From: Dong Ligang Subject: Re: [issue 9] Fix LFB definition To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 I think not all LFBs (at least not entire LFB) are managed/controlled by the CE. As we konw, there exists some LFB attributes that managed by FE manager not CE. regards Ligang ------------------- BTW, I am really suprised at the weak definitions of LFB; i just glanced at model and framework docs. Probably you want to emphasize the following: - it resides at the FE (since we killed CE based LFBs) - it _may_ process packets - it is managed/controlled by the CE i.e something along: "LFB classes are the basic building blocks that are operated on by the Forces protocol. The LFB is a well defined, logically separable functional block that resides in the FE and is controlled by the CE via forces protocol. The LFB may reside at the FEs datapath and process packets or may be purely a control entity that is operated on by the CE" cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 16 11:27:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53Ll-0002Mk-Ec for forces-archive@megatron.ietf.org; Tue, 16 Aug 2005 11:27:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17999 for ; Tue, 16 Aug 2005 11:27:34 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E53us-00046q-Ow for forces-archive@IETF.ORG; Tue, 16 Aug 2005 12:04:10 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010CE856@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 11:27:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82772114 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 11:27:17 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 11:27:17 -0400 Received: from [68.80.132.222] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11884290; Tue, 16 Aug 2005 11:27:15 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050816112427.0302f538@localhost> Date: Tue, 16 Aug 2005 11:27:11 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue 9] Fix LFB definition Comments: To: Dong Ligang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 I guess this depends upon interpretation. 1) It is extremely unlikely that the FE Manager will control any LFBs. 2) Some LFBs are set up and their parameter settings controlled by the FE itself. 3) All LFBs are there for CE interaction. An LFB which the CE neither reads nor writes serves no purpose. An attribute in an LFB which a CE can not write and has no reason to read serves no purpose. Phrased differently, LFBs are an abstraction of FE functionality for the purpose of working with the CE. It is true that some LFBs are not modifiable, but they will still be examined by the CE. (And such LFBs will severely limit what the CE can do.) Yours, Joel M. Halpern At 09:56 AM 8/16/2005, Dong Ligang wrote: >I think not all LFBs (at least not entire LFB) are managed/controlled by >the CE. >As we konw, there exists some LFB attributes >that managed by FE manager not CE. > >regards >Ligang > >------------------- >BTW, I am really suprised at the weak definitions of LFB; i just glanced >at model and framework docs. > >Probably you want to emphasize the following: >- it resides at the FE (since we killed CE based LFBs) >- it _may_ process packets >- it is managed/controlled by the CE > >i.e something along: >"LFB classes are the basic building blocks that are operated on by the >Forces protocol. The LFB is a well defined, logically separable >functional block that resides in the FE and is controlled by the CE via >forces protocol. The LFB may reside at the FEs datapath and process >packets or may be purely a control entity that is operated on by the CE" > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 16 11:36:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53U6-0004Ns-6U for forces-archive@megatron.ietf.org; Tue, 16 Aug 2005 11:36:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18553 for ; Tue, 16 Aug 2005 11:36:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E543G-0004Oh-76 for forces-archive@IETF.ORG; Tue, 16 Aug 2005 12:12:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.010CE7CF@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 11:36:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82773279 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 11:35:59 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 11:35:57 -0400 Received: from [220.192.116.250] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Wed, 17 Aug 2005 00:04:17 +0800 (CST) References: <006401c5a20d$c952f9a0$3f73c0dc@WwmLapSamsung> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <012101c5a277$33c71460$3f73c0dc@WwmLapSamsung> Date: Tue, 16 Aug 2005 23:08:43 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: [Editorial #2] Introduction To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Hi, followed is a supposed editorial change to the protocol draft. Pls send your comments if any. Thanks, Weiming 1. Introduction This specification provides a draft definition of an IP-based protocol for Control Element control of an Forwarding Element. The protocol is a TLV based protocol that include commands for transport of LFB information as well as TLVs for association, configuration, status, and events. This specification does not specify a transport mechanism for messages, but does include a discussion of the services that must be provided by the transport interface. 1.1 Sections of this document Section 2 provides a glossary of terminology used in the specification. Section 3 provides an overview of the protocol including a discussion on the protocol framework, descriptions of the protocol layer (PL) and a transport mapping layer (TML), as well as of the ForCES protocol mechanisms. While this document does not define the TML, Section 4 details the services that the TML must provide. The Forces protocol is defined to have a common header for all other message types. The header is defined in Section 5.1, while the protocol messages are defined in Section 6. Section 7 describes several Protocol Scenarios and includes message exchange descriptions. Section 8 describes mechanism in the protocol to support high availability mechanisms including redundancy and fail over. Section 9 defines the security mechanisms provided by the PL and TML. 1. Introduction Forwarding and Control Element Separation (ForCES) aims to define an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in an ForCES Network Element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3764 has defined the ForCES framework. While there may be multiple protocols used within the overall ForCES architecture, the term "ForCES protocol" refers only to the protocol used to standardize the information exchange between Control Elements(CEs) and Forwarding Elements(FEs) only. ForCES FE model [FE-MODEL] represents the capabilities, state and configuration of FEs within the context of the ForCES protocol, so that CEs can accordingly control the FEs in a standardizded way and by means of the ForCES protocol. This document defines the specifications for the ForCES protocol. Basically, the ForCES protocol works in a master-slave mode in which FEs are slaves and CEs are masters. The ForCES protocol is a message exchange protocol, information exchanged between FEs and CEs is always in the form of protocol messages. The protocol is also a TLV based protocol that include commands for transport of LFB information as well as TLVs for association, configuration, status, and event notifications, etc. Section 2 provides a glossary of terminology used in the specification. Section 3 provides an overview of the protocol including a discussion on the protocol framework, descriptions of the Protocol Layer (PL) and a Transport Mapping Layer (TML), as well as of the ForCES protocol mechanisms. While this document does not define any specific TML, Section 4 details the services that a TML must provide (TML requirements). The ForCES protocol is defined to have a common header for all protocol messages. The header is defined in Section 5.1, while the actual protocol messages are defined in Section 6. Section 7 describes several protocol scenarios and includes message exchange descriptions. Section 8 describes mechanism in the protocol to support high availability mechanisms including redundancy and fail over. Section 9 defines the security mechanisms provided by the PL and TML. From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 16 11:44:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53cJ-0005ne-4S for forces-archive@megatron.ietf.org; Tue, 16 Aug 2005 11:44:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19002 for ; Tue, 16 Aug 2005 11:44:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E54Be-0004dQ-Gx for forces-archive@IETF.ORG; Tue, 16 Aug 2005 12:21:14 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010CE9C8@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 11:44:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82773601 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 11:44:40 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 11:44:38 -0400 Received: from [220.192.116.250] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Wed, 17 Aug 2005 00:13:19 +0800 (CST) References: <006401c5a20d$c952f9a0$3f73c0dc@WwmLapSamsung> <009801c5a235$c0cb1bf0$3f73c0dc@WwmLapSamsung> <1124190518.6727.35.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <014c01c5a278$76ec73b0$3f73c0dc@WwmLapSamsung> Date: Tue, 16 Aug 2005 23:37:48 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 9] Fix LFB definition To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ----- Original Message ----- From: "Jamal Hadi Salim" > BTW, I am really suprised at the weak definitions of LFB; i just glanced > at model and framework docs. > > Probably you want to emphasize the following: > - it resides at the FE (since we killed CE based LFBs) > - it _may_ process packets > - it is managed/controlled by the CE > > i.e something along: > "LFB classes are the basic building blocks that are operated on by the > Forces protocol. The LFB is a well defined, logically separable > functional block that resides in the FE and is controlled by the CE via > forces protocol. The LFB may reside at the FEs datapath and process > packets or may be purely a control entity that is operated on by the CE" I'm fine with the definition. How about model team thought? We need to be consistent between the protocol and the team on the definition. Jamal, when it is solved, I will immediately modify the definition in the protocol draft. Thanks, Weiming > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 16 11:58:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53pO-0008Re-9L for forces-archive@megatron.ietf.org; Tue, 16 Aug 2005 11:58:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19650 for ; Tue, 16 Aug 2005 11:58:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E54Ok-00051D-1z for forces-archive@IETF.ORG; Tue, 16 Aug 2005 12:34:47 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010CE9F2@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 11:58:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82774275 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 11:58:11 -0400 Received: from 195.212.29.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 11:58:10 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j7GFwAqQ230250 for ; Tue, 16 Aug 2005 15:58:10 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7GFwAc3244870 for ; Tue, 16 Aug 2005 16:58:10 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j7GF5m8P028364 for ; Tue, 16 Aug 2005 16:05:48 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j7GF5mNv028361 for ; Tue, 16 Aug 2005 16:05:48 +0100 Received: from [127.0.0.1] (dhcp69-10.zurich.ibm.com [9.4.69.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA41716 for ; Tue, 16 Aug 2005 17:58:09 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.uk.ibm.com id j7GFwAqQ230250 Approved-By: Robert Haas Message-ID: <43020D11.5030400@zurich.ibm.com> Date: Tue, 16 Aug 2005 17:58:09 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: ForCES WG meeting minutes, IETF 63, Paris, Aug 1 2005. To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <42F8998F.9060109@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Hi All, I have updated the tracker for all issues discussed and resolved at the=20 Paris wg meeting. The status remains "Pending" for most of them as long=20 as the text has not been put in the draft. See below for the details. Regards, -Robert > > > Issue 28: Multiple LFB instances select (under the same LFB-select TLV). > Reject. Updated in the tracker. Text in the draft must be updated (or removed). > > > > Issue 32: Packet redirect with two LFBs: sink and tap. Encapsulation of > redirected packet in a Redirect Message and TLVs. Static metadata > assignment, with metada transcoding. Accept. Updated in the tracker. Remains "pending" until changes are reflected in=20 the draft. > > Issue 33: Command pipelining is inherently permitted ny the protocol. > Correlators may be used to match responses with requests. Accept. > Updated in the tracker. I proposed text for that section. > Issue 34: Header flags: text will be provided to set the precise meanin= g > of the ACK, priority flags. Throttle flag will be dropped. Pending. Updated in the tracker. > > Issue 36: FE/CE failover. CE failover policy determines if the FE shoul= d > continue or stop forwarding packets after an association is lost. FE > failover policy determines how the FE should behave after it regains an > association, currently: start from default state again (no fast > recovery). Accept. Updated in tracker, text proposed. Must be added to the draft. > > Issue 37: Remove requirement for the FE Protocol LFB. Instead, global > defaults must be used. Heartbeat at 300 ms, with a Association Expiry > timer of 900 ms. Accept. Updated in tracker. Text must be removed/changed in the draft. > > Issue 40: BLOCK operations. May include in a future release of the > protocol. Reject. Updated in tracker. Need to remove references to BLOCK operation tin the=20 draft. > > Issue 47: PL sequence number and correlator. Convert the sequence numbe= r > and the correlator into a 64-bit correlator. Correlator used in Config > and Query messages. Must be set to 0 for Notifications. Updated in tracker. Need to make changes in the draft. > > > > Issue 52: Association Setup. Unsolicited information can be transmitted > in the Association Setup message from the FE, using GET-RESPONSE. CE ca= n > set attributes with the Association Setup Response using SET. Accept. Updated in tracker. Need text for the draft. > > Issue 55: Recovery of transactions in intermediate state after > association comes back up. Relates to issue 36. Reject. Updated in tracker. > > Issue 56: Association Setup Result TLV. Accept. Updated in tracker. Need to copy proposed text in the draft. > > Issue 57: Operation types. Updated in tracker. Need to copy proposed text in the draft. > > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 16 12:22:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E54CX-0005zm-Eg for forces-archive@megatron.ietf.org; Tue, 16 Aug 2005 12:22:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21836 for ; Tue, 16 Aug 2005 12:22:06 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E54lu-0005wE-I7 for forces-archive@IETF.ORG; Tue, 16 Aug 2005 12:58:42 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.010CE950@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 12:22:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82775421 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 12:22:07 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 12:21:56 -0400 Received: from [220.192.116.250] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Wed, 17 Aug 2005 00:50:35 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <021001c5a27d$ab405960$3f73c0dc@WwmLapSamsung> Date: Wed, 17 Aug 2005 00:15:04 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: ForCES WG meeting minutes, IETF 63, Paris, Aug 1 2005. To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Robert, very clear description. I will update the text accordingly. Thanks very much. Weiming ----- Original Message ----- From: "Robert Haas" Hi All, I have updated the tracker for all issues discussed and resolved at the Paris wg meeting. The status remains "Pending" for most of them as long as the text has not been put in the draft. See below for the details. Regards, -Robert > > > Issue 28: Multiple LFB instances select (under the same LFB-select TLV). > Reject. Updated in the tracker. Text in the draft must be updated (or removed). > > > > Issue 32: Packet redirect with two LFBs: sink and tap. Encapsulation of > redirected packet in a Redirect Message and TLVs. Static metadata > assignment, with metada transcoding. Accept. Updated in the tracker. Remains "pending" until changes are reflected in the draft. > > Issue 33: Command pipelining is inherently permitted ny the protocol. > Correlators may be used to match responses with requests. Accept. > Updated in the tracker. I proposed text for that section. > Issue 34: Header flags: text will be provided to set the precise meaning > of the ACK, priority flags. Throttle flag will be dropped. Pending. Updated in the tracker. > > Issue 36: FE/CE failover. CE failover policy determines if the FE should > continue or stop forwarding packets after an association is lost. FE > failover policy determines how the FE should behave after it regains an > association, currently: start from default state again (no fast > recovery). Accept. Updated in tracker, text proposed. Must be added to the draft. > > Issue 37: Remove requirement for the FE Protocol LFB. Instead, global > defaults must be used. Heartbeat at 300 ms, with a Association Expiry > timer of 900 ms. Accept. Updated in tracker. Text must be removed/changed in the draft. > > Issue 40: BLOCK operations. May include in a future release of the > protocol. Reject. Updated in tracker. Need to remove references to BLOCK operation tin the draft. > > Issue 47: PL sequence number and correlator. Convert the sequence number > and the correlator into a 64-bit correlator. Correlator used in Config > and Query messages. Must be set to 0 for Notifications. Updated in tracker. Need to make changes in the draft. > > > > Issue 52: Association Setup. Unsolicited information can be transmitted > in the Association Setup message from the FE, using GET-RESPONSE. CE can > set attributes with the Association Setup Response using SET. Accept. Updated in tracker. Need text for the draft. > > Issue 55: Recovery of transactions in intermediate state after > association comes back up. Relates to issue 36. Reject. Updated in tracker. > > Issue 56: Association Setup Result TLV. Accept. Updated in tracker. Need to copy proposed text in the draft. > > Issue 57: Operation types. Updated in tracker. Need to copy proposed text in the draft. > > -- Dr. Robert R. Haas IBM Zurich Research Laboratory Säumerstrasse 4 CH-8803 Rüschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 16 22:34:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Dkp-00078r-4f for forces-archive@megatron.ietf.org; Tue, 16 Aug 2005 22:34:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01697 for ; Tue, 16 Aug 2005 22:34:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5EKG-0006ps-L3 for forces-archive@IETF.ORG; Tue, 16 Aug 2005 23:10:49 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010CF003@cherry.ease.lsoft.com>; Tue, 16 Aug 2005 22:34:04 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82814860 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 16 Aug 2005 22:34:03 -0400 Received: from 209.119.0.34 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 16 Aug 2005 22:34:03 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <8.0058F6A4@grape.ease.lsoft.com>; Tue, 16 Aug 2005 22:34:03 -0400 Message-ID: Date: Tue, 16 Aug 2005 22:34:03 -0400 Reply-To: Dong Ligang Sender: Forwarding and Control Element Separation From: Dong Ligang Subject: Re: [issue 9] Fix LFB definition To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Ok, it is clarification of FE&LFB attributes. If a parameter in FE or LFB cannot be managed (read and/or write) by CE, then this parameter is neither FE nor LFB attribute. I am fine with this understanding. regards Ligang ----- Original Message ----- From: "Joel M. Halpern" To: "Dong Ligang" ; Sent: Tuesday, August 16, 2005 11:27 PM Subject: Re: [issue 9] Fix LFB definition > I guess this depends upon interpretation. > 1) It is extremely unlikely that the FE Manager will control any LFBs. > 2) Some LFBs are set up and their parameter settings controlled by the FE > itself. > 3) All LFBs are there for CE interaction. An LFB which the CE neither > reads nor writes serves no purpose. An attribute in an LFB which a CE can > not write and has no reason to read serves no purpose. > > Phrased differently, LFBs are an abstraction of FE functionality for the > purpose of working with the CE. > It is true that some LFBs are not modifiable, but they will still be > examined by the CE. (And such LFBs will severely limit what the CE can do.) > > Yours, > Joel M. Halpern > > At 09:56 AM 8/16/2005, Dong Ligang wrote: > >I think not all LFBs (at least not entire LFB) are managed/controlled by > >the CE. > >As we konw, there exists some LFB attributes > >that managed by FE manager not CE. > > > >regards > >Ligang > > > >------------------- > >BTW, I am really suprised at the weak definitions of LFB; i just glanced > >at model and framework docs. > > > >Probably you want to emphasize the following: > >- it resides at the FE (since we killed CE based LFBs) > >- it _may_ process packets > >- it is managed/controlled by the CE > > > >i.e something along: > >"LFB classes are the basic building blocks that are operated on by the > >Forces protocol. The LFB is a well defined, logically separable > >functional block that resides in the FE and is controlled by the CE via > >forces protocol. The LFB may reside at the FEs datapath and process > >packets or may be purely a control entity that is operated on by the CE" > > > >cheers, > >jamal > From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 17 10:37:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5P39-00076Z-M3 for forces-archive@megatron.ietf.org; Wed, 17 Aug 2005 10:37:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04730 for ; Wed, 17 Aug 2005 10:37:49 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Pcd-0001N5-0K for forces-archive@IETF.ORG; Wed, 17 Aug 2005 11:14:36 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010CF7D1@cherry.ease.lsoft.com>; Wed, 17 Aug 2005 10:37:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82882303 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 17 Aug 2005 10:37:41 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 17 Aug 2005 10:37:40 -0400 Received: from [220.192.114.29] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Wed, 17 Aug 2005 23:06:32 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <000f01c5a338$434a3540$1d72c0dc@WwmLapSamsung> Date: Wed, 17 Aug 2005 22:30:16 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe ----- Original Message ----- From: "Robert Haas" > Issue 32: Packet redirect with two LFBs: sink and tap. Encapsulation of > redirected packet in a Redirect Message and TLVs. Static metadata > assignment, with metada transcoding. Accept. Updated in the tracker. Remains "pending" until changes are reflected in the draft. [Weiming] Most of the text has already been updated in the current version. I just suggest the following minor changes more to reflect the transcoding necessity. After this, I think the issue can be completely closed. Meta Data ILV: This is an Identifier-Length-Value format that is used to describe one meta data. The ILV has the format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data Value | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, Meta Data ID is an identifier for the meta data, which is usually defined by FE-Model[FE-MODEL]. Meta Data ILV: This is an Identifier-Length-Value format that is used to describe one meta data. The ILV has the format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data Value | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, Meta Data ID is an identifier for the meta data, which is defined by FE-Model[FE-MODEL]. This actually implies a Meta Data ID is statically assigned by FE-Model. This also implies a Meta Data ID transcoding mechanism may be necessary if a metadata traverses several LFBs while these LFBs define the metadata with different Meta Data IDs. Comments please. thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 17 10:38:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5P3K-00076p-6X for forces-archive@megatron.ietf.org; Wed, 17 Aug 2005 10:38:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04744 for ; Wed, 17 Aug 2005 10:37:59 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Pcr-0001NZ-PU for forces-archive@IETF.ORG; Wed, 17 Aug 2005 11:14:47 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010CF878@cherry.ease.lsoft.com>; Wed, 17 Aug 2005 10:37:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82882422 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 17 Aug 2005 10:37:59 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 17 Aug 2005 10:37:58 -0400 Received: from [220.192.114.29] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Wed, 17 Aug 2005 23:06:28 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <000e01c5a338$40df4fc0$1d72c0dc@WwmLapSamsung> Date: Wed, 17 Aug 2005 22:06:29 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 28] Query and Query Response - LFB Instance addessing To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de ----- Original Message ----- From: "Robert Haas" > Issue 28: Multiple LFB instances select (under the same LFB-select TLV). > Reject. Updated in the tracker. Text in the draft must be updated (or removed). [Weiming] The text has already been updated in the previous update version by weiming. This issue can be completely closed. From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 17 10:55:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PKX-0003ou-0h for forces-archive@megatron.ietf.org; Wed, 17 Aug 2005 10:55:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05711 for ; Wed, 17 Aug 2005 10:55:46 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Pu5-0001uN-34 for forces-archive@IETF.ORG; Wed, 17 Aug 2005 11:32:34 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010CFB2A@cherry.ease.lsoft.com>; Wed, 17 Aug 2005 10:55:46 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 82883858 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 17 Aug 2005 10:55:31 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 17 Aug 2005 10:55:30 -0400 Received: from [220.192.114.29] by 202.96.99.56 with StormMail ESMTP id 56870.1341347395; Wed, 17 Aug 2005 23:24:19 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <002b01c5a33a$bf9a2c70$1d72c0dc@WwmLapSamsung> Date: Wed, 17 Aug 2005 22:48:27 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: ForCES WG meeting minutes, IETF 63, Paris, Aug 1 2005. Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Robert, ----- Original Message ----- From: "Robert Haas" > Issue 33: Command pipelining is inherently permitted ny the protocol. > Correlators may be used to match responses with requests. Accept. > Updated in the tracker. I proposed text for that section. [Weiming] I see the current Hormuzd's version has included the correlator in some way, but not sure if it's all. I'm now out of town and my lap-top only reaches latest two weeks list posts, making me hard to locate your proposed text. Could you try to send the proposed text again? I then can compare to see if anything is included. Thanks a lot. Weiming From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 18 10:23:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lIi-0006be-8z for forces-archive@megatron.ietf.org; Thu, 18 Aug 2005 10:23:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08227 for ; Thu, 18 Aug 2005 10:23:22 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5lsO-0002Ff-9P for forces-archive@IETF.ORG; Thu, 18 Aug 2005 11:00:21 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.010D0B7A@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 10:23:17 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83013569 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 10:23:16 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 10:23:15 -0400 Received: from [220.192.115.146] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Thu, 18 Aug 2005 22:52:13 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> Date: Thu, 18 Aug 2005 22:10:43 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 34] Header flags To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 > Issue 34: Header flags: text will be provided to set the precise meaning > of the ACK, priority flags. Throttle flag will be dropped. Pending. Updated in the tracker. [Weiming] Hormuzd has provided text for priority flags. I suppose to provide text on ACK flags as below: - ACK indicator(2 bits) The ACK indicator flag is used by a protocol message sender to indicate the message receiver whether a response message is required back by the sender. 'NoACK' (00) - to indicate the message receiver not to send any response message back to this message sender. 'SuccessACK'(01) - to inidcate the message receiver to send a response message back only when the message has been successfully processed by the receiver. 'UnsuccessACK'(10) - to indicate the message receiver to send a response message back only when the message has been found unable to be successfully processed. In other words, if the message can be processed successfully, the sender will not expect any response from the receiver. 'ACKAll' (11) - to indicate the message receiver to send a response message back in any case. Note that the ACK indicator can only take effect after the message has been successfully received, while successful delivery of a message is always a resposibility of protocol TML. Also note that some messages defined in the following sections may have default definitions for requiring response messages. In this case, the ACK indicator will also not take effect. We summarize these definitions as below: . Association Message will always expect a response message. . Teardown Message, Redirect Message, and Heartbeat Message will always not expect a response message . Any kind of response messages will never expect further responses to these messages. Any comments? p.s., Jamal, Could you provide some text on the Batch flag and the Atomicity flag? They are still blank in the draft. Another question is, I'm not sure if the flags description is precise enough or not, because the bits location has not been provided. Thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 18 10:34:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lT9-0001U2-Bh for forces-archive@megatron.ietf.org; Thu, 18 Aug 2005 10:34:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08919 for ; Thu, 18 Aug 2005 10:34:09 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5m2m-0002bv-7j for forces-archive@IETF.ORG; Thu, 18 Aug 2005 11:11:08 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010D0BD7@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 10:33:53 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83014220 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 10:33:52 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 10:33:52 -0400 Received: from [162.83.73.96] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 11921268 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 10:33:51 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050818102932.02cc0d08@localhost> Date: Thu, 18 Aug 2005 10:33:45 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue 34] Header flags To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac I think that this needs some tuning. A single "message" with a single set of flags can contain multiple operations. We have in other places in the document stated that there are three different modes of operation: 1) All-or-none. In this case either all the operations succeed, or none are performed. It is clear how that relates to the ACK flags you describe. 2) Operate-until-error. In this case, all operations are performed sequentially until one fails. If they all succeed, then the relationship with the flags is clear. But if some succeed and then one fails, should that result in an ACK if the setting was "SuccessACK"? Should it result in an ACK if the settings was "UnsuccessACK"? 3) Perform-individually. In this case, each operation is attempted, whether the earlier operations succeeded or failed. Given that there can be multiple success and multiple failures, what should happen if the setting is either "SuccessACK" or "UnsuccessACK"? I believe we can pick and describe behaviors. But we need to do so. Yours, Joel M. Halpern At 10:10 AM 8/18/2005, Wang,Weiming wrote: > > Issue 34: Header flags: text will be provided to set the precise >meaning > > of the ACK, priority flags. Throttle flag will be dropped. Pending. > >Updated in the tracker. > >[Weiming] Hormuzd has provided text for priority flags. I suppose to >provide text on ACK flags as below: > > > - ACK indicator(2 bits) > The ACK indicator flag is used by a protocol message sender to >indicate the message receiver whether a response message is required >back by the sender. > > 'NoACK' (00) - to indicate the message receiver not to >send any response message back to this message sender. > > 'SuccessACK'(01) - to inidcate the message receiver to >send a response message back only when the message has been successfully >processed by the receiver. > > 'UnsuccessACK'(10) - to indicate the message receiver to >send a response message back only when the message has been found unable >to be successfully processed. In other words, if the message can be >processed successfully, the sender will not expect any response from the >receiver. > > 'ACKAll' (11) - to indicate the message receiver to send >a response message back in any case. > >Note that the ACK indicator can only take effect after the message has >been successfully received, while successful delivery of a message is >always a resposibility of protocol TML. > >Also note that some messages defined in the following sections may have >default definitions for requiring response messages. In this case, the >ACK indicator will also not take effect. We summarize these definitions >as below: >. Association Message will always expect a response message. >. Teardown Message, Redirect Message, and Heartbeat Message will always >not expect a response message >. Any kind of response messages will never expect further responses to >these messages. > > >Any comments? > >p.s., Jamal, Could you provide some text on the Batch flag and the >Atomicity flag? They are still blank in the draft. Another question is, >I'm not sure if the flags description is precise enough or not, because >the bits location has not been provided. > >Thanks, >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 18 10:40:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lZT-0003AI-Da for forces-archive@megatron.ietf.org; Thu, 18 Aug 2005 10:40:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09345 for ; Thu, 18 Aug 2005 10:40:41 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5m9E-0002ob-PM for forces-archive@IETF.ORG; Thu, 18 Aug 2005 11:17:41 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.010D0A8D@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 10:40:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83014600 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 10:40:38 -0400 Received: from 195.212.29.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 10:40:37 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j7IEebOA138954 for ; Thu, 18 Aug 2005 14:40:37 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7IEea5g106404 for ; Thu, 18 Aug 2005 16:40:36 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j7IEea4V032267 for ; Thu, 18 Aug 2005 16:40:36 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j7IEeaf2032258; Thu, 18 Aug 2005 16:40:36 +0200 Received: from [127.0.0.1] (sig-9-145-134-239.de.ibm.com [9.145.134.239]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA71552; Thu, 18 Aug 2005 16:40:35 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <002b01c5a33a$bf9a2c70$1d72c0dc@WwmLapSamsung> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.de.ibm.com id j7IEebOA138954 Approved-By: Robert Haas Message-ID: <43049DAC.7060403@zurich.ibm.com> Date: Thu, 18 Aug 2005 16:39:40 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: ForCES WG meeting minutes, IETF 63, Paris, Aug 1 2005. Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <002b01c5a33a$bf9a2c70$1d72c0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Weiming, Please take a look at the tracker with my proposed text (copied below): http://www.mip4.org/issues/tracker/forces/issue33 Consensus of the Paris wg meeting is that pipelining is inherently suppor= ted=20 by the protocol. Correlators may be used to match responses with requests. I propose to put this sentence in the "Command Pipelining" section: "The protocol allows any number of messages to be issued by the CE before= the=20 corresponding acknowledgments (if requested) have been returned by the FE= .=20 Hence pipelining is inherently supported by the protocol. Matching respon= ses=20 with requests messages can be done using the correlator field in the mess= age=20 header." Regards, -Robert Wang,Weiming wrote: >Robert, > >----- Original Message ----- >From: "Robert Haas" > > =20 > >>Issue 33: Command pipelining is inherently permitted ny the protocol. >>Correlators may be used to match responses with requests. Accept. >> >> =20 >> >Updated in the tracker. I proposed text for that section. > > [Weiming] I see the current Hormuzd's version has included the >correlator in some way, but not sure if it's all. I'm now out of town >and my lap-top only reaches latest two weeks list posts, making me hard >to locate your proposed text. Could you try to send the proposed text >again? I then can compare to see if anything is included. > >Thanks a lot. >Weiming > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 18 10:46:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lel-0004lv-Gr for forces-archive@megatron.ietf.org; Thu, 18 Aug 2005 10:46:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09688 for ; Thu, 18 Aug 2005 10:46:09 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5mEX-0002zS-00 for forces-archive@IETF.ORG; Thu, 18 Aug 2005 11:23:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010D0BF3@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 10:46:10 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83014900 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 10:46:09 -0400 Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 10:45:44 -0400 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j7IEjZlc026487; Thu, 18 Aug 2005 14:45:35 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j7IEjIdV032613; Thu, 18 Aug 2005 14:45:35 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005081807453409726 ; Thu, 18 Aug 2005 07:45:34 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 07:45:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [issue 9] Fix LFB definition Thread-Index: AcWieW4KAkL2AQiEQI+0Zy6VtvtxSwBii6XA X-OriginalArrivalTime: 18 Aug 2005 14:45:34.0960 (UTC) FILETIME=[7DA2B700:01C5A403] X-Scanned-By: MIMEDefang 2.44 Approved-By: "Deleganes, Ellen M" Message-ID: <468F3FDA28AA87429AD807992E22D07E06625DC1@orsmsx408> Date: Thu, 18 Aug 2005 07:46:53 -0700 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Re: [issue 9] Fix LFB definition Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable I am also fine with this definition. Regards,=20 Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Tuesday, August 16, 2005 8:38 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [issue 9] Fix LFB definition ----- Original Message ----- From: "Jamal Hadi Salim" > BTW, I am really suprised at the weak definitions of LFB; i just glanced > at model and framework docs. > > Probably you want to emphasize the following: > - it resides at the FE (since we killed CE based LFBs) > - it _may_ process packets > - it is managed/controlled by the CE > > i.e something along: > "LFB classes are the basic building blocks that are operated on by the > Forces protocol. The LFB is a well defined, logically separable > functional block that resides in the FE and is controlled by the CE via > forces protocol. The LFB may reside at the FEs datapath and process > packets or may be purely a control entity that is operated on by the CE" I'm fine with the definition. How about model team thought? We need to be consistent between the protocol and the team on the definition. Jamal, when it is solved, I will immediately modify the definition in the protocol draft. Thanks, Weiming > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 18 11:27:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mIT-0000sC-QV for forces-archive@megatron.ietf.org; Thu, 18 Aug 2005 11:27:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12529 for ; Thu, 18 Aug 2005 11:27:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5ms9-0004R1-Sa for forces-archive@IETF.ORG; Thu, 18 Aug 2005 12:04:12 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010D0BD6@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 11:27:06 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83018760 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 11:26:52 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 11:26:51 -0400 Received: from [220.192.126.98] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Thu, 18 Aug 2005 23:55:53 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <002b01c5a33a$bf9a2c70$1d72c0dc@WwmLapSamsung> <43049DAC.7060403@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <006201c5a408$49105d30$9273c0dc@WwmLapSamsung> Date: Thu, 18 Aug 2005 23:17:40 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 33] TBD - Command Pipelining To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi, The section "Command Pipelining" has been added in the draft with the text proposed by Robert as below. This issue 33 can be closed. Thanks, Weiming ----- Original Message ----- From: "Robert Haas" Weiming, Please take a look at the tracker with my proposed text (copied below): http://www.mip4.org/issues/tracker/forces/issue33 Consensus of the Paris wg meeting is that pipelining is inherently supported by the protocol. Correlators may be used to match responses with requests. I propose to put this sentence in the "Command Pipelining" section: "The protocol allows any number of messages to be issued by the CE before the corresponding acknowledgments (if requested) have been returned by the FE. Hence pipelining is inherently supported by the protocol. Matching responses with requests messages can be done using the correlator field in the message header." Regards, -Robert From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 18 11:56:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mki-0008Hn-U7 for forces-archive@megatron.ietf.org; Thu, 18 Aug 2005 11:56:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13899 for ; Thu, 18 Aug 2005 11:56:22 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5nKT-0005Et-Sx for forces-archive@IETF.ORG; Thu, 18 Aug 2005 12:33:23 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010D0C0A@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 11:50:48 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83022000 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 11:50:47 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 11:50:47 -0400 Received: from [220.192.126.186] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Fri, 19 Aug 2005 00:19:51 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E06625DC1@orsmsx408> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <007001c5a40b$a2135a60$9273c0dc@WwmLapSamsung> Date: Thu, 18 Aug 2005 23:40:58 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 9] Fix LFB definition To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Hi, The LFB class definition has been modifed in the protocol draft as below: LFB (Logical Functional Block) Class (or Type) -- the basic building blocks that are operated on by the Forces protocol. The LFB is a well defined, logically separable functional block that resides in the FE and is controlled by the CE via ForCES protocol. The LFB may reside at the FE's datapath and process packets or may be purely a control entity that is operated on by the CE. Thanks, Weiming ----- Original Message ----- From: "Deleganes, Ellen M" I am also fine with this definition. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming Sent: Tuesday, August 16, 2005 8:38 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [issue 9] Fix LFB definition ----- Original Message ----- From: "Jamal Hadi Salim" > BTW, I am really suprised at the weak definitions of LFB; i just glanced > at model and framework docs. > > Probably you want to emphasize the following: > - it resides at the FE (since we killed CE based LFBs) > - it _may_ process packets > - it is managed/controlled by the CE > > i.e something along: > "LFB classes are the basic building blocks that are operated on by the > Forces protocol. The LFB is a well defined, logically separable > functional block that resides in the FE and is controlled by the CE via > forces protocol. The LFB may reside at the FEs datapath and process > packets or may be purely a control entity that is operated on by the CE" I'm fine with the definition. How about model team thought? We need to be consistent between the protocol and the team on the definition. Jamal, when it is solved, I will immediately modify the definition in the protocol draft. Thanks, Weiming > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 18 12:11:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mz0-00050s-Kw for forces-archive@megatron.ietf.org; Thu, 18 Aug 2005 12:11:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14854 for ; Thu, 18 Aug 2005 12:11:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5nYm-0005hu-Mv for forces-archive@IETF.ORG; Thu, 18 Aug 2005 12:48:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010D0B21@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 12:11:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83028139 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 12:11:08 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 12:11:07 -0400 Received: from [220.192.126.244] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Fri, 19 Aug 2005 00:40:11 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <007c01c5a40e$792d5a80$9273c0dc@WwmLapSamsung> Date: Thu, 18 Aug 2005 23:57:42 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: [Edtorial 3] FE Object LFB consistency To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 uniformed all "FE LFB" to"FE Obejct LFB". Weiming ----- Original Message ----- From: "Robert Haas" To: Sent: Tuesday, August 16, 2005 11:58 PM Subject: Re: ForCES WG meeting minutes, IETF 63, Paris, Aug 1 2005. Hi All, I have updated the tracker for all issues discussed and resolved at the Paris wg meeting. The status remains "Pending" for most of them as long as the text has not been put in the draft. See below for the details. Regards, -Robert > > > Issue 28: Multiple LFB instances select (under the same LFB-select TLV). > Reject. Updated in the tracker. Text in the draft must be updated (or removed). > > > > Issue 32: Packet redirect with two LFBs: sink and tap. Encapsulation of > redirected packet in a Redirect Message and TLVs. Static metadata > assignment, with metada transcoding. Accept. Updated in the tracker. Remains "pending" until changes are reflected in the draft. > > Issue 33: Command pipelining is inherently permitted ny the protocol. > Correlators may be used to match responses with requests. Accept. > Updated in the tracker. I proposed text for that section. > Issue 34: Header flags: text will be provided to set the precise meaning > of the ACK, priority flags. Throttle flag will be dropped. Pending. Updated in the tracker. > > Issue 36: FE/CE failover. CE failover policy determines if the FE should > continue or stop forwarding packets after an association is lost. FE > failover policy determines how the FE should behave after it regains an > association, currently: start from default state again (no fast > recovery). Accept. Updated in tracker, text proposed. Must be added to the draft. > > Issue 37: Remove requirement for the FE Protocol LFB. Instead, global > defaults must be used. Heartbeat at 300 ms, with a Association Expiry > timer of 900 ms. Accept. Updated in tracker. Text must be removed/changed in the draft. > > Issue 40: BLOCK operations. May include in a future release of the > protocol. Reject. Updated in tracker. Need to remove references to BLOCK operation tin the draft. > > Issue 47: PL sequence number and correlator. Convert the sequence number > and the correlator into a 64-bit correlator. Correlator used in Config > and Query messages. Must be set to 0 for Notifications. Updated in tracker. Need to make changes in the draft. > > > > Issue 52: Association Setup. Unsolicited information can be transmitted > in the Association Setup message from the FE, using GET-RESPONSE. CE can > set attributes with the Association Setup Response using SET. Accept. Updated in tracker. Need text for the draft. > > Issue 55: Recovery of transactions in intermediate state after > association comes back up. Relates to issue 36. Reject. Updated in tracker. > > Issue 56: Association Setup Result TLV. Accept. Updated in tracker. Need to copy proposed text in the draft. > > Issue 57: Operation types. Updated in tracker. Need to copy proposed text in the draft. > > -- Dr. Robert R. Haas IBM Zurich Research Laboratory Säumerstrasse 4 CH-8803 Rüschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rha From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 18 12:47:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nYd-0000dS-Ed for forces-archive@megatron.ietf.org; Thu, 18 Aug 2005 12:47:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17172 for ; Thu, 18 Aug 2005 12:47:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5o8O-00071I-UC for forces-archive@IETF.ORG; Thu, 18 Aug 2005 13:24:58 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010D0CF9@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 12:47:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83030975 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 12:47:53 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 12:47:52 -0400 Received: from [220.192.116.118] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Fri, 19 Aug 2005 01:16:57 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> Date: Fri, 19 Aug 2005 00:20:43 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 36] FE/CE failover To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b > > Issue 36: FE/CE failover. CE failover policy determines if the FE should > continue or stop forwarding packets after an association is lost. FE > failover policy determines how the FE should behave after it regains an > association, currently: start from default state again (no fast > recovery). Accept. Updated in tracker, text proposed. Must be added to the draft. [Weiming] I think Hormuzd has added some in his revision as below: * FE restart policy - This specifies the behavior of the FE during a restart. For example, this would specify if the FE should start from a default state after a CE failure in the NE. * CE failover policy - This specifies the behavior of the FE during a CE failure and restart time interval. For example, this would specify if the FE should continue running or stop operation during a CE failure in the NE. I'm based on you two and propose the following: * FE restart policy - This specifies the behavior of the FE during a restart. For example, this would specify if the FE should start from scratch or from a default state after a CE failure in the NE. Default value for this attribute should be to let the FE to start from scratch. * CE failover policy - This specifies the behavior of the FE during a CE failure and restart time interval. For example, this would specify if the FE should continue running or stop operation during a CE failure in the NE. Default value for this attribute should be to let the FE to continue running. Comments please. Thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 18 12:47:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nYd-0000di-Ox for forces-archive@megatron.ietf.org; Thu, 18 Aug 2005 12:47:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17175 for ; Thu, 18 Aug 2005 12:47:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5o8Q-00071I-Gz for forces-archive@IETF.ORG; Thu, 18 Aug 2005 13:24:58 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010D0DDC@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 12:47:56 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83030979 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 12:47:54 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 12:47:54 -0400 Received: from [220.192.116.118] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Fri, 19 Aug 2005 01:16:59 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <009e01c5a413$9cfe90f0$9273c0dc@WwmLapSamsung> Date: Fri, 19 Aug 2005 00:30:04 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 37] TBD - FE Protocol Attributes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 > > Issue 37: Remove requirement for the FE Protocol LFB. Instead, global > defaults must be used. Heartbeat at 300 ms, with a Association Expiry > timer of 900 ms. Accept. Updated in tracker. Text must be removed/changed in the draft. [Weiming] The heartbeat default and Association Expiry default have been added by Hormuzd, but I think this issue has not been totally solved. Description of some of the attributes need to be added, and the defaults also. I also suggest this issue combines FE Object attributes also. I hope this issue can be discussed more on the next call or someone can provide more text on this. Thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 18 12:48:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nYe-0000du-IW for forces-archive@megatron.ietf.org; Thu, 18 Aug 2005 12:48:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17178 for ; Thu, 18 Aug 2005 12:47:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5o8R-00071P-Br for forces-archive@IETF.ORG; Thu, 18 Aug 2005 13:24:59 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.010D0D90@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 12:47:59 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83030998 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 12:47:59 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 12:47:58 -0400 Received: from [220.192.116.118] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Fri, 19 Aug 2005 01:17:03 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <009f01c5a413$9f3e95e0$9273c0dc@WwmLapSamsung> Date: Fri, 19 Aug 2005 00:34:40 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 40] BLOCK operations To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 > > Issue 40: BLOCK operations. May include in a future release of the > protocol. Reject. Updated in tracker. Need to remove references to BLOCK operation tin the draft. [Weiming] checked the file and assured all BLOCK operation has been removed. This issue can be closed. Thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 18 12:55:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ng5-0002gF-Sr for forces-archive@megatron.ietf.org; Thu, 18 Aug 2005 12:55:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17586 for ; Thu, 18 Aug 2005 12:55:39 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5oFs-0007F1-LC for forces-archive@IETF.ORG; Thu, 18 Aug 2005 13:32:40 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.010D0C01@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 12:55:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83031273 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 12:55:39 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 12:55:37 -0400 Received: from [220.192.116.118] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Fri, 19 Aug 2005 01:24:40 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <000f01c5a338$434a3540$1d72c0dc@WwmLapSamsung> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <00b701c5a414$afa5d870$9273c0dc@WwmLapSamsung> Date: Fri, 19 Aug 2005 00:48:37 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Hi The text has been updated according to the proposed change. This issue can be closed. Thanks, Weiming ----- Original Message ----- From: "Wang,Weiming" > ----- Original Message ----- > From: "Robert Haas" > > Issue 32: Packet redirect with two LFBs: sink and tap. Encapsulation > of > > redirected packet in a Redirect Message and TLVs. Static metadata > > assignment, with metada transcoding. Accept. > > Updated in the tracker. Remains "pending" until changes are reflected in > the draft. > > [Weiming] Most of the text has already been updated in the current > version. I just suggest the following minor changes more to reflect the > transcoding necessity. After this, I think the issue can be completely > closed. > > > Meta Data ILV: > This is an Identifier-Length-Value format that is used to describe > one meta data. The ILV has the format as: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Meta Data ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Meta Data Value | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Where, Meta Data ID is an identifier for the meta data, which is > usually defined by FE-Model[FE-MODEL]. > > > > Meta Data ILV: > This is an Identifier-Length-Value format that is used to describe > one meta data. The ILV has the format as: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Meta Data ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Meta Data Value | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Where, Meta Data ID is an identifier for the meta data, which is > defined by FE-Model[FE-MODEL]. This actually implies > a Meta Data ID is statically assigned by FE-Model. This also implies a > Meta Data > ID transcoding mechanism may be necessary if a metadata traverses > several LFBs > while these LFBs define the metadata with different Meta Data IDs. > > > > Comments please. > > thanks, > Weiming From owner-forces@PEACH.EASE.LSOFT.COM Thu Aug 18 23:45:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5xox-0007rV-GP for forces-archive@megatron.ietf.org; Thu, 18 Aug 2005 23:45:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26309 for ; Thu, 18 Aug 2005 23:45:28 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5yOp-0002NH-IP for forces-archive@IETF.ORG; Fri, 19 Aug 2005 00:22:36 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010D160E@cherry.ease.lsoft.com>; Thu, 18 Aug 2005 23:45:29 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83071163 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 18 Aug 2005 23:45:29 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Thu, 18 Aug 2005 23:45:28 -0400 Received: from [220.192.126.51] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Fri, 19 Aug 2005 12:14:31 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> Date: Fri, 19 Aug 2005 11:37:04 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 34] Header flags To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Joel, ----- Original Message ----- From: "Joel M. Halpern" > I think that this needs some tuning. > A single "message" with a single set of flags can contain multiple operations. > We have in other places in the document stated that there are three > different modes of operation: First of all, we should note that ACK flag does not interfere into any operations. Then, we noted that ACK flag also does not affect the response format of operations. The only effect of ACK flag is to choose a response at the time. I see the question you raised as that we may need some definitions and specifications in the operations regarding ACK flag meaning, whereas the ACK flag still keep its clearness in meaning. > 1) All-or-none. In this case either all the operations succeed, or none > are performed. It is clear how that relates to the ACK flags you describe. > 2) Operate-until-error. In this case, all operations are performed > sequentially until one fails. If they all succeed, then the relationship > with the flags is clear. But if some succeed and then one fails, should > that result in an ACK if the setting was "SuccessACK"? It should reasonably be no response then. >Should it result in > an ACK if the settings was "UnsuccessACK"? It should reasonably be of a response then. I suggest to add a text in operation-until-error description that "ACKAll" be recommended to use for such operation. > 3) Perform-individually. In this case, each operation is attempted, > whether the earlier operations succeeded or failed. Given that there can > be multiple success and multiple failures, what should happen if the > setting is either "SuccessACK" or "UnsuccessACK"? ACK flag in the header is defined to be overall of operations in the message, therefore, one failure can be reasonably taken as unsucces of the whole message operation. > > I believe we can pick and describe behaviors. But we need to do so. By your above comments, I just feel that a 'Success' or 'Unsuccess' definition should be added to the text I proposed to make it clearer. Thank you very much. Weiming > > Yours, > Joel M. Halpern > > At 10:10 AM 8/18/2005, Wang,Weiming wrote: > > > Issue 34: Header flags: text will be provided to set the precise > >meaning > > > of the ACK, priority flags. Throttle flag will be dropped. Pending. > > > >Updated in the tracker. > > > >[Weiming] Hormuzd has provided text for priority flags. I suppose to > >provide text on ACK flags as below: > > > > > > - ACK indicator(2 bits) > > The ACK indicator flag is used by a protocol message sender to > >indicate the message receiver whether a response message is required > >back by the sender. > > > > 'NoACK' (00) - to indicate the message receiver not to > >send any response message back to this message sender. > > > > 'SuccessACK'(01) - to inidcate the message receiver to > >send a response message back only when the message has been successfully > >processed by the receiver. > > > > 'UnsuccessACK'(10) - to indicate the message receiver to > >send a response message back only when the message has been found unable > >to be successfully processed. In other words, if the message can be > >processed successfully, the sender will not expect any response from the > >receiver. > > > > 'ACKAll' (11) - to indicate the message receiver to send > >a response message back in any case. > > > >Note that the ACK indicator can only take effect after the message has > >been successfully received, while successful delivery of a message is > >always a resposibility of protocol TML. > > > >Also note that some messages defined in the following sections may have > >default definitions for requiring response messages. In this case, the > >ACK indicator will also not take effect. We summarize these definitions > >as below: > >. Association Message will always expect a response message. > >. Teardown Message, Redirect Message, and Heartbeat Message will always > >not expect a response message > >. Any kind of response messages will never expect further responses to > >these messages. > > > > > >Any comments? > > > >p.s., Jamal, Could you provide some text on the Batch flag and the > >Atomicity flag? They are still blank in the draft. Another question is, > >I'm not sure if the flags description is precise enough or not, because > >the bits location has not been provided. > > > >Thanks, > >Weiming From owner-forces@PEACH.EASE.LSOFT.COM Fri Aug 19 01:15:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5zE2-0004TT-6z for forces-archive@megatron.ietf.org; Fri, 19 Aug 2005 01:15:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29505 for ; Fri, 19 Aug 2005 01:15:29 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5znu-0004Wc-9J for forces-archive@IETF.ORG; Fri, 19 Aug 2005 01:52:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010D1757@cherry.ease.lsoft.com>; Fri, 19 Aug 2005 1:15:27 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83076567 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 19 Aug 2005 01:15:05 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 19 Aug 2005 01:15:04 -0400 Received: from [220.192.116.188] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Fri, 19 Aug 2005 13:44:16 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <00e001c5a47b$fbae8b60$9273c0dc@WwmLapSamsung> Date: Fri, 19 Aug 2005 13:07:58 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 47] PL sequence number and correlator To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 > > Issue 47: PL sequence number and correlator. Convert the sequence number > and the correlator into a 64-bit correlator. Correlator used in Config > and Query messages. Must be set to 0 for Notifications. Updated in tracker. Need to make changes in the draft. Robert, I don't think to remove the Sequence Number is the consensus we reached. I have for several times noted that SN will be used in several cases. Note that SN will be the only key to order back messages for messages transported over unreliable TMLs. I can currently think of that the redirect message will definitely need the SN to order back redirect data. I also think of the future, when SN may be used by CE and FE to syncronize the messages. It's a little too early to deliminate the necessity, I'm afraid. How others think? Thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Fri Aug 19 01:19:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5zIB-0005qf-Je for forces-archive@megatron.ietf.org; Fri, 19 Aug 2005 01:19:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29644 for ; Fri, 19 Aug 2005 01:19:46 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5zs5-0004bz-14 for forces-archive@IETF.ORG; Fri, 19 Aug 2005 01:56:53 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010D178E@cherry.ease.lsoft.com>; Fri, 19 Aug 2005 1:19:46 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83076762 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 19 Aug 2005 01:19:45 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 19 Aug 2005 01:19:36 -0400 Received: from [220.192.116.188] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Fri, 19 Aug 2005 13:48:37 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <00ea01c5a47c$97488760$9273c0dc@WwmLapSamsung> Date: Fri, 19 Aug 2005 13:12:17 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 52] Association Setup. To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c > Issue 52: Association Setup. Unsolicited information can be transmitted > in the Association Setup message from the FE, using GET-RESPONSE. CE can > set attributes with the Association Setup Response using SET. Accept. Updated in tracker. Need text for the draft. Hormuzd, Could you provide an updated text regarding this issue to let me put in? Then we can close it. Thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Fri Aug 19 01:33:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5zVN-00015O-7M for forces-archive@megatron.ietf.org; Fri, 19 Aug 2005 01:33:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00150 for ; Fri, 19 Aug 2005 01:33:23 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E605G-0004wr-O4 for forces-archive@IETF.ORG; Fri, 19 Aug 2005 02:10:30 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010D1669@cherry.ease.lsoft.com>; Fri, 19 Aug 2005 1:33:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83077240 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 19 Aug 2005 01:33:09 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 19 Aug 2005 01:33:08 -0400 Received: from [220.192.116.188] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Fri, 19 Aug 2005 14:02:20 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> Date: Fri, 19 Aug 2005 13:26:00 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 56] Result TLV and result codes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 > > Issue 56: Association Setup Result TLV. Accept. Updated in tracker. Need to copy proposed text in the draft. [Weiming] Hormuzd has added the error codes in the association setup response message in the revision. I'm not sure if this issue has also related to more than this. If not, then this issue can be closed. Thank, Weiming From DaleMcneal@barmbrack.com Sun Aug 21 11:24:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6rg8-0007i2-DM for forces-archive@megatron.ietf.org; Sun, 21 Aug 2005 11:24:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04966 for ; Sun, 21 Aug 2005 11:24:05 -0400 (EDT) Received: from [62.57.209.40] (helo=40.red-62-57-209.user.auna.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E6sGO-0001N1-DT for forces-archive@ietf.org; Sun, 21 Aug 2005 12:01:44 -0400 Received: from Zbz5@localhost by K4Z.int (8.11.6/8.11.6); Sun, 21 Aug 2005 19:13:56 +0300 Message-ID: From: "Olen Pierce" Reply-To: "Olen Pierce" To: forces-archive@ietf.org, ujuyjyht@ietf.org, katherine.lange@ietf.org Subject: AutoCAD & Office XP Software Starting at $29 Date: Sun, 21 Aug 2005 17:13:56 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: DaleMcneal@barmbrack.com Content-Type: multipart/mixed; boundary="--gKOph1WAwlZJ7tL8x" X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb NVa ----gKOph1WAwlZJ7tL8x Content-Type: text/html; Content-Transfer-Encoding: quoted-printable M
Opt-in Email Special Offer   = ;  unsubscribe me
=
SEARCH

<= /table>

TOP 10 NEW TITLES

9= =

 = ON SALE NOW!

 1 Office Pro 2003
 2 A= dobe Photoshop 9.0
 3 Windows XP Pro
 4 A= dobe Acrobat 7 Pro
 5 Flash MX 2004
 6 Corel Draw 12
 7 Nort= on Antivirus 2005
 8 Windows 2003 Server
  Alias Maya 6 Wavefrt
 10 Adobe Illustrator 11
  See more by this manufacturer<= /b>
   Microsoft
=    Symantec
   Adobe
  Customers also bought
   these othe= r items...

Microsoft Office Professional Edition *2003*
Microsoft

Choose:
 <= a href=3Dhttp://number1soft.net/?v>

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (86= %)



Availability:= Available for INSTANT download!
Coupon Code: hJcMe
 <= /p>

Sales Rank: #1
System requirements&nbs= p; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review: Based on 1= 192 reviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

C= hoose:
 

=



Availability: Available for INSTANT do= wnload!
Coupon Code: wQkIS
 

Sales Rank: #2
System requirements  |  Other Versions
Da= te Coupon Expires: August 31st, 2005
= Average Customer Review:3D"5 Based on 1154 reviews. Write a review.

List Price:$599.00=
Price:$69.99
= You Save:$529.01 (90%)

Microso= ft Windows XP Professional or Longhorn Edition
Microsoft

Choose:<= /tr>
 

List Price:$279.00
Price:= $49.99
You Save:$229.01 (8= 5%)



Availability: Available for INSTANT download!
Coupon Code: 3jlzRNke
&nb= sp;

Sales Rank: #3
System requirements=   |  Other Versions
Date Coupon Expires: August 31st, 2005 Average Customer Review:3D"5 Based = on 179185 reviews. Write a review.=

Adobe Acrobat Professional V 7.0
= Adobe

Choose:
&= nbsp;

=

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability:= Available for INSTANT download!
Coupon Code: qdX0QVAe
&nbs= p;

Sales Rank: #4
System requirements&= nbsp; |  Other Versions
Date Coupon Expires: August 31st, 2005
= Average Customer Review:3D"5 Based o= n 1214 reviews. Write a review.

----gKOph1WAwlZJ7tL8x-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Aug 22 11:41:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EQo-0001gO-R8 for forces-archive@megatron.ietf.org; Mon, 22 Aug 2005 11:41:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23424 for ; Mon, 22 Aug 2005 11:41:45 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7F1L-0004rC-J9 for forces-archive@IETF.ORG; Mon, 22 Aug 2005 12:19:36 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010D48A6@cherry.ease.lsoft.com>; Mon, 22 Aug 2005 11:41:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83481685 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Aug 2005 11:41:42 -0400 Received: from 195.212.29.136 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 22 Aug 2005 11:41:41 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j7MFg3Fi268726 for ; Mon, 22 Aug 2005 16:42:03 +0100 Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7MFfZXZ272670 for ; Mon, 22 Aug 2005 16:41:35 +0100 Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j7MFfZdo006139 for ; Mon, 22 Aug 2005 16:41:35 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j7MFfZ2R006117; Mon, 22 Aug 2005 16:41:35 +0100 Received: from [127.0.0.1] (dhcp69-10.zurich.ibm.com [9.4.69.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA28998; Mon, 22 Aug 2005 17:41:34 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate3.uk.ibm.com id j7MFg3Fi268726 Approved-By: Robert Haas Message-ID: <4309F1F9.8020604@zurich.ibm.com> Date: Mon, 22 Aug 2005 17:40:41 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [issue 34] Header flags Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Weiming, One comment on the text you proposed: > 'ACKAll' (11) - to indicate the message receiver to send >a response message back in any case. > >Note that the ACK indicator can only take effect after the message has >been successfully received, while successful delivery of a message is >always a resposibility of protocol TML. > =20 > I don't understand the sentence above. Did we mean instead: "Note that=20 the ACK indicator can only take effect after the message has been=20 successfully PROCESSED, [..] " ? And what do we mean exactly by "take effect" ? On a follow-up posting on the same topic: > > =20 > >>> 3) Perform-individually. In this case, each operation is attempted, >>> whether the earlier operations succeeded or failed. Given that there= can >> >>> be multiple success and multiple failures, what should happen if the >>> setting is either "SuccessACK" or "UnsuccessACK"? >> =20 >> > ACK flag in the header is defined to be overall of operations in the=20 > message, therefore, one failure can be reasonably taken as unsucces of=20 > the whole message operation. I agree: anything else than a complete success is a failure, i.e., for=20 the all-or-none, operate-until-error, and perform-individually schemes,=20 if any single operation in the message fails, then it will result in a=20 response only if the UnsuccessACK is set (or AckAll obviously too). Regards, --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Mon Aug 22 12:20:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7F1q-0002HU-4Y for forces-archive@megatron.ietf.org; Mon, 22 Aug 2005 12:20:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26136 for ; Mon, 22 Aug 2005 12:20:03 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7FcM-0006F8-Pn for forces-archive@IETF.ORG; Mon, 22 Aug 2005 12:57:55 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010D48E1@cherry.ease.lsoft.com>; Mon, 22 Aug 2005 12:20:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83485302 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Aug 2005 12:20:00 -0400 Received: from 195.212.29.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 22 Aug 2005 12:19:59 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j7MGJwKT196178 for ; Mon, 22 Aug 2005 16:19:58 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7MGJwXZ247234 for ; Mon, 22 Aug 2005 17:19:58 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j7MFUYKu032200 for ; Mon, 22 Aug 2005 16:30:35 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j7MFUY1L032197; Mon, 22 Aug 2005 16:30:34 +0100 Received: from [127.0.0.1] (dhcp69-10.zurich.ibm.com [9.4.69.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA60370; Mon, 22 Aug 2005 18:19:57 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00e001c5a47b$fbae8b60$9273c0dc@WwmLapSamsung> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.uk.ibm.com id j7MGJwKT196178 Approved-By: Robert Haas Message-ID: <4309FAFB.9080702@zurich.ibm.com> Date: Mon, 22 Aug 2005 18:19:07 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [Issue 47] PL sequence number and correlator Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00e001c5a47b$fbae8b60$9273c0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Weiming, Well, this was the consensus among the participants at the meeting, at=20 least. But let's discuss this again: First, note that the protocol as we designed it until now _relies_ on a=20 reliable TML. For instance, if the response to a operation was lost over an unreliable=20 TML, the CE would reissue the operation. The FE would have no way to=20 realize that this second operation is actually a repetition (remember=20 that the correlator field is completely opaque to the FE). Depending on=20 the kind of operation, this could be fatal to the FE. Now, if you want to use an unreliable TML only for certain message types=20 (such as event notifications or redirected packets, nothing fatal can=20 happen if messages are lost), then we need to decide whether we want to=20 guarantee ordering at the PL level at all. This is debatable. Regards, -Robert Wang,Weiming wrote: >>Issue 47: PL sequence number and correlator. Convert the sequence >> =20 >> >number > =20 > >>and the correlator into a 64-bit correlator. Correlator used in Config >>and Query messages. Must be set to 0 for Notifications. >> =20 >> > >Updated in tracker. Need to make changes in the draft. > >Robert, > >I don't think to remove the Sequence Number is the consensus we reached. >I have for several times noted that SN will be used in several cases. >Note that SN will be the only key to order back messages for messages >transported over unreliable TMLs. I can currently think of that the >redirect message will definitely need the SN to order back redirect >data. I also think of the future, when SN may be used by CE and FE to >syncronize the messages. It's a little too early to deliminate the >necessity, I'm afraid. > >How others think? > >Thanks, >Weiming > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Mon Aug 22 13:57:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GXn-00044S-IN for forces-archive@megatron.ietf.org; Mon, 22 Aug 2005 13:57:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01181 for ; Mon, 22 Aug 2005 13:57:10 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7H8F-0000k8-Ql for forces-archive@IETF.ORG; Mon, 22 Aug 2005 14:35:01 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010D4A24@cherry.ease.lsoft.com>; Mon, 22 Aug 2005 13:57:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83490953 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Aug 2005 13:56:59 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 22 Aug 2005 13:56:51 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Tue, 23 Aug 2005 02:26:46 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <004601c5a742$fd5c9370$1f12fea9@wwm1> Date: Tue, 23 Aug 2005 01:57:40 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [Issue 57] Inconsistent operation types To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: base64 SGksDQoNCnRoZSB1cGRhdGUgcmVsYXRlZCB0byB0aGUgaXNzdWUgaXMgYXMgYmVsb3c6DQoNCj5D b25zZW5zdXMgZnJvbSBQYXJpcyB3ZyBtZWV0aW5nIG9uIHRoZSBtZXNzYWdlcyBhbmQgb3BlcmF0 aW9ucyByZXF1aXJlZDoNCj4obmVlZCB0byBiZSBwdXQgaW4gdGhlIGRyYWZ0KQ0KDQo+Q09ORklH VVJBVElPTiBtZXNzYWdlOg0KPiBTZXQgKGFsc28gdXNlZCBmb3IgZXZlbnQgc3Vic2NyaXB0aW9u KSwgRGVsZXRlDQo+Q09ORklHVVJBVElPTi1SRVNQT05TRSBtZXNzYWdlOg0KPiBTYW1lIGFzIGFi b3ZlIHdpdGggKi1yZXNwb25zZQ0KW1dlbWluZ10gaGFzIGJlZW4gdXBkYXRlZCBhbmQgaGFzIG1h ZGUgY29tcGFyYXRpdmVseSBsYXJnZSBzY2FsZSB0ZXh0IG1vZGlmeWluZyB0byB0aGlzIHNlY3Rp b24gZm9yIHRleHQgY29uc2lzdGVuY3kgd2l0aCBvdGhlciBzZWN0aW9ucywgc2VlIFtlZGl0b3Jp YWwgNF0gcG9zdC4NCg0KUVVFUlkgbWVzc2FnZToNCiBHZXQNClFVRVJZLVJFU1BPTlNFIG1lc3Nh Z2U6DQogR2V0LXJlc3BvbnNlDQpbV2VpbWluZ11IYXMgYmVlbiB1cGRhdGVkIGFuZCBtYWRlIG1p bnV0ZSBtb2RpZmljYXRpb24gdG8gd2hvbGUgc2VjdGlvbg0KDQpFVkVOVC1OT1RJRklDQVRJT04g bWVzc2FnZToNCiBSZXBvcnQNCltXZWltaW5nXVVwZGF0ZWQuIElzIGdvaW5nIHRvIGNvbXBsZXRl bHkgcmVtb3ZlIHRoZSBzZWN0aW9uIG9mIGV2ZW50IG5vdGlmaWNhdGlvbiByZXNwb25zZT8NCg0K QVNTT0NJQVRJT04tU0VUVVAgbWVzc2FnZToNCiBHZXQtcmVzcG9uc2UgKG9wdGlvbmFsLCB1c2Vk IHRvIGFkdmVydGlzZSBmaWVsZHMgZnJvbSB0aGUgRkUgTEZCIA0KYW5kL29yIEZFIFByb3RvY29s IExGQiBpbiBhbiB1bnNvbGljaXRlZCBtYW5uZXIpDQoNCltXZWltaW5nXWhhdmVuJ3QgbWFkZSBj aGFuZ2VzLiBRdWVzdGlvbnM6DQpEbyB3ZSByZWFsbHkgbmVlZCBhbiBvcGVyYXRpb24gaW4gdGhl IGFzc29jaWF0aW9uIHNldHVwIG1lc3NhZ2U/IEl0IHdpbGwgbWFrZSBmbG9vZGluZyBhdHRhY2sg bW9yZSBlYXN5LCBJIHRoaW5rLiBXaHkgZG9uJ3Qgd2UgbGV0IENFIGxhdGVyIHRvIHF1ZXJ5IHRo ZW4/DQoNCkFTU09DSUFUSU9OLVNFVFVQLVJFU1BPTlNFIG1lc3NhZ2U6DQogU2V0IChvcHRpb25h bCwgb25seSB0byBzZXQgZmllbGRzIGluIHRoZSBGRSBMRkIgYW5kL29yIEZFIFByb3RvY29sIExG QikNCltXZWltaW5nXUhhdmVuJ3QgbWFkZSBjaGFuZ2VzLiBRdWVzdGlvbnM6DQpEb2VzIHRoaXMg cmVhbGx5IG1lYW4gd2UgYWxsb3cgYSBTRVQgb3BlcmF0aW9uIHRoYXQgbmV2ZXIgYmUgYWJsZSB0 byBnZXQgU0VUIHJlc3BvbnNlPyBXaHkgZG9uJ3Qgd2UgdXNlIGNvbmZpZyBtZXNzYWdlIHRvIFNF VCB0aGVuPw0KDQpQQUNLRVQgUkVESVIsIEhFQVJUQkVBVCBkbyBub3QgaGF2ZSBvcGVyYXRpb25z Lg0KW1dlaW1pbmddaGFzIG1hZGUgbWludXRlIHRleHQgbW9kaWZpY2F0aW9uIHRvIHRoZXNlIHNl Y3Rpb25zLg0KDQpUaGFua3MsDQpXZWltaW5nDQo= From owner-forces@PEACH.EASE.LSOFT.COM Mon Aug 22 14:15:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GpD-0007Z5-V6 for forces-archive@megatron.ietf.org; Mon, 22 Aug 2005 14:15:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02328 for ; Mon, 22 Aug 2005 14:15:10 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7HPh-0001Gq-J2 for forces-archive@IETF.ORG; Mon, 22 Aug 2005 14:53:02 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010D4A1E@cherry.ease.lsoft.com>; Mon, 22 Aug 2005 14:14:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83493222 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Aug 2005 14:14:57 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 22 Aug 2005 14:14:52 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Tue, 23 Aug 2005 02:44:49 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <007c01c5a40e$792d5a80$9273c0dc@WwmLapSamsung> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0051_01C5A788.904CF2C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <005301c5a745$82a80a80$1f12fea9@wwm1> Date: Tue, 23 Aug 2005 02:15:42 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: [Edtorial 4] Configure Message (Section 6.5) modifying, also related to issue 57 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C5A788.904CF2C0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCkF0dGFjaGVkIGlzIHRoZSBzdXBwb3NlZCBtb2RpZnlpbmcgdG8gU2VjdGlvbiA2LjUg Zm9yIHRoZSBwdXJwb3NlIG9mIGNvbnNpc3RlbmN5LiBQbHMgc2VuZCB5b3VyIGNvbW1lbnRzLg0K DQpUaGFua3MsDQpXZWltaW5nDQoNCg== ------=_NextPart_000_0051_01C5A788.904CF2C0 Content-Type: text/plain; name="configmsg.txt" Content-Disposition: attachment; filename="configmsg.txt" Content-Transfer-Encoding: quoted-printable 6.5 Configuration Messages The ForCES Configuration messages are used by the CEs to configure the FEs in a ForCES NE and report the results back to the CE. 6.5.1 Config Message This message is sent by the CE to the FE to configure FE or LFB attributes. This message is also used by the CE to subscribe/ unsubscribe to FE and LFB events. Message transfer direction: CE to FE Message Header: The Message Type in the header is set MessageType=3D 'Config'. = The ACK flag in the header is can be used by the CE to turn off any response from the FE. The default behavior is to turn on the ACK to get the config response from the FE. Message body: The config message body consists of (at least) one or more than one TLV that describes entries to config. The TLV is called LFBselect TLV (with the TLV Type=3D"LFBselect"), and a generic format definition of which has been given in Section 6.1.1. Detailed data format of a LFBselect TLV for config message is as below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFBselect | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15 Doria (Ed.), et al. Expires February 24, 2006 [Page 48] =0C Internet-Draft ForCES August 2005 Type: The type of the TLV is "LFBselect" Length: Length of the TLV including the T and L fields, in bytes. LFB Class ID: This field uniquely recognizes the LFB class/type. LFB Instance ID: This field uniquely identifies the LFB instance. Operation TLV: The Operation TLV for the 'Config' message is formatted as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: The type of operation the config message supports. Currently two types of operations are defined for the config message: Type =3D "SET" --- this type of operation is to set LFB attributes Type =3D "DEL" --- this type of operation to delete some = LFB attributes PATH-DATA-TLV: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The restriction on the use of PATH-DATA-TLV for SET operation is it SHALL NOT contain any RESULT-TLV. The erstriction on the use of PATH-DATA-TLV for DEL operation is it SHALL NOT contain any DATARAW-TLV and any RESULT-TLV. *Note: FE Activate/Deactivate, Shutdown FE commands for State Maintenance will be sent using Config messages. *Note: For Event subscription, the events will be defines by the individual LFBs. To better understand the above PDU format, we can show a tree structure for the format as below: Doria (Ed.), et al. Expires February 24, 2006 [Page 49] =0C Internet-Draft ForCES August 2005 main hdr (eg type =3D config) | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D target LFB class | | | | | +-- LFBInstance =3D target LFB instance | | | | | +-- T =3D operation { SET } | | | | | +-- // one or more path targets | | // associated with DATARAW-TLV(s) | | | +-- T =3D operation { DEL } | | | | | +-- // one or more path targets 6.5.2 Config Response Message This message is sent by the FE to the CE in response to the Config message. It indicates whether the Config was successful or not on the FE and also gives a detailed response regarding the configuration result of each attribute. Message transfer direction: FE to CE Message Header: The Message Type in the header is set MessageType=3D 'Config Response'. The ACK flag in the header is always ignored, because the config response message will never expect to get any more response from the message receiver (CE). The Correlator field in the header MUST keep the same as that of the config message to be responded, so that the config message sender can keep track of the response. Message body: The Config response message body consists of (at least) one or more than one TLV that describes entries for config response. The TLV is called LFBselect TLV (with the TLV = Type=3D"LFBselect"), and a generic format definition of which has been given in Section 6.1.1. Detailed data format of one LFBselect TLV for Doria (Ed.), et al. Expires February 24, 2006 [Page 50] =0C Internet-Draft ForCES August 2005 config response message is as below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFBselect | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18 Type: The type of the TLV is "LFBselect". Length: Length of the TLV including the T and L fields, in bytes. LFB Class ID: This field uniquely recognizes the LFB class/type. LFB Instance ID: This field uniquely identifies the LFB instance. Operation TLV: The Operation TLV for the config response message is formatted as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Doria (Ed.), et al. Expires February 24, 2006 [Page 51] =0C Internet-Draft ForCES August 2005 Type: The type of operation the config response message supports. Currently two types of operations are defined for the config response message: Type =3D "SET-RESPONSE" --- this type of operation is for response of SET operation of LFB attributes Type =3D "DEL-RESPONSE" --- this type of operation is for response of DELete operation of LFB attributes PATH-DATA-TLV: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The restriction on the use of PATH-DATA-TLV for SET- RESPONSE operation is it MUST contain RESULT-TLV(s). The restriction on the use of PATH-DATA-TLV for DEL-RESPONSE operation is also it MUST contain RESULT-TLV(s). ------=_NextPart_000_0051_01C5A788.904CF2C0-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Aug 22 14:33:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7H6c-0002aC-0N for forces-archive@megatron.ietf.org; Mon, 22 Aug 2005 14:33:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03160 for ; Mon, 22 Aug 2005 14:33:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7HhD-0001mo-6T for forces-archive@IETF.ORG; Mon, 22 Aug 2005 15:11:00 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.010D49CA@cherry.ease.lsoft.com>; Mon, 22 Aug 2005 14:33:07 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83495028 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Aug 2005 14:33:02 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 22 Aug 2005 14:33:01 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 56870.804536222; Tue, 23 Aug 2005 03:02:58 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <4309F1F9.8020604@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <005901c5a748$0c187320$1f12fea9@wwm1> Date: Tue, 23 Aug 2005 02:33:53 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [issue 34] Header flags To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 2.2 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlJvYmVydCBI YWFzIiA8cmhhQHp1cmljaC5pYm0uY29tPg0KV2VpbWluZywNCg0KT25lIGNvbW1lbnQgb24gdGhl IHRleHQgeW91IHByb3Bvc2VkOg0KDQo+ICAgICAgICAgICAgICAgJ0FDS0FsbCcgKDExKSAtIHRv IGluZGljYXRlIHRoZSBtZXNzYWdlIHJlY2VpdmVyIHRvIHNlbmQNCj5hIHJlc3BvbnNlIG1lc3Nh Z2UgYmFjayBpbiBhbnkgY2FzZS4NCj4NCj5Ob3RlIHRoYXQgdGhlIEFDSyBpbmRpY2F0b3IgY2Fu IG9ubHkgdGFrZSBlZmZlY3QgIGFmdGVyICB0aGUgbWVzc2FnZSBoYXMNCj5iZWVuIHN1Y2Nlc3Nm dWxseSByZWNlaXZlZCwgd2hpbGUgc3VjY2Vzc2Z1bCBkZWxpdmVyeSBvZiBhIG1lc3NhZ2UgaXMN Cj5hbHdheXMgYSByZXNwb3NpYmlsaXR5IG9mIHByb3RvY29sIFRNTC4NCj4gIA0KPg0KSSBkb24n dCB1bmRlcnN0YW5kIHRoZSBzZW50ZW5jZSBhYm92ZS4gRGlkIHdlIG1lYW4gaW5zdGVhZDogIk5v dGUgdGhhdCANCnRoZSBBQ0sgaW5kaWNhdG9yIGNhbiBvbmx5IHRha2UgZWZmZWN0IGFmdGVyIHRo ZSBtZXNzYWdlIGhhcyBiZWVuIA0Kc3VjY2Vzc2Z1bGx5IFBST0NFU1NFRCwgWy4uXSAiID8NCkFu ZCB3aGF0IGRvIHdlIG1lYW4gZXhhY3RseSBieSAidGFrZSBlZmZlY3QiID8NCltXZWltaW5nXSBt YXliZSB0aGVyZXMgc29tZSBsYW5ndWdlIHByb2JsZW0gd2l0aCBtZSwgYnV0IHdoYXQgSSByZWFs bHkgd2FudCB0byBzYXkgaXM6DQoNCnRoZSBBQ0sgaW5kaWNhdG9yIGNhbiBwbGF5IGl0cyByb2xl IG9ubHkgdW5kZXIgdGhlIGNvbmRpdGlvbiB0aGF0IHRoZSBtZXNzYWdlIHdpdGggdGhpcyBpbmRp Y2F0b3IgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHJlY2VpdmVkLCB0aG91Z2ggaXQgZG9lc24ndCBo YXZlIHRvIHdhaXQgZm9yIHRoZSBtZXNzYWdlIHRvIGJlIHN1Y2Nlc3NmdWxseSBwcm9jZXNzZWQo ZXhlY3V0ZWQpLiAgDQoNClRvIG1lbnRpb24gdGhpcywgSSBqdXN0IHdhbnQgdG8gZXhwcmVzcyB0 aGUgaWRlYSB0aGF0IGV4Y2VwdCBzZXR0aW5nIHRvICJBQ0thbGwiLCB0aGUgQUNLIGluZGljYXRv ciBpcyBvZiBubyB1c2UgdG8gaW5oYW5jZSB0cmFuc3BvcnQgbGF5ZXIgcmVsaWFiaWxpdHkuIA0K DQpMZXQgbWUgbW9kaWZ5IHRoaXMgc2VudGVuY2UuDQoNClRoYW5rcywNCldlaW1pbmcNCiA= From owner-forces@PEACH.EASE.LSOFT.COM Mon Aug 22 15:23:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7HtR-0003g7-E9 for forces-archive@megatron.ietf.org; Mon, 22 Aug 2005 15:23:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06845 for ; Mon, 22 Aug 2005 15:23:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7IU1-0003Px-8a for forces-archive@IETF.ORG; Mon, 22 Aug 2005 16:01:28 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010D4B40@cherry.ease.lsoft.com>; Mon, 22 Aug 2005 15:23:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83498606 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Aug 2005 15:23:32 -0400 Received: from 195.212.29.137 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 22 Aug 2005 15:23:32 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j7MJNVKT296956 for ; Mon, 22 Aug 2005 19:23:31 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7MJNVXZ287900 for ; Mon, 22 Aug 2005 20:23:31 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id j7MIYBSs000645 for ; Mon, 22 Aug 2005 19:34:11 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j7MIYBxU000642; Mon, 22 Aug 2005 19:34:11 +0100 Received: from [127.0.0.1] (sig-9-145-135-83.de.ibm.com [9.145.135.83]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id VAA44434; Mon, 22 Aug 2005 21:23:29 +0200 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.uk.ibm.com id j7MJNVKT296956 Approved-By: Robert Haas Message-ID: <430A25FA.9090102@zurich.ibm.com> Date: Mon, 22 Aug 2005 21:22:34 +0200 Reply-To: Robert Haas Sender: Forwarding and Control Element Separation From: Robert Haas Subject: Re: [Issue 57] Inconsistent operation types Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <004601c5a742$fd5c9370$1f12fea9@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Weiming, The idea of the get-response and set operations in the Association Setup=20 and Response messages, respectively, was mainly to allow unsolicited=20 information to be advertised by the FE. I agree with you that the set=20 operation is not very fortunate as it means that a set-reponse might be=20 needed, this time in a CONFIG message type. Therefore I propose that we only allow the get-response (or can be=20 called anything else, such as SHOW) in the Association Setup messages,=20 and nothing in the Response. Regards, -Robert Weiming Wang wrote: >Hi, > >the update related to the issue is as below: > > =20 > >>Consensus from Paris wg meeting on the messages and operations required= : >>(need to be put in the draft) >> =20 >> > > =20 > >>CONFIGURATION message: >>Set (also used for event subscription), Delete >>CONFIGURATION-RESPONSE message: >>Same as above with *-response >> =20 >> >[Weming] has been updated and has made comparatively large scale text mo= difying to this section for text consistency with other sections, see [ed= itorial 4] post. > >QUERY message: > Get >QUERY-RESPONSE message: > Get-response >[Weiming]Has been updated and made minute modification to whole section > >EVENT-NOTIFICATION message: > Report >[Weiming]Updated. Is going to completely remove the section of event not= ification response? > >ASSOCIATION-SETUP message: > Get-response (optional, used to advertise fields from the FE LFB=20 >and/or FE Protocol LFB in an unsolicited manner) > >[Weiming]haven't made changes. Questions: >Do we really need an operation in the association setup message? It will= make flooding attack more easy, I think. Why don't we let CE later to qu= ery then? > >ASSOCIATION-SETUP-RESPONSE message: > Set (optional, only to set fields in the FE LFB and/or FE Protocol LFB) >[Weiming]Haven't made changes. Questions: >Does this really mean we allow a SET operation that never be able to get= SET response? Why don't we use config message to SET then? > >PACKET REDIR, HEARTBEAT do not have operations. >[Weiming]has made minute text modification to these sections. > >Thanks, >Weiming > > > =20 > --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=C3=A4umerstrasse 4 CH-8803 R=C3=BCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a From owner-forces@PEACH.EASE.LSOFT.COM Mon Aug 22 23:04:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7P5F-0000Tu-7a for forces-archive@megatron.ietf.org; Mon, 22 Aug 2005 23:04:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25694 for ; Mon, 22 Aug 2005 23:04:14 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7P5D-0004eC-TM for forces-archive@IETF.ORG; Mon, 22 Aug 2005 23:04:19 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010D51E3@cherry.ease.lsoft.com>; Mon, 22 Aug 2005 23:04:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83541655 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Aug 2005 23:01:05 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 22 Aug 2005 23:01:04 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Tue, 23 Aug 2005 11:30:38 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <430A25FA.9090102@zurich.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <001701c5a78e$f5041fd0$1f12fea9@wwm1> Date: Tue, 23 Aug 2005 11:01:25 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [Issue 57] Inconsistent operation types To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlJvYmVydCBI YWFzIiA8cmhhQHp1cmljaC5pYm0uY29tPg0KDQpXZWltaW5nLA0KVGhlIGlkZWEgb2YgdGhlIGdl dC1yZXNwb25zZSBhbmQgc2V0IG9wZXJhdGlvbnMgaW4gdGhlIEFzc29jaWF0aW9uIFNldHVwIA0K YW5kIFJlc3BvbnNlIG1lc3NhZ2VzLCByZXNwZWN0aXZlbHksIHdhcyBtYWlubHkgdG8gYWxsb3cg dW5zb2xpY2l0ZWQgDQppbmZvcm1hdGlvbiB0byBiZSBhZHZlcnRpc2VkIGJ5IHRoZSBGRS4gSSBh Z3JlZSB3aXRoIHlvdSB0aGF0IHRoZSBzZXQgDQpvcGVyYXRpb24gaXMgbm90IHZlcnkgZm9ydHVu YXRlIGFzIGl0IG1lYW5zIHRoYXQgYSBzZXQtcmVwb25zZSBtaWdodCBiZSANCm5lZWRlZCwgdGhp cyB0aW1lIGluIGEgQ09ORklHIG1lc3NhZ2UgdHlwZS4NClRoZXJlZm9yZSBJIHByb3Bvc2UgdGhh dCB3ZSBvbmx5IGFsbG93IHRoZSBnZXQtcmVzcG9uc2UgKG9yIGNhbiBiZSANCmNhbGxlZCBhbnl0 aGluZyBlbHNlLCBzdWNoIGFzIFNIT1cpIGluIHRoZSBBc3NvY2lhdGlvbiBTZXR1cCBtZXNzYWdl cywgDQphbmQgbm90aGluZyBpbiB0aGUgUmVzcG9uc2UuDQpbV2VpbWluZ10gSSBkaWQgbm90IGZv bGxvdyB0aGUgZGlzY3Vzc2lvbiB3ZWxsIGJlZm9yZS4gTWF5YmUgdGhlcmUgYXJlIG90aGVyIHJl YXNvbnMsIGJ1dCBJIHRoaW5rIHdoeSAgd2UgZG8gbm90IHNldCB0aGUgYXNzb2NpYXRpb24gc2V0 dXAgb3BlcmF0aW9uIGp1c3QgYXMgUkVQT1JUPw0KDQpUaGFua3MsDQpXZWltaW5nDQoNCg0KUmVn YXJkcywNCi1Sb2JlcnQNCg0KV2VpbWluZyBXYW5nIHdyb3RlOg0KDQo+SGksDQo+DQo+dGhlIHVw ZGF0ZSByZWxhdGVkIHRvIHRoZSBpc3N1ZSBpcyBhcyBiZWxvdzoNCj4NCj4gIA0KPg0KPj5Db25z ZW5zdXMgZnJvbSBQYXJpcyB3ZyBtZWV0aW5nIG9uIHRoZSBtZXNzYWdlcyBhbmQgb3BlcmF0aW9u cyByZXF1aXJlZDoNCj4+KG5lZWQgdG8gYmUgcHV0IGluIHRoZSBkcmFmdCkNCj4+ICAgIA0KPj4N Cj4NCj4gIA0KPg0KPj5DT05GSUdVUkFUSU9OIG1lc3NhZ2U6DQo+PlNldCAoYWxzbyB1c2VkIGZv ciBldmVudCBzdWJzY3JpcHRpb24pLCBEZWxldGUNCj4+Q09ORklHVVJBVElPTi1SRVNQT05TRSBt ZXNzYWdlOg0KPj5TYW1lIGFzIGFib3ZlIHdpdGggKi1yZXNwb25zZQ0KPj4gICAgDQo+Pg0KPltX ZW1pbmddIGhhcyBiZWVuIHVwZGF0ZWQgYW5kIGhhcyBtYWRlIGNvbXBhcmF0aXZlbHkgbGFyZ2Ug c2NhbGUgdGV4dCBtb2RpZnlpbmcgdG8gdGhpcyBzZWN0aW9uIGZvciB0ZXh0IGNvbnNpc3RlbmN5 IHdpdGggb3RoZXIgc2VjdGlvbnMsIHNlZSBbZWRpdG9yaWFsIDRdIHBvc3QuDQo+DQo+UVVFUlkg bWVzc2FnZToNCj4gR2V0DQo+UVVFUlktUkVTUE9OU0UgbWVzc2FnZToNCj4gR2V0LXJlc3BvbnNl DQo+W1dlaW1pbmddSGFzIGJlZW4gdXBkYXRlZCBhbmQgbWFkZSBtaW51dGUgbW9kaWZpY2F0aW9u IHRvIHdob2xlIHNlY3Rpb24NCj4NCj5FVkVOVC1OT1RJRklDQVRJT04gbWVzc2FnZToNCj4gUmVw b3J0DQo+W1dlaW1pbmddVXBkYXRlZC4gSXMgZ29pbmcgdG8gY29tcGxldGVseSByZW1vdmUgdGhl IHNlY3Rpb24gb2YgZXZlbnQgbm90aWZpY2F0aW9uIHJlc3BvbnNlPw0KPg0KPkFTU09DSUFUSU9O LVNFVFVQIG1lc3NhZ2U6DQo+IEdldC1yZXNwb25zZSAob3B0aW9uYWwsIHVzZWQgdG8gYWR2ZXJ0 aXNlIGZpZWxkcyBmcm9tIHRoZSBGRSBMRkIgDQo+YW5kL29yIEZFIFByb3RvY29sIExGQiBpbiBh biB1bnNvbGljaXRlZCBtYW5uZXIpDQo+DQo+W1dlaW1pbmddaGF2ZW4ndCBtYWRlIGNoYW5nZXMu IFF1ZXN0aW9uczoNCj5EbyB3ZSByZWFsbHkgbmVlZCBhbiBvcGVyYXRpb24gaW4gdGhlIGFzc29j aWF0aW9uIHNldHVwIG1lc3NhZ2U/IEl0IHdpbGwgbWFrZSBmbG9vZGluZyBhdHRhY2sgbW9yZSBl YXN5LCBJIHRoaW5rLiBXaHkgZG9uJ3Qgd2UgbGV0IENFIGxhdGVyIHRvIHF1ZXJ5IHRoZW4/DQo+ DQo+QVNTT0NJQVRJT04tU0VUVVAtUkVTUE9OU0UgbWVzc2FnZToNCj4gU2V0IChvcHRpb25hbCwg b25seSB0byBzZXQgZmllbGRzIGluIHRoZSBGRSBMRkIgYW5kL29yIEZFIFByb3RvY29sIExGQikN Cj5bV2VpbWluZ11IYXZlbid0IG1hZGUgY2hhbmdlcy4gUXVlc3Rpb25zOg0KPkRvZXMgdGhpcyBy ZWFsbHkgbWVhbiB3ZSBhbGxvdyBhIFNFVCBvcGVyYXRpb24gdGhhdCBuZXZlciBiZSBhYmxlIHRv IGdldCBTRVQgcmVzcG9uc2U/IFdoeSBkb24ndCB3ZSB1c2UgY29uZmlnIG1lc3NhZ2UgdG8gU0VU IHRoZW4/DQo+DQo+UEFDS0VUIFJFRElSLCBIRUFSVEJFQVQgZG8gbm90IGhhdmUgb3BlcmF0aW9u cy4NCj5bV2VpbWluZ11oYXMgbWFkZSBtaW51dGUgdGV4dCBtb2RpZmljYXRpb24gdG8gdGhlc2Ug c2VjdGlvbnMuDQo+DQo+VGhhbmtzLA0KPldlaW1pbmcNCj4NCj4NCj4gIA0KPg0KDQotLSANCkRy LiBSb2JlcnQgUi4gSGFhcw0KSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5DQpTw6R1bWVy c3RyYXNzZSA0DQpDSC04ODAzIFLDvHNjaGxpa29uL1N3aXR6ZXJsYW5kDQpwaG9uZSArNDEtNDQt NzI0LTg2OTggIGZheCArNDEtNDQtNzI0LTg1NzggIGh0dHA6Ly93d3cuenVyaWNoLmlibS5jb20v fnJoYQ== From owner-forces@PEACH.EASE.LSOFT.COM Mon Aug 22 23:38:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Pck-0007WU-Vr for forces-archive@megatron.ietf.org; Mon, 22 Aug 2005 23:38:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27271 for ; Mon, 22 Aug 2005 23:38:52 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Pcn-0005Vx-HB for forces-archive@IETF.ORG; Mon, 22 Aug 2005 23:38:57 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010D52EB@cherry.ease.lsoft.com>; Mon, 22 Aug 2005 23:38:53 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83544193 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 22 Aug 2005 23:38:53 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Mon, 22 Aug 2005 23:38:52 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Tue, 23 Aug 2005 12:08:47 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <002601c5a794$499bc1b0$1f12fea9@wwm1> Date: Tue, 23 Aug 2005 11:38:46 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [Issue 57] Inconsistent operation types To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIldlaW1pbmcgV2FuZyIgPHdt d2FuZ0BtYWlsLnpqZ3N1LmVkdS5jbj4NCiANCj4gDQo+IEVWRU5ULU5PVElGSUNBVElPTiBtZXNz YWdlOg0KPiAgUmVwb3J0DQo+IFtXZWltaW5nXVVwZGF0ZWQuIElzIGdvaW5nIHRvIGNvbXBsZXRl bHkgcmVtb3ZlIHRoZSBzZWN0aW9uIG9mIGV2ZW50IG5vdGlmaWNhdGlvbiByZXNwb25zZT8NCj4g DQpUaGVyZSBpcyBhIG1vcmUgcXVlc3Rpb24gYWJvdXQgZXZlbnQgbm90aWZpY2F0aW9uIG1lc3Nh Z2UuIEhhdmUgd2UgcmVhY2hlZCBhbnkgY29uc2Vuc3VzIHRoYXQgd2UgZG9uJ3QgbmVlZCBhbnkg ZXZlbnQgbm90aWZpY2F0aW9uIHNlbnQgYnkgQ0U/IElmIHdlIGFsbG93IENFIGV2ZW50cywgdGhl cmUgd2lsbCBiZSBwcm9ibGVtIHdpdGggdGhlIG1lc3NhZ2UgcmVwcmVzZW50YXRpb24sIGJlY2F1 c2Ugd2UgZG8gbm90IGhhdmUgYW55IFBBVEgtREFUQSBkZWZpbmVkIGZvciBDRSBhZnRlciB3ZSBo YXZlIGRlY2lkZWQgdGhhdCB3ZSBhYmFuZG9uZWQgQ0UgTEZCLg0KDQpDb21tZW50cyBwbGVhc2Uh DQoNClRoYW5rcyBhIGxvdC4NCldlaW1pbmcNCg== From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 23 01:20:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7RCc-00013m-8m for forces-archive@megatron.ietf.org; Tue, 23 Aug 2005 01:20:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00425 for ; Tue, 23 Aug 2005 01:20:01 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7RCf-0007qg-Ih for forces-archive@IETF.ORG; Tue, 23 Aug 2005 01:20:05 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.010D54B1@cherry.ease.lsoft.com>; Tue, 23 Aug 2005 1:20:00 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83550234 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Aug 2005 01:19:55 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 23 Aug 2005 01:19:48 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Tue, 23 Aug 2005 13:49:45 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <003a01c5a7a2$63e3c820$1f12fea9@wwm1> Date: Tue, 23 Aug 2005 13:20:35 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [Issue 57] Inconsistent operation types To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 1.1 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: base64 SGksDQoNCkhlcmUgaXMgdGhlIHN1cHBvc2VkIHVwZGF0ZSBmb3IgZXZlbnQgbm90aWZpY2F0aW9u IG1lc3NhZ2UuDQoNClRoYW5rcywNCldlaW1pbmcNCg0KNi43ICBFdmVudCBOb3RpZmljYXRpb24g TWVzc2FnZQ0KDQogICBFdmVudCBOaXRpZmljYXRpb24gTWVzc2FnZSBpcyB1c2VkIGJ5IEZFIHRv IGFzeW5jaHJvbm91c2x5IG5vdGlmeSBDRQ0KICAgb2YgZXZlbnRzIGhhcHBlbmQgaW4gdGhlIEZF Lg0KDQogICBBbGwgZXZlbnRzIGhhcHBlbmVkIGluIEZFIGFyZSBzdWJzY3JpYmFibGUgYnkgQ0Uu ICBBIGNvbmZpZyBtZXNzYWdlDQogICBpcyB1c2VkIGJ5IENFIHRvIHN1YnNjcmliZS91bnN1YnNj cmliZSBmb3IgYW4gZXZlbnQgaW4gRkUuDQoNCiAgIEFzIHVzdWFsLCBhbiBFdmVudCBOb3RpZmlj YXRpb24gTWVzc2FnZSBpcyBjb21wb3NlZCBvZiBhIGNvbW1vbg0KICAgaGVhZGVyIGFuZCBhIG1l c3NhZ2UgYm9keSB0aGF0IGNvbnNpc3RzIG9mIG9uZSBvciBtb3JlIFRMViBkYXRhDQogICBmb3Jt YXQuICBEZXRhaWxlZCBkZXNjcmlwdGlvbiBvZiB0aGUgbWVzc2FnZSBpcyBhcyBiZWxvdy4NCg0K ICAgTWVzc2FnZSBUcmFuc2ZlciBEaXJlY3Rpb246DQogICAgICBGRSB0byBDRQ0KDQogICBNZXNz YWdlIEhlYWRlcjoNCiAgICAgIFRoZSBNZXNzYWdlIFR5cGUgaW4gdGhlIG1lc3NhZ2UgaGVhZGVy IGlzIHNldCB0bw0KICAgICAgTWVzc2FnZVR5cGUgPSAnRXZlbnROb3RpZmljYXRpb24nLiAgQmVj YXVzZSB3ZSBkbyBub3QgZXhwZWN0IGFueQ0KICAgICAgcmVzcG9uc2UgZm9yIGV2ZW50IG5vdGlm aWNhdGlvbiwgdGhlIEFDSyBmbGFnIGluIHRoZSBtZXNzYWdlDQogICAgICBoZWFkZXIgU0hPVUxE IGJlIHJlYXNvbmFibHkgc2V0IHRvICdOb0FDSycuICBJZiB0aGUgQUNLIGZsYWcgaXMNCiAgICAg IHNldCB0byBhbnkgb3RoZXIgdmFsdWVzLCB0aGUgbWVhbmluZyBvZiB0aGUgZmxhZyB3aWxsIHRo ZW4gYmUNCiAgICAgIGlnbm9yZWQuDQoNCiAgIE1lc3NhZ2UgQm9keToNCiAgICAgIFRoZSBtZXNz YWdlIGJvZHkgZm9yIGFuIGV2ZW50IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGNvbnNpc3RzIG9mIChh dA0KICAgICAgbGVhc3QpIG9uZSBvciBtb3JlIHRoYW4gb25lIFRMVnMgdGhhdCBkZXNjcmliZSB0 aGUgbm90aWZpZWQNCiAgICAgIGV2ZW50cy4gIFRoZSBUTFYgaXMgYWxzbyBhIExGQnNlbGVjdCBU TFYgKHdpdGggdGhlIFRMVg0KICAgICAgVHlwZT0iTEZCc2VsZWN0IiksIGFuZCBhIGdlbmVyaWMg Zm9ybWF0IGRlZmluaXRpb24gb2Ygd2hpY2ggaGFzDQogICAgICBiZWVuIGdpdmVuIGluIFNlY3Rp b24gNi4xLjEuICBEZXRhaWxlZCBkYXRhIGZvcm1hdCBvZiBhIExGQnNlbGVjdA0KICAgICAgVExW IGZvciBldmVudCBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBhcyBiZWxvdzoNCg0KDQogICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMQ0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICAgfCAgICAgICAgVHlwZSA9IExGQnNlbGVjdCAgICAgICB8 ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgIExGQiBDbGFzcyBJRCAgICAgICAgICAgICAgICAgICAgICAg ICB8DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgTEZCIEluc3Rh bmNlIElEICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgfCAgICAg ICAgICAgICAgICAgICAgICAgIE9wZXJhdGlvbiBUTFYgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLg0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgfiAgICAgICAgICAgICAgICAgICAg ICAgICAgIC4uLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4NCiAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBPcGVyYXRpb24gVExWICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMjQNCg0KICAgT3BlcmF0aW9uIFRMVjoN CiAgICAgIFRoaXMgaXMgYW4gb3BlcmF0aW9uIFRMViB0aGF0IGRlc2NyaWJlcyB0aGUgZXZlbnQg dG8gYmUgbm90aWZpZWQsDQogICAgICBhcyBmb2xsb3dzOg0KIA0KICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwg ICAgVHlwZSA9IFJFUE9SVCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIExlbmd0aCAgICAg ICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAgICAgUEFUSC1EQVRBLVRM ViBmb3IgUkVQT1JUICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMjUNCg0KICAgVHlwZToNCiAgICAgIE9u bHkgb25lIG9wZXJhdGlvbiB0eXBlIGlzIGRlZmluZWQgZm9yIHRoZSBldmVudCBub3RpZmljYXRp b24NCiAgICAgIG1lc3NhZ2U6DQoNCiAgICAgICAgICAgICBUeXBlID0gIlJFUE9SVCIgLS0tIHRo aXMgdHlwZSBvZiBvcGVyYXRpb24gaXMgZm9yIEZFIHRvDQogICAgICAgICAgICAgcmVwb3J0IHNv bWV0aGluZyB0byBDRS4NCg0KICAgUEFUSC1EQVRBLVRMViBmb3IgUkVQT1JUOg0KICAgICAgVGhp cyBpcyBnZW5lcmljYWxseSBhIFBBVEgtREFUQS1UTFYgZm9ybWF0IHRoYXQgaGFzIGJlZW4gZGVm aW5lZA0KICAgICAgaW4gIlByb3RvY29sIEdyYW1tYXIiIHNlY3Rpb24oU2VjdGlvbiA2LjEpIGlu IHRoZSBQQVRILURBVEEgQk5GDQogICAgICBkZWZpbml0aW9uLiAgVGhlIHJlc3RyaWN0aW9uIG9u IHRoZSB1c2Ugb2YgUEFUSC1EQVRBLVRMViBmb3INCiAgICAgIFJFUE9SVCBvcGVyYXRpb24gaXMg aXQgTUFZIGNvbnRhaW4gREFUQVJBVy1UTFYocykgYnV0IFNIQUxMIE5PVA0KICAgICAgY29udGFp biBhbnkgUkVTVUxULVRMViBpbiB0aGUgZGF0YSBmb3JtYXQuDQoNCiAgIFRvIGJldHRlciB1bmRl cnN0YW5kIHRoZSBhYm92ZSBQRFUgZm9ybWF0LCB3ZSBzaG93IGEgdHJlZSBzdHJ1Y3R1cmUNCiAg IGZvciB0aGUgZm9ybWF0IGFzIGJlbG93Og0KDQogICBtYWluIGhkciAodHlwZSA9IEV2ZW50IE5v dGlmaWNhdGlvbikNCiAgICAgICAgfA0KICAgICAgICB8DQogICAgICAgICstLS0gVCA9IExGQnNl bGVjdA0KICAgICAgICB8ICAgICAgICB8DQogICAgICAgIHwgICAgICAgICstLSBMRkJDTEFTU0lE ID0gdGFyZ2V0IExGQiBjbGFzcw0KICAgICAgICB8ICAgICAgICB8DQogICAgICAgIHwgICAgICAg IHwNCiAgICAgICAgfCAgICAgICAgKy0tIExGQkluc3RhbmNlID0gdGFyZ2V0IExGQiBpbnN0YW5j ZQ0KICAgICAgICB8ICAgICAgICB8DQogICAgICAgIHwgICAgICAgIHwNCiAgICAgICAgfCAgICAg ICAgKy0tIFQgPSBvcGVyYXRpb24geyBSRVBPUlQgfQ0KICAgICAgICB8ICAgICAgICB8ICAgfA0K ICAgICAgICB8ICAgICAgICB8ICAgKy0tICAvLyBvbmUgb3IgbW9yZSBwYXRoIHRhcmdldHMNCiAg ICAgICAgfCAgICAgICAgfCAgICAgICAgLy8gYXNzb2NpYXRlZCB3aXRoIERBVEFSQVctVExWKHMp DQogICAgICAgIHwgICAgICAgICstLSBUID0gb3BlcmF0aW9uIHsgUkVQT1JUIH0NCiAgICAgICAg fCAgICAgICAgfCAgIHwNCiAgICAgICAgfCAgICAgICAgfCAgICstLSAgLy8gb25lIG9yIG1vcmUg cGF0aCB0YXJnZXRzDQogICAgICAgIHwgICAgICAgIHwgICAgICAgIC8vIGFzc29jaWF0ZWQgd2l0 aCBEQVRBUkFXLVRMVihzKQ0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZp Z3VyZSAyNg0KDQoNCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4gRnJvbTogIldl aW1pbmcgV2FuZyIgPHdtd2FuZ0BtYWlsLnpqZ3N1LmVkdS5jbj4NCj4gIA0KPiA+IA0KPiA+IEVW RU5ULU5PVElGSUNBVElPTiBtZXNzYWdlOg0KPiA+ICBSZXBvcnQNCj4gPiBbV2VpbWluZ11VcGRh dGVkLiBJcyBnb2luZyB0byBjb21wbGV0ZWx5IHJlbW92ZSB0aGUgc2VjdGlvbiBvZiBldmVudCBu b3RpZmljYXRpb24gcmVzcG9uc2U/DQo+ID4gDQo+IFRoZXJlIGlzIGEgbW9yZSBxdWVzdGlvbiBh Ym91dCBldmVudCBub3RpZmljYXRpb24gbWVzc2FnZS4gSGF2ZSB3ZSByZWFjaGVkIGFueSBjb25z ZW5zdXMgdGhhdCB3ZSBkb24ndCBuZWVkIGFueSBldmVudCBub3RpZmljYXRpb24gc2VudCBieSBD RT8gSWYgd2UgYWxsb3cgQ0UgZXZlbnRzLCB0aGVyZSB3aWxsIGJlIHByb2JsZW0gd2l0aCB0aGUg bWVzc2FnZSByZXByZXNlbnRhdGlvbiwgYmVjYXVzZSB3ZSBkbyBub3QgaGF2ZSBhbnkgUEFUSC1E QVRBIGRlZmluZWQgZm9yIENFIGFmdGVyIHdlIGhhdmUgZGVjaWRlZCB0aGF0IHdlIGFiYW5kb25l ZCBDRSBMRkIuDQo+IA0KPiBDb21tZW50cyBwbGVhc2UhDQo+IA0KPiBUaGFua3MgYSBsb3QuDQo+ IFdlaW1pbmcNCj4g From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 23 10:53:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7a9C-0007AK-Af for forces-archive@megatron.ietf.org; Tue, 23 Aug 2005 10:53:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08637 for ; Tue, 23 Aug 2005 10:53:04 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7a9C-0006u0-7y for forces-archive@IETF.ORG; Tue, 23 Aug 2005 10:53:14 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.010D57FC@cherry.ease.lsoft.com>; Tue, 23 Aug 2005 10:52:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83613123 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Aug 2005 10:52:52 -0400 Received: from 207.69.195.66 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 23 Aug 2005 10:52:52 -0400 Received: from user-2ivf97b.dsl.mindspring.com ([165.247.164.235] helo=JMHLap3.stevecrocker.com) by pop-canoe.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1E7a8x-0003vu-00 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Aug 2005 10:52:51 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> <003a01c5a7a2$63e3c820$1f12fea9@wwm1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050823105005.02d046b8@localhost> Date: Tue, 23 Aug 2005 10:52:42 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [Issue 57] Inconsistent operation types To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003a01c5a7a2$63e3c820$1f12fea9@wwm1> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 The text below is an excerpt from a proposed methodology for a particular PL message. It is about event notification messages, and the fact that no responses are expected to them. (They are transmitted reliably, and the FE which sends them has no use for an ACK. However, if we are going to take this approach, we render the ack flags much more complex. We should either define the ack flags globally and use them everywhere, or we should not have them in the common message header. If we choose to keep them, then a message receiver should be prepared to generate an ACK for ANY message it receives, if the flags tell it to do so. Yours, Joel M. Halpern At 01:20 AM 8/23/2005, Weiming Wang wrote: > header SHOULD be reasonably set to 'NoACK'. If the ACK flag is > set to any other values, the meaning of the flag will then be > ignored. From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 23 12:05:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bHJ-0005Dx-Ne for forces-archive@megatron.ietf.org; Tue, 23 Aug 2005 12:05:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12241 for ; Tue, 23 Aug 2005 12:05:31 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bHO-0000fV-A9 for forces-archive@IETF.ORG; Tue, 23 Aug 2005 12:05:42 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010D5936@cherry.ease.lsoft.com>; Tue, 23 Aug 2005 12:05:27 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83619605 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Aug 2005 12:05:26 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 23 Aug 2005 12:05:25 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7NFPDXK070946; Tue, 23 Aug 2005 08:25:15 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00e001c5a47b$fbae8b60$9273c0dc@WwmLapSamsung> <4309FAFB.9080702@zurich.ibm.com> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1124807359.6579.14.camel@localhost.localdomain> Date: Tue, 23 Aug 2005 10:29:19 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [Issue 47] PL sequence number and correlator Comments: To: Robert Haas To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <4309FAFB.9080702@zurich.ibm.com> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit I think it is an issue of semantics. If we say we have a 64 bit field to play with and call it correlator it doesnt matter how that field is used by the CE. The important detail in my opinion is that the 64 bit is opaque to the FE and is returned as is to the CE. So my suggestion is to call it a corellator and have perhaps(?) some text around it to say how its usage by the CE could be implemented. In the case of reliability of messages, I think thats the responsibility is one that is owned by the TML (and the TML API describes how to indicate a message from the PL that needs reliability). cheers, jamal On Mon, 2005-22-08 at 18:19 +0200, Robert Haas wrote: > Weiming, > Well, this was the consensus among the participants at the meeting, at > least. But let's discuss this again: > > First, note that the protocol as we designed it until now _relies_ on a > reliable TML. > For instance, if the response to a operation was lost over an unreliable > TML, the CE would reissue the operation. The FE would have no way to > realize that this second operation is actually a repetition (remember > that the correlator field is completely opaque to the FE). Depending on > the kind of operation, this could be fatal to the FE. > > Now, if you want to use an unreliable TML only for certain message types > (such as event notifications or redirected packets, nothing fatal can > happen if messages are lost), then we need to decide whether we want to > guarantee ordering at the PL level at all. This is debatable. > > Regards, > -Robert > > Wang,Weiming wrote: > > >>Issue 47: PL sequence number and correlator. Convert the sequence > >> > >> > >number > > > > > >>and the correlator into a 64-bit correlator. Correlator used in Config > >>and Query messages. Must be set to 0 for Notifications. > >> > >> > > > >Updated in tracker. Need to make changes in the draft. > > > >Robert, > > > >I don't think to remove the Sequence Number is the consensus we reached. > >I have for several times noted that SN will be used in several cases. > >Note that SN will be the only key to order back messages for messages > >transported over unreliable TMLs. I can currently think of that the > >redirect message will definitely need the SN to order back redirect > >data. I also think of the future, when SN may be used by CE and FE to > >syncronize the messages. It's a little too early to deliminate the > >necessity, I'm afraid. > > > >How others think? > > > >Thanks, > >Weiming > > > > > > > > > From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 23 12:05:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bHL-0005EI-UV for forces-archive@megatron.ietf.org; Tue, 23 Aug 2005 12:05:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12244 for ; Tue, 23 Aug 2005 12:05:33 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bHU-0000fi-0n for forces-archive@IETF.ORG; Tue, 23 Aug 2005 12:05:45 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010D59A8@cherry.ease.lsoft.com>; Tue, 23 Aug 2005 12:05:34 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83619624 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Aug 2005 12:05:33 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 23 Aug 2005 12:05:33 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7NFOrXK070930; Tue, 23 Aug 2005 08:24:59 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <000f01c5a338$434a3540$1d72c0dc@WwmLapSamsung> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1124807344.6579.11.camel@localhost.localdomain> Date: Tue, 23 Aug 2005 10:29:03 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 32] Packet Redirect Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <000f01c5a338$434a3540$1d72c0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Weiming, Comment below ... On Wed, 2005-17-08 at 22:30 +0800, Wang,Weiming wrote: > ----- Original Message ----- [..] > > Meta Data ILV: > This is an Identifier-Length-Value format that is used to describe > one meta data. The ILV has the format as: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Meta Data ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Meta Data Value | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Where, Meta Data ID is an identifier for the meta data, which is > defined by FE-Model[FE-MODEL]. This actually implies > a Meta Data ID is statically assigned by FE-Model. This is not realistic. I think that way after the FE-Model becomes RFCs metadata will continue to be defined. > This also implies a Meta Data ID transcoding mechanism may be necessary > if a metadata traverses several LFBs > while these LFBs define the metadata with different Meta Data IDs. > > > > Comments please. > > thanks, > Weiming From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 23 12:05:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bHR-0005EZ-MP for forces-archive@megatron.ietf.org; Tue, 23 Aug 2005 12:05:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12247 for ; Tue, 23 Aug 2005 12:05:39 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bHZ-0000fm-OR for forces-archive@IETF.ORG; Tue, 23 Aug 2005 12:05:51 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010D581A@cherry.ease.lsoft.com>; Tue, 23 Aug 2005 12:05:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83619637 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Aug 2005 12:05:39 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 23 Aug 2005 12:05:38 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7NFPJXK070950; Tue, 23 Aug 2005 08:25:20 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1124807362.6579.15.camel@localhost.localdomain> Date: Tue, 23 Aug 2005 10:29:22 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [Issue 57] Inconsistent operation types Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <004601c5a742$fd5c9370$1f12fea9@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit On Tue, 2005-23-08 at 01:57 +0800, Weiming Wang wrote: > EVENT-NOTIFICATION message: > Report > [Weiming]Updated. Is going to completely remove the section of event notification > response? > Lets review after you complete your update. > ASSOCIATION-SETUP message: > Get-response (optional, used to advertise fields from the FE LFB > and/or FE Protocol LFB in an unsolicited manner) > > [Weiming]haven't made changes. Questions: > Do we really need an operation in the association setup message? It will make > flooding attack more easy, I think. Why don't we let CE later to query then? > I think making it optional is fine. Optionally it can be used to cut down on the number of messages issued. > ASSOCIATION-SETUP-RESPONSE message: > Set (optional, only to set fields in the FE LFB and/or FE Protocol LFB) > [Weiming]Haven't made changes. Questions: > Does this really mean we allow a SET operation that never be able to get SET > response? Why don't we use config message to SET then? I think the challenge in the naming convention as we discussed in the meeting is that Config goes from CE->FE and response goes back. However you do bring up a good point: the CE would need to know if the SET was successful or not. A GET following the SET should be sufficient. Which actually invalidates the need to SET in the ASSOCIATION-SETUP message since eventually the number of messages is going to be equivalent. Thoughts? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 23 12:05:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bHS-0005El-2E for forces-archive@megatron.ietf.org; Tue, 23 Aug 2005 12:05:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12250 for ; Tue, 23 Aug 2005 12:05:39 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bHb-0000fm-4Z for forces-archive@IETF.ORG; Tue, 23 Aug 2005 12:05:51 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010D59D1@cherry.ease.lsoft.com>; Tue, 23 Aug 2005 12:05:39 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83619619 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Aug 2005 12:05:33 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 23 Aug 2005 12:05:32 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7NFP8XK070940; Tue, 23 Aug 2005 08:25:09 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1124807356.6579.13.camel@localhost.localdomain> Date: Tue, 23 Aug 2005 10:29:16 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 34] Header flags Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit On Fri, 2005-19-08 at 11:37 +0800, Wang,Weiming wrote: > Joel, > > ----- Original Message ----- > From: "Joel M. Halpern" > > > I think that this needs some tuning. > > A single "message" with a single set of flags can contain multiple > operations. > > We have in other places in the document stated that there are three > > different modes of operation: > First of all, we should note that ACK flag does not interfere into any > operations. Then, we noted that ACK flag also does not affect the > response format of operations. The only effect of ACK flag is to choose > a response at the time. I see the question you raised as that we may > need some definitions and specifications in the operations regarding ACK > flag meaning, whereas the ACK flag still keep its clearness in meaning. > Could we specify that the ACK flags override the All-or-none, Operate-until-error etc? > > >p.s., Jamal, Could you provide some text on the Batch flag and the > > >Atomicity flag? Why dont i wait until you are done since i think youve done a lot of cleanup and this may be related to the execution text. i.e i want to correlate with the rest of the text. Maybe we can open an issue in the tracker so it is not forgotten. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 23 12:05:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bHj-0005Fk-2D for forces-archive@megatron.ietf.org; Tue, 23 Aug 2005 12:05:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12262 for ; Tue, 23 Aug 2005 12:05:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bHr-0000g2-61 for forces-archive@IETF.ORG; Tue, 23 Aug 2005 12:06:08 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010D58BE@cherry.ease.lsoft.com>; Tue, 23 Aug 2005 12:05:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83619697 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Aug 2005 12:05:56 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 23 Aug 2005 12:05:55 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7NFPUXK070964; Tue, 23 Aug 2005 08:25:31 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1124807371.6579.18.camel@localhost.localdomain> Date: Tue, 23 Aug 2005 10:29:31 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [Issue 57] Inconsistent operation types Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <002601c5a794$499bc1b0$1f12fea9@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Tue, 2005-23-08 at 11:38 +0800, Weiming Wang wrote: > ----- Original Message ----- > From: "Weiming Wang" > > > > > EVENT-NOTIFICATION message: > > Report > > [Weiming]Updated. Is going to completely remove the section of event notification response? > > > There is a more question about event notification message. Have we reached any consensus > that we don't need any event notification sent by CE? If we allow CE events, there will > be problem with the message representation, because we do not have any PATH-DATA defined > for CE after we have decided that we abandoned CE LFB. > I think we decided IIRC that messages from CE to FE will be of type CONFIG? Events from the CE to FE could be masquareded as CONFIG, no? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 23 12:06:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bHu-0005GW-S3 for forces-archive@megatron.ietf.org; Tue, 23 Aug 2005 12:06:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12271 for ; Tue, 23 Aug 2005 12:06:08 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bI3-0000gO-TD for forces-archive@IETF.ORG; Tue, 23 Aug 2005 12:06:20 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.010D5911@cherry.ease.lsoft.com>; Tue, 23 Aug 2005 12:06:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83619717 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Aug 2005 12:06:02 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 23 Aug 2005 12:06:01 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7NFPXXK070967; Tue, 23 Aug 2005 08:25:34 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> <003a01c5a7a2$63e3c820$1f12fea9@wwm1> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1124807374.6579.19.camel@localhost.localdomain> Date: Tue, 23 Aug 2005 10:29:34 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [Issue 57] Inconsistent operation types Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003a01c5a7a2$63e3c820$1f12fea9@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit On Tue, 2005-23-08 at 13:20 +0800, Weiming Wang wrote: > Hi, > > Here is the supposed update for event notification message. > > Thanks, > Weiming > > 6.7 Event Notification Message > > Event Nitification Message is used by FE to asynchronously notify CE ^^^^^^^^^^^ typo > of events happend in the FE. ^^^^^^^ probably rewrite as "of events that happen in the FE" > All events happened in FE are subscribable by CE. A config message ^^^^^^^ "happen" > is used by CE to subscribe/unsubscribe for an event in FE. Perhaps mention that to subscribe to an event is usually by specifying to the path of such an event as described by FE-Model and defined by specific LFB. > Message Header: > The Message Type in the message header is set to > MessageType = 'EventNotification'. Because we do not expect any > response for event notification, the ACK flag in the message > header SHOULD be reasonably set to 'NoACK'. If the ACK flag is > set to any other values, the meaning of the flag will then be > ignored. I think once you suggest a SHOULD to use NoACK then the rest is a SHOULD; i.e if you set an ACK then you expect a response back even if it is an event. > Message Body: > The message body for an event notification message consists of (at > least) one or more than one TLVs that describe the notified > events. The TLV is also a LFBselect TLV (with the TLV > Type="LFBselect"), and a generic format definition of which has > been given in Section 6.1.1. Detailed data format of a LFBselect > TLV for event notification message is as below: > My comments as before in the config. The Operation and LFBSelect should be defined elsewhere and just used in these messages. Clearly you are repeating this text and diagrams relative to the config message. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 23 12:06:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bIP-0005JC-Gd for forces-archive@megatron.ietf.org; Tue, 23 Aug 2005 12:06:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12285 for ; Tue, 23 Aug 2005 12:06:38 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bIY-0000h0-CD for forces-archive@IETF.ORG; Tue, 23 Aug 2005 12:06:50 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010D5A4B@cherry.ease.lsoft.com>; Tue, 23 Aug 2005 12:06:37 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83619838 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 23 Aug 2005 12:06:36 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 23 Aug 2005 12:06:35 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7NFPNXK070954; Tue, 23 Aug 2005 08:25:25 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <007c01c5a40e$792d5a80$9273c0dc@WwmLapSamsung> <005301c5a745$82a80a80$1f12fea9@wwm1> Content-Type: multipart/mixed; boundary="=-3OEsJh8x7chyeBRtqsrW" Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Approved-By: Jamal Hadi Salim Message-ID: <1124807365.6579.16.camel@localhost.localdomain> Date: Tue, 23 Aug 2005 10:29:25 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [Edtorial 4] Configure Message (Section 6.5) modifying, also related to issue 57 Comments: To: Weiming Wang To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <005301c5a745$82a80a80$1f12fea9@wwm1> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --=-3OEsJh8x7chyeBRtqsrW Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello Weiming, On Tue, 2005-23-08 at 02:15 +0800, Weiming Wang wrote: > Hi, > > Attached is the supposed modifying to Section 6.5 for the purpose of consistency. >Pls send your comments. Comments attached. cheers, jamal --=-3OEsJh8x7chyeBRtqsrW Content-Disposition: attachment; filename=configmsg.txt Content-Type: text/plain; name=configmsg.txt; charset=utf-8 Content-Transfer-Encoding: 7bit >6.5.1 Config Message > > This message is sent by the CE to the FE to configure FE or LFB > attributes. This message is also used by the CE to subscribe/ > unsubscribe to FE and LFB events. > Everything to be configured is maintained in a LFB, no? i.e it is ambigous to say "to configure FE" > > Message transfer direction: > CE to FE > > Message Header: > The Message Type in the header is set MessageType= 'Config'. The > ACK flag in the header is can be used by the CE to turn off any more like is used to control response from the CE. > response from the FE. The default behavior is to turn on the ACK > to get the config response from the FE. > > Message body: > The config message body consists of (at least) one or more than > one TLV that describes entries to config. The TLV is called > LFBselect TLV (with the TLV Type="LFBselect"), and a generic > format definition of which has been given in Section 6.1.1. I would reword as: " The config message body consists of (at least) one or more LFBselect TLV as described in section 6.1.1." I think it would also make sense to have LFBSelect TLV and operation TLV in their own sub-sub sections? > Detailed data format of a LFBselect TLV for config message is as > below: > > Operation TLV: > > PATH-DATA-TLV: > This is generically a PATH-DATA-TLV format that has been defined > in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF > definition. The restriction on the use of PATH-DATA-TLV for SET > operation is it SHALL NOT contain any RESULT-TLV. The > erstriction on the use of PATH-DATA-TLV for DEL operation is it ^^^^^^^^^^^ typo > *Note: FE Activate/Deactivate, Shutdown FE commands for State > Maintenance will be sent using Config messages. > Where do we talk about FE Activate/Deactivate, Shutdown ? Are these not just association messages etc? > > individual LFBs. > > To better understand the above PDU format, we can show a tree Perharps replace "understand" with explain or illustrate. > >6.5.2 Config Response Message > > > Message body: > The Config response message body consists of (at least) one or > more than one TLV that describes entries for config response. > The TLV is called LFBselect TLV (with the TLV Type="LFBselect"), > and a generic format definition of which has been given in > Section 6.1.1. Detailed data format of one LFBselect TLV for > Should we instead talk about Result TLV here? --=-3OEsJh8x7chyeBRtqsrW-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 09:05:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7uwx-00047D-D8 for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 09:05:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19183 for ; Wed, 24 Aug 2005 09:05:50 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7uxA-0007rg-Mv for forces-archive@IETF.ORG; Wed, 24 Aug 2005 09:06:11 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.010D6AD2@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 9:05:37 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83727657 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 09:05:36 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 09:05:35 -0400 Received: from [220.192.124.199] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 24 Aug 2005 21:35:42 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> Date: Wed, 24 Aug 2005 19:51:52 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 36] FE/CE failover To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi, The draft has been updated in Section 6.2.1(FE Protocol LFB) according to the text proposed below. The issue 36 can be closed! Thanks, Weiming ----- Original Message ----- From: "Wang,Weiming" To: Sent: Friday, August 19, 2005 12:20 AM Subject: Re: [Issue 36] FE/CE failover > > > > Issue 36: FE/CE failover. CE failover policy determines if the FE > should > > continue or stop forwarding packets after an association is lost. FE > > failover policy determines how the FE should behave after it regains > an > > association, currently: start from default state again (no fast > > recovery). Accept. > > Updated in tracker, text proposed. Must be added to the draft. > > [Weiming] I think Hormuzd has added some in his revision as below: > > * FE restart policy - This specifies the behavior of the FE > during a restart. For example, this would specify if the FE > should start from a default state after a CE failure in the NE. > > * CE failover policy - This specifies the behavior of the FE > during a CE failure and restart time interval. For example, > this would specify if the FE should continue running or stop > operation during a CE failure in the NE. > > I'm based on you two and propose the following: > > * FE restart policy - This specifies the behavior of the FE > during a restart. For example, this would specify if the FE > should start from scratch or from a default state after a CE > failure in the NE. Default value for this attribute should be to let the > FE to start from scratch. > > * CE failover policy - This specifies the behavior of the FE > during a CE failure and restart time interval. For example, > this would specify if the FE should continue running or stop > operation during a CE failure in the NE. Default value for this > attribute should be to let the FE to continue running. > > Comments please. > > Thanks, > Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 09:06:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ux9-0004Jg-9X for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 09:06:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19193 for ; Wed, 24 Aug 2005 09:06:02 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7uxT-0007sM-CY for forces-archive@IETF.ORG; Wed, 24 Aug 2005 09:06:23 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010D69A2@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 9:06:02 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83727679 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 09:06:01 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 09:05:59 -0400 Received: from [220.192.124.199] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 24 Aug 2005 21:35:51 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> <1124807356.6579.13.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <013501c5a8ab$7c380fd0$c77cc0dc@WwmLapSamsung> Date: Wed, 24 Aug 2005 20:57:00 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 34] Header flags To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Hi, I modified the text as below: - ACK indicator(2 bits) The ACK indicator flag is used by a protocol message sender to indicate the message receiver whether a response message is required back by the sender. The values are defined as below: 'NoACK' (00) - to indicate the message receiver not to send any response message back to this message sender. 'SuccessACK'(01) - to inidcate the message receiver to send a response message back only when the message has been successfully processed by the receiver. 'UnsuccessACK'(10) - to indicate the message receiver to send a response message back only when the message has been found unable to be successfully processed. In other words, if the message can be processed successfully, the sender will not expect any response from the receiver. 'ACKAll' (11) - to indicate the message receiver to send a response message back in any case. Note that in above definitions, a success to process a message actually means the message is completely processed(excuted) without any failure. This also means anything else than a complete success is a failure and results in an unsuccess of the message processing. As a result, for the execution modes(defined in Section 3.3.1.1) like execute-all-or-none, execute-until-failure, and continue-execute-on-failure, if any single operation in the message fails, then it will result in a response only if the ACK indicator is set to 'UnsuccessACK' or to 'ACKAll'. Also note that some messages defined in the followed sections may have default requirements for responses. In these cases, the ACK indicators will be ignored by message receiver. We summarize these defaut requirements as below: . Association Message will always expect a response. . Teardown Message, Redirect Message, and Heartbeat Message will always never expect responses. . Any kind of response messages will never expect further responses. I'l update this soon if theres no more comments, and then the issue 34 can be closed. Jamal, pls see more reply inline below. Thanks, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Tuesday, August 23, 2005 10:29 PM Subject: Re: [issue 34] Header flags > On Fri, 2005-19-08 at 11:37 +0800, Wang,Weiming wrote: > > Joel, > > > > ----- Original Message ----- > > From: "Joel M. Halpern" > > > > > I think that this needs some tuning. > > > A single "message" with a single set of flags can contain multiple > > operations. > > > We have in other places in the document stated that there are three > > > different modes of operation: > > First of all, we should note that ACK flag does not interfere into any > > operations. Then, we noted that ACK flag also does not affect the > > response format of operations. The only effect of ACK flag is to choose > > a response at the time. I see the question you raised as that we may > > need some definitions and specifications in the operations regarding ACK > > flag meaning, whereas the ACK flag still keep its clearness in meaning. > > > > Could we specify that the ACK flags override the All-or-none, > Operate-until-error etc? I still prefer to define what 'Success' and 'Unsuccess' for ACK indicator mean. If we say override as above, we then also need to define what 'override' actually mean. > > > > > >p.s., Jamal, Could you provide some text on the Batch flag and the > > > >Atomicity flag? > > Why dont i wait until you are done since i think youve done a lot of > cleanup and this may be related to the execution text. i.e i want to > correlate with the rest of the text. Maybe we can open an issue in the > tracker so it is not forgotten. That's fine. I don't think we have to open a speccial issue for this. The blank is obvious and I think you can notice it easily. I'l also remember it:) > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 10:59:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wjD-00063X-Vu for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 10:59:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26360 for ; Wed, 24 Aug 2005 10:59:46 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7wjU-00039f-En for forces-archive@IETF.ORG; Wed, 24 Aug 2005 11:00:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010D6B5C@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 10:59:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83736443 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 10:59:40 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 10:59:39 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7OEIbXK081014; Wed, 24 Aug 2005 07:18:38 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1124895533.6300.7.camel@localhost.localdomain> Date: Wed, 24 Aug 2005 10:58:53 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [Issue 36] FE/CE failover Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Weiming, Dont close it yet since I am not sure if i commented on this or not: a) Default behaviors for the two restarts are contradictory. If the Default FE restart behavior is to start from scratch, that implies an element of trust involved i.e the FE doesnt trust the state it has during the disappearance of the CE. OTOH, the CE restart default seems to say the FE should continue to use the policies it has on disappearance of the CE which implies it trusts the state it has as being valid ;-> Is it fair to say we need to choose similar default policies? b) Should we enumerate all possibilities in the text for the two restart policies? cheers, jamal On Wed, 2005-24-08 at 19:51 +0800, Wang,Weiming wrote: > Hi, > > The draft has been updated in Section 6.2.1(FE Protocol LFB) according to > the text proposed below. > > The issue 36 can be closed! [..] > > I'm based on you two and propose the following: > > > > * FE restart policy - This specifies the behavior of the FE > > during a restart. For example, this would specify if the FE > > should start from scratch or from a default state after a CE > > failure in the NE. Default value for this attribute should be to let the > > FE to start from scratch. > > > > * CE failover policy - This specifies the behavior of the FE > > during a CE failure and restart time interval. For example, > > this would specify if the FE should continue running or stop > > operation during a CE failure in the NE. Default value for this > > attribute should be to let the FE to continue running. > > > > Comments please. > > > > Thanks, > > Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 11:07:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wr7-0007jU-Ia for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 11:07:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26764 for ; Wed, 24 Aug 2005 11:07:55 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7wrQ-0003Rr-Gl for forces-archive@IETF.ORG; Wed, 24 Aug 2005 11:08:19 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010D6BB4@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 11:07:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83737127 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 11:07:54 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 11:07:52 -0400 Received: from [220.192.124.77] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 24 Aug 2005 23:37:59 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <000f01c5a338$434a3540$1d72c0dc@WwmLapSamsung> <1124807344.6579.11.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <018301c5a8bc$8b80a8b0$c77cc0dc@WwmLapSamsung> Date: Wed, 24 Aug 2005 21:54:49 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 32] Packet Redirect To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Jamal, > > Where, Meta Data ID is an identifier for the meta data, which is > > defined by FE-Model[FE-MODEL]. This actually implies > > a Meta Data ID is statically assigned by FE-Model. > > > This is not realistic. I think that way after the FE-Model becomes RFCs > metadata will continue to be defined. How about adding a mention as 'by FE-Model and LFB library'? Do we have other documents related to the definition? Thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 11:07:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wr7-0007jq-Uj for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 11:07:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26767 for ; Wed, 24 Aug 2005 11:07:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7wrT-0003Rr-4V for forces-archive@IETF.ORG; Wed, 24 Aug 2005 11:08:19 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010D6BF1@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 11:07:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83737122 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 11:07:52 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 11:07:51 -0400 Received: from [220.192.124.77] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 24 Aug 2005 23:38:06 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> <003a01c5a7a2$63e3c820$1f12fea9@wwm1> <6.2.1.2.0.20050823105005.02d046b8@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <018401c5a8bc$8f976970$c77cc0dc@WwmLapSamsung> Date: Wed, 24 Aug 2005 22:09:59 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 34] Header flags To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Joel, Pls allow me to change the titile to issue 34. I agree with you some what. I also noticed that actualy the ACK flag is only useful for Config message after we removed event response function. The question is, if we don't put it in the common header, as a global flag for this message, where can we put then and how we can make it specifically for config message only? I thought of puting the flag in an LFBselect TLV, the operation TLV, (or even in a Path flag). In this way, it makes the flag only restricted to the LFB selector, the operation, (or even the path). It means some LFBselect or operations inside wants response, while others may not. I didn't think it further. Thanks, Weiming ----- Original Message ----- From: "Joel M. Halpern" > The text below is an excerpt from a proposed methodology for a particular > PL message. > It is about event notification messages, and the fact that no responses are > expected to them. (They are transmitted reliably, and the FE which sends > them has no use for an ACK. > > However, if we are going to take this approach, we render the ack flags > much more complex. We should either define the ack flags globally and use > them everywhere, or we should not have them in the common message header. > If we choose to keep them, then a message receiver should be prepared to > generate an ACK for ANY message it receives, if the flags tell it to do so. > > Yours, > Joel M. Halpern > > At 01:20 AM 8/23/2005, Weiming Wang wrote: > > header SHOULD be reasonably set to 'NoACK'. If the ACK flag is > > set to any other values, the meaning of the flag will then be > > ignored. From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 11:08:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wrE-0007le-Hi for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 11:08:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26774 for ; Wed, 24 Aug 2005 11:08:02 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7wrY-0003S4-56 for forces-archive@IETF.ORG; Wed, 24 Aug 2005 11:08:25 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010D6B16@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 11:08:01 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83737148 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 11:08:01 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 11:07:53 -0400 Received: from [220.192.124.77] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 24 Aug 2005 23:38:10 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> <003a01c5a7a2$63e3c820$1f12fea9@wwm1> <1124807374.6579.19.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <018501c5a8bc$91c08b00$c77cc0dc@WwmLapSamsung> Date: Wed, 24 Aug 2005 22:57:47 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 57] Inconsistent operation types To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Jamal, Thanks for the intensive review. Some have updated accordingly and some replied inline. Thanks, Weiming Hormzud, could you check inline also? ----- Original Message ----- From: "Jamal Hadi Salim" > > > Message Header: > > The Message Type in the message header is set to > > MessageType = 'EventNotification'. Because we do not expect any > > response for event notification, the ACK flag in the message > > header SHOULD be reasonably set to 'NoACK'. If the ACK flag is > > set to any other values, the meaning of the flag will then be > > ignored. > > I think once you suggest a SHOULD to use NoACK then the rest is a > SHOULD; > i.e if you set an ACK then you expect a response back even if it is > an event. Can I understand in this case, SHOULD means it's not an error, while if we use MUST, it becomes an error. > > > Message Body: > > The message body for an event notification message consists of (at > > least) one or more than one TLVs that describe the notified > > events. The TLV is also a LFBselect TLV (with the TLV > > Type="LFBselect"), and a generic format definition of which has > > been given in Section 6.1.1. Detailed data format of a LFBselect > > TLV for event notification message is as below: > > > > My comments as before in the config. The Operation and LFBSelect should > be defined elsewhere and just used in these messages. Clearly you are > repeating this text and diagrams relative to the config message. Yes, I noticed this. Just not very sure where should it be put, in the BNF, or using another section? After we decide this, I can update the text actually. Hormuzd, could you give a reply on this? > > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 11:10:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wu3-00085l-GU for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 11:10:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26909 for ; Wed, 24 Aug 2005 11:10:57 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7wuO-0003XA-NM for forces-archive@IETF.ORG; Wed, 24 Aug 2005 11:11:21 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010D6B2E@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 11:10:58 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83737391 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 11:10:57 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 11:10:57 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7OEUHXK081106; Wed, 24 Aug 2005 07:30:19 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> <1124807356.6579.13.camel@localhost.localdomain> <013501c5a8ab$7c380fd0$c77cc0dc@WwmLapSamsung> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1124896236.6300.18.camel@localhost.localdomain> Date: Wed, 24 Aug 2005 11:10:36 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 34] Header flags Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <013501c5a8ab$7c380fd0$c77cc0dc@WwmLapSamsung> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit On Wed, 2005-24-08 at 20:57 +0800, Wang,Weiming wrote: > 'UnsuccessACK'(10) - Do we wanna call this a FailureACK instead? > ----- Original Message ----- > From: "Jamal Hadi Salim" > To: > Sent: Tuesday, August 23, 2005 10:29 PM > Subject: Re: [issue 34] Header flags > > > > Could we specify that the ACK flags override the All-or-none, > > Operate-until-error etc? > I still prefer to define what 'Success' and 'Unsuccess' for ACK indicator > mean. If we say override as above, we then also need to define what > 'override' actually mean. My comment was mostly to Joel's concern in that there are contradictory statements i.e: for example, consider when you say "Operate-until-error" but then you set a flag to say "noACK": statement1) "Operate-until-error" says to the receiver "when the error occurs stop and let me know" statement2) "noACK" says "dont bother telling me anything". In other words we have ambiguity between the two statements. Which one should the receiver belive?;-> Typically conflict resolution requeires to specify a rule of which among X possible statement wins/overrides. This could be done in the text. Hope that makes sense. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 11:45:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xR5-00055d-FV for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 11:45:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29489 for ; Wed, 24 Aug 2005 11:45:05 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xRQ-0004wB-Q1 for forces-archive@IETF.ORG; Wed, 24 Aug 2005 11:45:29 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.010D6DEA@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 11:45:06 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83740107 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 11:44:58 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 11:44:58 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7OF30XK081338; Wed, 24 Aug 2005 08:03:01 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <000f01c5a338$434a3540$1d72c0dc@WwmLapSamsung> <1124807344.6579.11.camel@localhost.localdomain> <018301c5a8bc$8b80a8b0$c77cc0dc@WwmLapSamsung> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1124898194.6611.1.camel@localhost.localdomain> Date: Wed, 24 Aug 2005 11:43:13 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 32] Packet Redirect Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <018301c5a8bc$8b80a8b0$c77cc0dc@WwmLapSamsung> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit On Wed, 2005-24-08 at 21:54 +0800, Wang,Weiming wrote: > Jamal, > > > > Where, Meta Data ID is an identifier for the meta data, which is > > > defined by FE-Model[FE-MODEL]. This actually implies > > > a Meta Data ID is statically assigned by FE-Model. > > > > > > This is not realistic. I think that way after the FE-Model becomes RFCs > > metadata will continue to be defined. > How about adding a mention as 'by FE-Model and LFB library'? Do we have > other documents related to the definition? LFBs will continue to be defined in the future even post LFB Library document; for example if Forces is still around in 10 years, someone will define an LFB and its associated metadata. So i would suggest just "A metaid is staticaly assigned by the LFB definitions" cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 11:53:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xYx-0007ts-Ky for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 11:53:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29909 for ; Wed, 24 Aug 2005 11:53:13 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xZJ-0005BS-6k for forces-archive@IETF.ORG; Wed, 24 Aug 2005 11:53:37 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.010D6BB4@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 11:53:14 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83740454 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 11:52:56 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 11:52:55 -0400 Received: from [10.0.0.229] (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7OFCJXK081433; Wed, 24 Aug 2005 08:12:20 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> <003a01c5a7a2$63e3c820$1f12fea9@wwm1> <1124807374.6579.19.camel@localhost.localdomain> <018501c5a8bc$91c08b00$c77cc0dc@WwmLapSamsung> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1124898758.6611.8.camel@localhost.localdomain> Date: Wed, 24 Aug 2005 11:52:38 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [Issue 57] Inconsistent operation types Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <018501c5a8bc$91c08b00$c77cc0dc@WwmLapSamsung> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit On Wed, 2005-24-08 at 22:57 +0800, Wang,Weiming wrote: > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > > > Message Header: > > > The Message Type in the message header is set to > > > MessageType = 'EventNotification'. Because we do not expect any > > > response for event notification, the ACK flag in the message > > > header SHOULD be reasonably set to 'NoACK'. If the ACK flag is > > > set to any other values, the meaning of the flag will then be > > > ignored. > > > > I think once you suggest a SHOULD to use NoACK then the rest is a > > SHOULD; > > i.e if you set an ACK then you expect a response back even if it is > > an event. > Can I understand in this case, SHOULD means it's not an error, while if we > use MUST, it becomes an error. SHOULD is a recommendation. Ok, so let me change a little what i said. If you say "the header SHOULD be reasonably set to 'NoACK'" then a response MUST not be issued to such a message. If you say "SHOULD set the ACK flag" then a response MUST be provided to the message. > > My comments as before in the config. The Operation and LFBSelect should > > be defined elsewhere and just used in these messages. Clearly you are > > repeating this text and diagrams relative to the config message. > Yes, I noticed this. Just not very sure where should it be put, in the BNF, > or using another section? After we decide this, I can update the text > actually. I think another subsection of the message description - maybe just before individual ones are done, this would be the first one. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 12:17:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xwZ-0000xS-6Z for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 12:17:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01882 for ; Wed, 24 Aug 2005 12:17:36 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xwu-0006BE-Tt for forces-archive@IETF.ORG; Wed, 24 Aug 2005 12:18:01 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010D6DCC@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 12:14:57 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83745384 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 12:14:57 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 12:14:54 -0400 Received: from [220.192.124.206] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 25 Aug 2005 00:44:47 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <1124807362.6579.15.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <01ea01c5a8c5$dfad2fe0$c77cc0dc@WwmLapSamsung> Date: Thu, 25 Aug 2005 00:05:15 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 57] Inconsistent operation types To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Jamal, Hormuzd, and all, Based on this Jamal's and last Robert's comments, can we reach an agreement as below: 1. Association-setup message with REPORT operation TLV. 2. Association-setup response message without operation followed, but with a TLV followed to return result only(note not a RESULT-TLV in PATH-DATA). We can name the TLV as something like ASRresult. 3. Association-teardown message with a TLV to show reason, as TEAreason (note we have already had the TLV) In this way, at the message body first level, we have three TLVs: LFBselect ASRresult TEAreason thanks, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Tuesday, August 23, 2005 10:29 PM Subject: Re: [Issue 57] Inconsistent operation types > On Tue, 2005-23-08 at 01:57 +0800, Weiming Wang wrote: > > > EVENT-NOTIFICATION message: > > Report > > [Weiming]Updated. Is going to completely remove the section of event notification > > response? > > > > Lets review after you complete your update. > > > ASSOCIATION-SETUP message: > > Get-response (optional, used to advertise fields from the FE LFB > > and/or FE Protocol LFB in an unsolicited manner) > > > > [Weiming]haven't made changes. Questions: > > Do we really need an operation in the association setup message? It will make > > flooding attack more easy, I think. Why don't we let CE later to query then? > > > > I think making it optional is fine. Optionally it can be used to cut > down on the number of messages issued. > > > ASSOCIATION-SETUP-RESPONSE message: > > Set (optional, only to set fields in the FE LFB and/or FE Protocol LFB) > > [Weiming]Haven't made changes. Questions: > > Does this really mean we allow a SET operation that never be able to get SET > > response? Why don't we use config message to SET then? > > I think the challenge in the naming convention as we discussed in the > meeting is that Config goes from CE->FE and response goes back. > However you do bring up a good point: the CE would need to know if the > SET was successful or not. A GET following the SET should be sufficient. > Which actually invalidates the need to SET in the ASSOCIATION-SETUP > message since eventually the number of messages is going to be > equivalent. Thoughts? > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 12:17:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xwY-0000xG-To for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 12:17:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01876 for ; Wed, 24 Aug 2005 12:17:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xws-0006BE-DH for forces-archive@IETF.ORG; Wed, 24 Aug 2005 12:17:59 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010D6B9C@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 12:14:40 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83745270 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 12:14:37 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 12:14:36 -0400 Received: from [220.192.124.206] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 25 Aug 2005 00:44:40 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> <1124807356.6579.13.camel@localhost.localdomain> <013501c5a8ab$7c380fd0$c77cc0dc@WwmLapSamsung> <1124896236.6300.18.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <01e801c5a8c5$db97f5c0$c77cc0dc@WwmLapSamsung> Date: Wed, 24 Aug 2005 23:31:10 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 34] Header flags To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 ----- Original Message ----- From: "Jamal Hadi Salim" > On Wed, 2005-24-08 at 20:57 +0800, Wang,Weiming wrote: > > > 'UnsuccessACK'(10) - > > Do we wanna call this a FailureACK instead? OK, I also hope to change ACKAll to AlwaysACK. Thanks, Weiming > > > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > To: > > Sent: Tuesday, August 23, 2005 10:29 PM > > Subject: Re: [issue 34] Header flags > > > > > > > > Could we specify that the ACK flags override the All-or-none, > > > Operate-until-error etc? > > I still prefer to define what 'Success' and 'Unsuccess' for ACK indicator > > mean. If we say override as above, we then also need to define what > > 'override' actually mean. > > My comment was mostly to Joel's concern in that there are contradictory > statements i.e: > for example, consider when you say "Operate-until-error" but then you > set a flag to say "noACK": > > statement1) "Operate-until-error" says to the receiver "when the error > occurs stop and let me know" > statement2) "noACK" says "dont bother telling me anything". > > In other words we have ambiguity between the two statements. Which one > should the receiver belive?;-> > Typically conflict resolution requeires to specify a rule of which among > X possible statement wins/overrides. This could be done in the > text. Hope that makes sense. > > cheers, > jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 12:17:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xwY-0000xE-Tr for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 12:17:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01878 for ; Wed, 24 Aug 2005 12:17:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xwu-0006BE-0w for forces-archive@IETF.ORG; Wed, 24 Aug 2005 12:18:00 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.010D6DC7@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 12:14:41 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83745289 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 12:14:40 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 12:14:39 -0400 Received: from [220.192.124.206] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Thu, 25 Aug 2005 00:44:43 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <007c01c5a40e$792d5a80$9273c0dc@WwmLapSamsung> <005301c5a745$82a80a80$1f12fea9@wwm1> <1124807365.6579.16.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <01e901c5a8c5$dd60cee0$c77cc0dc@WwmLapSamsung> Date: Wed, 24 Aug 2005 23:53:13 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Edtorial 4] Configure Message (Section 6.5) modifying, also related to issue 57 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Jamal, and Hormzud, etc, I also strongly tend to rewrite the message sections with the idea to strip off the LFBselect TLV off and put it in a Section 6.1.1 or elsewhere with a special section, but I still want to keep operation TLV description in every message text, for it does differ from each other regarding the Type and the Path-data-TLV description. Can we decide it, Hormuzd? then I can update quickly. Thanks, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Tuesday, August 23, 2005 10:29 PM Subject: Re: [Edtorial 4] Configure Message (Section 6.5) modifying, also related to issue 57 > Hello Weiming, > > On Tue, 2005-23-08 at 02:15 +0800, Weiming Wang wrote: > > Hi, > > > > Attached is the supposed modifying to Section 6.5 for the purpose of consistency. > >Pls send your comments. > > > Comments attached. > > cheers, > jamal > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 16:51:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82DP-0004w8-Fk for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 16:51:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20408 for ; Wed, 24 Aug 2005 16:51:17 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E82Dh-0007oN-IG for forces-archive@IETF.ORG; Wed, 24 Aug 2005 16:51:43 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.010D7014@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 16:51:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83771293 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 16:51:11 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 16:51:11 -0400 Received: from [70.104.233.136] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12024516 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 16:51:10 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> <1124807356.6579.13.camel@localhost.localdomain> <013501c5a8ab$7c380fd0$c77cc0dc@WwmLapSamsung> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050824164615.02d3d498@localhost> Date: Wed, 24 Aug 2005 16:51:09 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue 34] Header flags To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <013501c5a8ab$7c380fd0$c77cc0dc@WwmLapSamsung> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Your proposed clarification of the interaction of the ACK flags and multiple operations makes sense to me. (I doubt if it ever makes sense to set the flags to "SuccessACK", but we can await implementation experience.) However, the text below leaves me uncomfortable. As I said before, if we are going to define the flags as global, they should be global. I could understand text which said "setting the flags improperly in the following will cause problems." In fact, I believe that an Association Request message like, the others in the list, should not normally be sent with an ACK expected. Heck, a GET request should not normally be sent with an All-ACK. The normal success response to a GET is not an ACK, but rather is the get response. Is it possible we have some ambiguity here between response messages and application level acknowledgements? Is the only message with a range of behaviors a SET request? If so, these flags belong in the SET request, not in the common message header? Yours, Joel M. Halpern At 08:57 AM 8/24/2005, Wang,Weiming wrote: >Also note that some messages defined in the followed sections may have >default requirements for responses. In these cases, the >ACK indicators will be ignored by message receiver. We summarize these >defaut requirements >as below: >. Association Message will always expect a response. >. Teardown Message, Redirect Message, and Heartbeat Message will always >never expect responses. >. Any kind of response messages will never expect further responses. From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 16:55:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82Hs-0006TQ-Pv for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 16:55:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20572 for ; Wed, 24 Aug 2005 16:55:54 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E82IF-0007wk-V8 for forces-archive@IETF.ORG; Wed, 24 Aug 2005 16:56:21 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.010D71B7@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 16:55:54 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83771466 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 16:55:53 -0400 Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 16:55:53 -0400 Received: from [70.104.233.136] (HELO JMHLap3.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 12024542; Wed, 24 Aug 2005 16:55:52 -0400 X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> <003a01c5a7a2$63e3c820$1f12fea9@wwm1> <6.2.1.2.0.20050823105005.02d046b8@localhost> <018401c5a8bc$8f976970$c77cc0dc@WwmLapSamsung> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: "Joel M. Halpern" Message-ID: <6.2.1.2.0.20050824165452.02d3cba0@localhost> Date: Wed, 24 Aug 2005 16:55:47 -0400 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: [issue 34] Header flags Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <018401c5a8bc$8f976970$c77cc0dc@WwmLapSamsung> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Looking at your more recent not, it seems that these flags only apply to the SET (Config) Request). If that is so, then they belong in the SET Operation TLV, or in the format of the Config message. Yours, Joel M. Halpern At 10:09 AM 8/24/2005, Wang,Weiming wrote: >Joel, > >Pls allow me to change the titile to issue 34. > >I agree with you some what. I also noticed that actualy the ACK flag is only >useful for Config message after we removed event response function. > >The question is, if we don't put it in the common header, as a global flag >for this message, where can we put then and how we can make it specifically >for config message only? > >I thought of puting the flag in an LFBselect TLV, the operation TLV, (or >even in a Path flag). In this way, it makes the flag only restricted to the >LFB selector, the operation, (or even the path). It means some LFBselect >or operations inside wants response, while others may not. I didn't think it >further. > >Thanks, >Weiming > >----- Original Message ----- >From: "Joel M. Halpern" > > > The text below is an excerpt from a proposed methodology for a particular > > PL message. > > It is about event notification messages, and the fact that no responses >are > > expected to them. (They are transmitted reliably, and the FE which sends > > them has no use for an ACK. > > > > However, if we are going to take this approach, we render the ack flags > > much more complex. We should either define the ack flags globally and use > > them everywhere, or we should not have them in the common message header. > > If we choose to keep them, then a message receiver should be prepared to > > generate an ACK for ANY message it receives, if the flags tell it to do >so. > > > > Yours, > > Joel M. Halpern > > > > At 01:20 AM 8/23/2005, Weiming Wang wrote: > > > header SHOULD be reasonably set to 'NoACK'. If the ACK flag is > > > set to any other values, the meaning of the flag will then be > > > ignored. From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 24 17:28:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82nV-0000cJ-PW for forces-archive@megatron.ietf.org; Wed, 24 Aug 2005 17:28:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22587 for ; Wed, 24 Aug 2005 17:28:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E82nr-0000fc-7f for forces-archive@IETF.ORG; Wed, 24 Aug 2005 17:29:02 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010D7015@cherry.ease.lsoft.com>; Wed, 24 Aug 2005 17:28:30 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 83773887 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 24 Aug 2005 17:28:29 -0400 Received: from 198.24.6.3 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 24 Aug 2005 17:28:28 -0400 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id j7OLSSrH014258 for ; Wed, 24 Aug 2005 16:28:28 -0500 Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 24 Aug 2005 16:28:28 -0500 Received: from [142.133.72.71] (dhcp723-071.rnet.lmc.ericsson.se [142.133.72.71]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id RG33TKAA; Wed, 24 Aug 2005 17:27:49 -0400 User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Approved-By: Jon Maloy Message-ID: <430CE63B.5060603@ericsson.com> Date: Wed, 24 Aug 2005 17:27:23 -0400 Reply-To: Jon Maloy Sender: Forwarding and Control Element Separation From: Jon Maloy Subject: TIPC/TML draft WG item ? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hi all, I realized just after my presentation of the TIPC/TML draft in Paris that I had forgotten something: I did not ask the meeting if it agreed on making the draft a WG item. So, I do that now: Do the chairs and the WG group members accept the TIPC/TML draft (draft-maloy-tipc-tml-00) as a WG item ? The draft is in about the same state as the TCP/TML draft, but more complete regarding multicast and data channel definition, so I don't think maturity should be an obstacle. Regards ///jon From UrsulaSwanson@behalfs.com Fri Aug 26 08:46:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dbZ-0002ky-Pm for forces-archive@megatron.ietf.org; Fri, 26 Aug 2005 08:46:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16010 for ; Fri, 26 Aug 2005 08:46:44 -0400 (EDT) Received: from 84-72-103-225.dclient.hispeed.ch ([84.72.103.225]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E8dbs-0004zl-3A for forces-archive@ietf.org; Fri, 26 Aug 2005 08:47:31 -0400 Received: from 6x0@localhost by 5WIk.int (8.11.6/8.11.6); Fri, 26 Aug 2005 09:18:49 -0500 Message-ID: From: "Barbara Lamb" Reply-To: "Barbara Lamb" To: burton.gifford@ietf.org, 3dmegaco@ietf.org, forces-archive@ietf.org, rufus.olsen@ietf.org Subject: Windows XP Pro $49.95, Office 2003 $69.95 Symantec Date: Fri, 26 Aug 2005 16:11:49 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: UrsulaSwanson@behalfs.com Content-Type: multipart/mixed; boundary="--mw2fnlKzE0d60VsRJ" X-Spam-Score: 1.6 (+) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 QYnZ ----mw2fnlKzE0d60VsRJ Content-Type: text/html; Content-Transfer-Encoding: quoted-printable K
Opt-in Email Special Offer   = ;  unsubscribe me
=
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: HzIyrKw
 

Sales Ra= nk: #1
System requirements  |  = Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Rev= iew:3D"5 Based on 152367 reviews. = Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: 5N5yhDXP
 =

Sales Rank: #2
System requirements = ; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 15383= 7 reviews. Write a review.

<= p>Microsoft Windows XP Professional or Longhorn Edition
Microsoft<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/promotions/sti= cker/newest_version.gif width=3D82 height=3D14>

Choose:
 

=
List Price:$279.00
Price:= $49.99
You Save:$229.01 (85%)



Ava= ilability: Available for INSTANT download!
Coupon Code: HSD= hzSTs
 

Sales Rank: #3
System requi= rements  |  Other Versions=
Date Coupon Expires: August 31st= , 2005
Average Customer Review:3D"5 Based on 12734 reviews. Write a revie= w.

Adobe Acrobat Professional V 7.0
= Adobe

Choose:
&nbs= p;

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: 22nqFooAa
 = ;

Sales Rank: #4
System requirements = |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 1122 = reviews. Write a review.

=

----mw2fnlKzE0d60VsRJ-- From owner-forces@PEACH.EASE.LSOFT.COM Fri Aug 26 12:15:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8grn-0005XQ-Jk for forces-archive@megatron.ietf.org; Fri, 26 Aug 2005 12:15:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29688 for ; Fri, 26 Aug 2005 12:15:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8gsP-0003ul-AZ for forces-archive@IETF.ORG; Fri, 26 Aug 2005 12:16:30 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010D920F@cherry.ease.lsoft.com>; Fri, 26 Aug 2005 12:15:30 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84004905 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 26 Aug 2005 12:15:29 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Fri, 26 Aug 2005 12:15:23 -0400 Received: from [211.167.158.207] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Sat, 27 Aug 2005 00:45:45 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <1124807362.6579.15.camel@localhost.localdomain> <01ea01c5a8c5$dfad2fe0$c77cc0dc@WwmLapSamsung> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0023_01C5AA9C.7596E2D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: Weiming Wang Message-ID: <002501c5aa59$688d0210$1f12fea9@wwm1> Date: Sat, 27 Aug 2005 00:15:41 +0800 Reply-To: Weiming Wang Sender: Forwarding and Control Element Separation From: Weiming Wang Subject: Re: [Issue 57] Inconsistent operation types To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 1.1 (+) X-Scan-Signature: 2c95861037f9de21ac04368792292e54 This is a multi-part message in MIME format. ------=_NextPart_000_0023_01C5AA9C.7596E2D0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCkF0dGFjaGVkIGlzIHRoZSBzdXBwb3NlZCB1cGRhdGUgZm9yIGFsbCBtZXNzYWdlcywg d2l0aCB0aGUgZm9sbG93aW5nIHRyYWNlOg0KDQoxLiBMRkIgc2VsZWN0IFRMViBpcyBpbiBhIHNw ZWNpZmljIHNlY3Rpb24uDQoNCjIuIFRMVnMgYW5kIE9wZXJhdGlvbnMgYXMgYmVsb3c6DQoNCiAg ICAgICAgICAgICAgICAgICAgICBUTFZzICAgICAgICAgICAgT3BlcmF0aW9ucw0KDQpBc3NvU2V0 dXAgICAgICAgICAgIExGQnNlbGVjdCAgICAgICAgICAgUkVQT1JUDQoNCkFzc29TZXR1cFJlc3Ag ICAgICAgQVNScmVzdWx0ICAgICAgICAgICBub25lDQoNCkFzc29UZWFyZG93biAgICAgICAgQVNU cmVhc29uICAgICAgICAgICBub25lDQoNCkNvbmZpZyAgICAgICAgICAgICAgTEZCc2VsZWN0ICAg ICAgICAgICBTRVQsIERFTA0KDQpDb25maWcgUmVzcG9uc2UgICAgIExGQnNlbGVjdCAgICAgICAg ICAgU0VULVJFU1BPTlNFIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IERFTC1SRVNQT05TRQ0KDQpRdWVyeSAgICAgICAgICAgICAgIExGQnNlbGVjdCAgICAgICAgICAg R0VUDQoNClF1ZXJ5IFJlc3BvbnNlICAgICAgTEZCc2VsZWN0ICAgICAgICAgICBHRVQtUkVTUE9O U0UNCg0KRXZlbnQgTm90aWZpY2F0aW9uICBMRkJzZWxlY3QgICAgICAgICAgIFJFUE9SVA0KDQpS ZWRpcmVjdCAgICAgICAgICAgIFJlZGlyZWN0ICAgICAgICAgICAgbm9uZQ0KDQpIZWFydGJlYXQg ICAgICAgICAgIE5vbmUgICAgICAgICAgICAgICAgbm9uZQ0KDQoNCkkgaGF2ZW4ndCBtb2RpZmll ZCBhbnkgdGV4dCByZWxhdGVkIHRvIEFDSywgaG9wZSB0byBkbyBpdCBhZnRlciB0aGUgaXNzdWUg cmVzb2x2ZS4gUGxzIGFsc28gY29tbWVudCBvbiB0aGlzIGlzc3VlLg0KDQpUaGFua3MsDQpXZWlt aW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiV2FuZyxXZWltaW5n IiA8d213YW5nQG1haWwuempnc3UuZWR1LmNuPg0KVG86IDxGT1JDRVNAUEVBQ0guRUFTRS5MU09G VC5DT00+DQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDI1LCAyMDA1IDEyOjA1IEFNDQpTdWJqZWN0 OiBSZTogW0lzc3VlIDU3XSBJbmNvbnNpc3RlbnQgb3BlcmF0aW9uIHR5cGVzDQoNCg0KPiBKYW1h bCwgSG9ybXV6ZCwgYW5kIGFsbCwNCj4gDQo+IEJhc2VkIG9uIHRoaXMgSmFtYWwncyBhbmQgbGFz dCBSb2JlcnQncyBjb21tZW50cywgY2FuIHdlIHJlYWNoIGFuIGFncmVlbWVudA0KPiBhcyBiZWxv dzoNCj4gDQo+IDEuIEFzc29jaWF0aW9uLXNldHVwIG1lc3NhZ2Ugd2l0aCBSRVBPUlQgb3BlcmF0 aW9uIFRMVi4NCj4gMi4gQXNzb2NpYXRpb24tc2V0dXAgcmVzcG9uc2UgbWVzc2FnZSB3aXRob3V0 IG9wZXJhdGlvbiBmb2xsb3dlZCwgYnV0IHdpdGggYQ0KPiBUTFYgZm9sbG93ZWQgdG8gcmV0dXJu IHJlc3VsdCBvbmx5KG5vdGUgbm90IGEgUkVTVUxULVRMViBpbiBQQVRILURBVEEpLiBXZQ0KPiBj YW4gbmFtZSB0aGUgVExWIGFzIHNvbWV0aGluZyBsaWtlIEFTUnJlc3VsdC4NCj4gMy4gQXNzb2Np YXRpb24tdGVhcmRvd24gbWVzc2FnZSB3aXRoIGEgVExWIHRvIHNob3cgcmVhc29uLCBhcyBURUFy ZWFzb24NCj4gKG5vdGUgd2UgaGF2ZSBhbHJlYWR5IGhhZCB0aGUgVExWKQ0KPiANCj4gSW4gdGhp cyB3YXksIGF0IHRoZSBtZXNzYWdlIGJvZHkgZmlyc3QgbGV2ZWwsIHdlIGhhdmUgdGhyZWUgVExW czoNCj4gTEZCc2VsZWN0DQo+IEFTUnJlc3VsdA0KPiBURUFyZWFzb24NCj4gDQo+IHRoYW5rcywN Cj4gV2VpbWluZw0KPiANCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAi SmFtYWwgSGFkaSBTYWxpbSIgPGhhZGlAem55eC5jb20+DQo+IFRvOiA8Rk9SQ0VTQFBFQUNILkVB U0UuTFNPRlQuQ09NPg0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjMsIDIwMDUgMTA6MjkgUE0N Cj4gU3ViamVjdDogUmU6IFtJc3N1ZSA1N10gSW5jb25zaXN0ZW50IG9wZXJhdGlvbiB0eXBlcw0K PiANCj4gDQo+ID4gT24gVHVlLCAyMDA1LTIzLTA4IGF0IDAxOjU3ICswODAwLCBXZWltaW5nIFdh bmcgd3JvdGU6DQo+ID4NCj4gPiA+IEVWRU5ULU5PVElGSUNBVElPTiBtZXNzYWdlOg0KPiA+ID4g IFJlcG9ydA0KPiA+ID4gW1dlaW1pbmddVXBkYXRlZC4gSXMgZ29pbmcgdG8gY29tcGxldGVseSBy ZW1vdmUgdGhlIHNlY3Rpb24gb2YgZXZlbnQNCj4gbm90aWZpY2F0aW9uDQo+ID4gPiByZXNwb25z ZT8NCj4gPiA+DQo+ID4NCj4gPiBMZXRzIHJldmlldyBhZnRlciB5b3UgY29tcGxldGUgeW91ciB1 cGRhdGUuDQo+ID4NCj4gPiA+IEFTU09DSUFUSU9OLVNFVFVQIG1lc3NhZ2U6DQo+ID4gPiAgR2V0 LXJlc3BvbnNlIChvcHRpb25hbCwgdXNlZCB0byBhZHZlcnRpc2UgZmllbGRzIGZyb20gdGhlIEZF IExGQg0KPiA+ID4gYW5kL29yIEZFIFByb3RvY29sIExGQiBpbiBhbiB1bnNvbGljaXRlZCBtYW5u ZXIpDQo+ID4gPg0KPiA+ID4gW1dlaW1pbmddaGF2ZW4ndCBtYWRlIGNoYW5nZXMuIFF1ZXN0aW9u czoNCj4gPiA+IERvIHdlIHJlYWxseSBuZWVkIGFuIG9wZXJhdGlvbiBpbiB0aGUgYXNzb2NpYXRp b24gc2V0dXAgbWVzc2FnZT8gSXQgd2lsbA0KPiBtYWtlDQo+ID4gPiBmbG9vZGluZyBhdHRhY2sg bW9yZSBlYXN5LCBJIHRoaW5rLiBXaHkgZG9uJ3Qgd2UgbGV0IENFIGxhdGVyIHRvIHF1ZXJ5DQo+ IHRoZW4/DQo+ID4gPg0KPiA+DQo+ID4gSSB0aGluayBtYWtpbmcgaXQgb3B0aW9uYWwgaXMgZmlu ZS4gT3B0aW9uYWxseSBpdCBjYW4gYmUgdXNlZCB0byBjdXQNCj4gPiBkb3duIG9uIHRoZSBudW1i ZXIgb2YgbWVzc2FnZXMgaXNzdWVkLg0KPiA+DQo+ID4gPiBBU1NPQ0lBVElPTi1TRVRVUC1SRVNQ T05TRSBtZXNzYWdlOg0KPiA+ID4gIFNldCAob3B0aW9uYWwsIG9ubHkgdG8gc2V0IGZpZWxkcyBp biB0aGUgRkUgTEZCIGFuZC9vciBGRSBQcm90b2NvbCBMRkIpDQo+ID4gPiBbV2VpbWluZ11IYXZl bid0IG1hZGUgY2hhbmdlcy4gUXVlc3Rpb25zOg0KPiA+ID4gRG9lcyB0aGlzIHJlYWxseSBtZWFu IHdlIGFsbG93IGEgU0VUIG9wZXJhdGlvbiB0aGF0IG5ldmVyIGJlIGFibGUgdG8gZ2V0DQo+IFNF VA0KPiA+ID4gcmVzcG9uc2U/IFdoeSBkb24ndCB3ZSB1c2UgY29uZmlnIG1lc3NhZ2UgdG8gU0VU IHRoZW4/DQo+ID4NCj4gPiBJIHRoaW5rIHRoZSBjaGFsbGVuZ2UgaW4gdGhlIG5hbWluZyBjb252 ZW50aW9uIGFzIHdlIGRpc2N1c3NlZCBpbiB0aGUNCj4gPiBtZWV0aW5nIGlzIHRoYXQgQ29uZmln IGdvZXMgZnJvbSBDRS0+RkUgYW5kIHJlc3BvbnNlIGdvZXMgYmFjay4NCj4gPiBIb3dldmVyIHlv dSBkbyBicmluZyB1cCBhIGdvb2QgcG9pbnQ6IHRoZSBDRSB3b3VsZCBuZWVkIHRvIGtub3cgaWYg dGhlDQo+ID4gU0VUIHdhcyBzdWNjZXNzZnVsIG9yIG5vdC4gQSBHRVQgZm9sbG93aW5nIHRoZSBT RVQgc2hvdWxkIGJlIHN1ZmZpY2llbnQuDQo+ID4gV2hpY2ggYWN0dWFsbHkgaW52YWxpZGF0ZXMg dGhlIG5lZWQgdG8gU0VUIGluIHRoZSBBU1NPQ0lBVElPTi1TRVRVUA0KPiA+IG1lc3NhZ2Ugc2lu Y2UgZXZlbnR1YWxseSB0aGUgbnVtYmVyIG9mIG1lc3NhZ2VzIGlzIGdvaW5nIHRvIGJlDQo+ID4g ZXF1aXZhbGVudC4gVGhvdWdodHM/DQo+ID4NCj4gPiBjaGVlcnMsDQo+ID4gamFtYWw= ------=_NextPart_000_0023_01C5AA9C.7596E2D0 Content-Type: text/plain; name="MsgUpdate.txt" Content-Disposition: attachment; filename="MsgUpdate.txt" Content-Transfer-Encoding: quoted-printable 6.1.1.1.5 LFB select TLV The LFB select TLV is an instance of TLV defined in Section 5.2. The definition is as below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D LFBselect | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 Type: The type of the TLV is "LFBselect" Length: Length of the TLV including the T and L fields, in bytes. LFB Class ID: This field uniquely recognizes the LFB class/type. LFB Instance ID: This field uniquely identifies the LFB instance. Operation TLV: It describes an operation nested in the LFB select TLV. Note that usually there SHOULD be at least one Operation TLV present for an LFB select TLV, but for Association Setup Message defined in Section 6.4.1, Operation TLV is totally optional, therefore there might be no any Operation TLV followed in the LFB select TLV there. Doria (Ed.), et al. Expires February 27, 2006 [Page 34] =0C Internet-Draft ForCES August 2005 6.1.1.1.6 Operation TLV The Operation TLV is an instance of TLV Idefined in Section 5.2. It is assumed that specific operations are identified by the Type code of the TLV. Definitions for individual Types of operation TLVs are in corresponding message description sections followed. ......... 6.4 Association Messages The ForCES Association messages are used to establish and teardown Doria (Ed.), et al. Expires February 28, 2006 [Page 43] =0C Internet-Draft ForCES August 2005 associations between FEs and CEs. 6.4.1 Association Setup Message This message is sent by the FE to the CE to setup a ForCES association between them. This message could also be used by CEs to join a ForCES NE, however CE-to-CE communication is not covered by this protocol. Message transfer direction: FE to CE Message Header: The Message Type in the header is set MessageType=3D 'AssociationSetup'. The ACK flag in the header is ignored, because the setup message will always expect to get a response from the message receiver (CE) whether the setup is successful or not. The Src ID (FE ID) may be set to O in the header which means that the FE would like the CE to assign a FE ID for the FE in the setup response message. Message body: The association setup message body optionally consist of one or more LFB select TLV as described in Section 6.1.1.1.5. The association setup message only operates toward the FE Object and FE Protocol LFBs, therefore, the LFB class ID in the LFB select TLV only points to these two kinds of LFBs. There is only one FE object LFB and one FE protocol LFB per FE, therefore, the LFB instance IDs for the FE object LFB and the FE protocol LFB are usually assigned to the value 0x1. The Operation TLV in the LFB select TLV is defined as a 'REPORT' operation. More than one attribute may be announced in this message using REPORT operation to let the FE declare its configuration parameters in an unsolicited manner. These may contain attributes like the Heart Beat Interval parameter, etc. The Operation TLV for event notificationis is defined below. Operation TLV for Association Setup: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D REPORT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV for REPORT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Doria (Ed.), et al. Expires February 28, 2006 [Page 44] =0C Internet-Draft ForCES August 2005 Type: Only one operation type is defined for the association setup message: Type =3D "REPORT" --- this type of operation is for FE to report something to CE. PATH-DATA-TLV for REPORT: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The PATH-DATA-TLV for REPORT operation MAY contain DATARAW-TLV(s) but SHALL NOT contain any RESULT-TLV in the data format. The RESULT-TLV is defined in Section 6.1.1.1.7 and the DATARAW-TLV is defined in Section 6.1.1.1.8. To better illustrate the above PDU format, we show a tree structure for the format as below: main hdr (eg type =3D Association setup) | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D FE object | | | | | +-- LFBInstance =3D 0x1 | | +--- T =3D LFBselect | +-- LFBCLASSID =3D FE Protocol object | | +-- LFBInstance =3D 0x1 | +-- Path-data to one or more attibutes including suggested HB parameters Figure 15 6.4.2 Association Setup Response Message This message is sent by the CE to the FE in response to the Setup message. It indicates to the FE whether the setup is successful or not, i.e. whether an association is established. Doria (Ed.), et al. Expires February 28, 2006 [Page 45] =0C Internet-Draft ForCES August 2005 Message transfer direction: CE to FE Message Header: The Message Type in the header is set MessageType=3D 'AssociationSetupResponse'. The ACK flag in the header is always ignored, because the setup response message will never expect to get any more response from the message receiver (FE). The Dst ID in the header will be set to some FE ID value assigned by the CE if the FE had requested that in the setup message (by SrcID =3D = 0). Message body: The association setup response message body only consists of one TLV, the Association Result TLV, the format of which is as follows: is: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D ASRresult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Setup Result | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (16 bits): The type of the TLV is "ASRresult". Length (16 bits): Length of the TLV including the T and L fields, in bytes. Association Setup Result (32 bits): This indicates whether the setup msg was successful or whether the FE request was rejected by the CE. the defined values are: 0 =3D success 1 =3D FE ID invalid 2 =3D too many associations 3 =3D permission denied 6.4.3 Association Teardown Message This message can be sent by the FE or CE to any ForCES element to end its ForCES association with that element. Doria (Ed.), et al. Expires February 28, 2006 [Page 46] =0C Internet-Draft ForCES August 2005 Message transfer direction: CE to FE, or FE to CE (or CE to CE) Message Header: The Message Type in the header is set MessageType=3D "AssociationTeardown". The ACK flag in the header is always ignored, because the teardown message will never expect to get any response from the message receiver. Message Body: The association teardown message body only consists of one TLV, the Association Teardown Reason TLV, the format of which is as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D ASTreason | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Teardown Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (16 bits): The type of the TLV is "ASTreason". Length (16 bits): Length of the TLV including the T and L fields, in bytes. Teardonw Reason (32 bits): This indicates the reason why the association is being terminated. Several reason codes are defined as follows. 0 - normal teardown by administrator 1 - error - loss of heartbeats 2 - error - out of bandwidth 3 - error - out of memory 4 - error - application crash 255 - error - other or unspecified 6.5 Configuration Messages The ForCES Configuration messages are used by CE to configure the FEs in a ForCES NE and report the results back to the CE. Doria (Ed.), et al. Expires February 28, 2006 [Page 47] =0C Internet-Draft ForCES August 2005 6.5.1 Config Message This message is sent by the CE to the FE to configure LFB attributes in the FE. This message is also used by the CE to subscribe/ unsubscribe to LFB events. As usual, a config message is composed of a common header followed by a message body that consists of one or more TLV data format. Detailed description of the message is as below. Message transfer direction: CE to FE Message Header: The Message Type in the header is set MessageType=3D 'Config'. = The ACK flag in the header is can be used by the CE to turn off any response from the FE. The default behavior is to turn on the ACK to get the config response from the FE. (this paragraph needs to be modified) Message body: The config message body MUST consist of at least one LFB select TLV as described in Section 6.1.1.1.5. The Operation TLV in the LFB select TLV is defined below. Operation TLV for Config: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: The operation type for config message. two types of operations for the config message are defined: Type =3D "SET" --- this operation is to set LFB attributes Type =3D "DEL" --- this operation to delete some LFB attributes PATH-DATA-TLV: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The restriction on the use of PATH-DATA-TLV for SET operation is, it SHALL NOT contain any RESULT-TLV. The Doria (Ed.), et al. Expires February 28, 2006 [Page 48] =0C Internet-Draft ForCES August 2005 restriction on the use of PATH-DATA-TLV for DEL operation is it SHALL NOT contain any DATARAW-TLV and any RESULT-TLV. The RESULT-TLV is defined in Section 6.1.1.1.7 and the DATARAW-TLV is defined in Section 6.1.1.1.8. *Note: For Event subscription, the events will be defined by the individual LFBs. To better illustrate the above PDU format, we show a tree structure for the format as below: main hdr (eg type =3D config) | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D target LFB class | | | | | +-- LFBInstance =3D target LFB instance | | | | | +-- T =3D operation { SET } | | | | | +-- // one or more path targets | | // associated with DATARAW-TLV(s) | | | +-- T =3D operation { DEL } | | | | | +-- // one or more path targets 6.5.2 Config Response Message This message is sent by the FE to the CE in response to the Config message. It indicates whether the Config was successful or not on the FE and also gives a detailed response regarding the configuration result of each attribute. Message transfer direction: FE to CE Message Header: The Message Type in the header is set MessageType=3D 'Config Response'. The ACK flag in the header is always ignored, because the config response message will never expect to get any more Doria (Ed.), et al. Expires February 28, 2006 [Page 49] =0C Internet-Draft ForCES August 2005 response from the message receiver (CE). The Correlator field in the header MUST keep the same as that of the config message to be responded, so that the config message sender can keep track of the response. Message body: TThe config message body MUST consist of at least one LFB select TLV as described in Section 6.1.1.1.5. The Operation TLV in the LFB select TLV is defined below. Operation TLV for Config Response: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: The operation type for config response message. Two types of operations for the config response message are defined: Type =3D "SET-RESPONSE" --- this operation is for the response of SET operation of LFB attributes Type =3D "DEL-RESPONSE" --- this operation is for the response of DELete operation of LFB attributes PATH-DATA-TLV: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The restriction on the use of PATH-DATA-TLV for SET- RESPONSE operation is it MUST contain RESULT-TLV(s). The restriction on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also MUST contain RESULT-TLV(s). The RESULT-TLV is defined in Section 6.1.1.1.7. 6.6 Query Messages The ForCES query messages are used by the CE to query LFBs in the FE for informations like LFB attributes, capabilities, statistics, etc. Query Messages include the Query Message and the Query Response Message. 6.6.1 Query Message As usual, a query message is composed of a common header and a Doria (Ed.), et al. Expires February 28, 2006 [Page 50] =0C Internet-Draft ForCES August 2005 message body that consists of one or more TLV data format. Detailed description of the message is as below. Message transfer direction: from CE to FE. Message Header: The Message Type in the header is set to MessageType=3D 'Query'. The ACK flag in the header SHOULD be set 'ACKAll', meaning a full response for a query message is always expected. If the ACK flag is set other values, the meaning of the flag will then be ignored, and a full response will still be returned by message receiver. Message body: The query message body MUST consist of at least one LFB select TLV as described in Section 6.1.1.1.5. The Operation TLV in the LFB select TLV is defined below. Operation TLV for Query: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D GET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV for GET | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21 Type: The operation type for query. One operation type is defined: Type =3D "GET" --- this operation is to request to get LFB attributes. PATH-DATA-TLV for GET: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The restriction on the use of PATH-DATA-TLV for GET operation is it SHALL NOT contain any DATARAW-TLV and RESULT-TLV in the data format. To better illustrate the above PDU format, we show a tree structure for the format as below: Doria (Ed.), et al. Expires February 28, 2006 [Page 51] =0C Internet-Draft ForCES August 2005 main hdr (type =3D Query) | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D target LFB class | | | | | +-- LFBInstance =3D target LFB instance | | | | | +-- T =3D operation { GET } | | | | | +-- // one or more path targets | | | +-- T =3D operation { GET } | | | | | +-- // one or more path targets | | Figure 22 6.6.2 Query Response Message When receiving a query message, the receiver should process the message and come up with a query result. The receiver sends the query result back to the message sender by use of the Query Response Message. The query result can be the information being queried if the query operation is successful, or can also be error codes if the query operation fails, indicating the reasons for the failure. A query response message is also composed of a common header and a message body consists of one or more TLVs describing the query result. Detailed description of the message is as below. Message transfer direction: from FE to CE. Message Header: The Message Type in the header is set to MessageType=3D 'QueryResponse'. The ACK flag in the header SHOULD be set 'NoACK', meaning no further response for a query response message is expected. If the ACK flag is set other values, the meaning of the flag will then be ignored. The Correlator field in the header MUST keep the same as that of the query message to be responded, so that the query message sender can keep track of the Doria (Ed.), et al. Expires February 28, 2006 [Page 52] =0C Internet-Draft ForCES August 2005 response. Message body: The query response message body MUST consist of at least one LFB select TLV as described in Section 6.1.1.1.5. The Operation TLV in the LFB select TLV is defined below. Operation TLV for Query Response: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D GET-RESPOSE | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV for GET-RESPONSE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23 Type: The operation type for query response. One operation type is defined: Type =3D "GET-RESPONSE" --- this operation is to response = to get operation of LFB attributes. PATH-DATA-TLV for GET-RESPONSE: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The restriction on the use of PATH-DATA-TLV for GET- RESPONSE operation is it MAY contain DATARAW-TLV(s) and/or RESULT-TLV(s) in the data format. The RESULT-TLV is defined in Section 6.1.1.1.7 and the DATARAW-TLV is defined in Section 6.1.1.1.8. 6.7 Event Notification Message Event Notification Message is used by FE to asynchronously notify CE of events that happen in the FE. All events happen in FE are subscribable by CE. A config message is used by CE to subscribe/unsubscribe for an event in FE. To subscribe to an event is usually by specifying to the path of such an event as described by FE-Model and defined by LFB library. As usual, an Event Notification Message is composed of a common header and a message body that consists of one or more TLV data format. Detailed description of the message is as below. Doria (Ed.), et al. Expires February 28, 2006 [Page 53] =0C Internet-Draft ForCES August 2005 Message Transfer Direction: FE to CE Message Header: The Message Type in the message header is set to MessageType =3D 'EventNotification'. Because we do not expect any response for event notification, the ACK flag in the message header SHOULD be reasonably set to 'NoACK'. If the ACK flag is set to any other values, the meaning of the flag SHOULD then be ignored. Message Body: The event notification message body MUST consist of at least one LFB select TLV as described in Section 6.1.1.1.5. The Operation TLV in the LFB select TLV is defined below. Operation TLV for Event Notification: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D REPORT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH-DATA-TLV for REPORT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Only one operation type is defined for the event notification message: Type =3D "REPORT" --- this type of operation is for FE to report something to CE. PATH-DATA-TLV for REPORT: This is generically a PATH-DATA-TLV format that has been defined in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF definition. The PATH-DATA-TLV for REPORT operation MAY contain DATARAW-TLV(s) but SHALL NOT contain any RESULT-TLV in the data format. To better illustrate the above PDU format, we show a tree structure for the format as below: Doria (Ed.), et al. Expires February 28, 2006 [Page 54] =0C Internet-Draft ForCES August 2005 main hdr (type =3D Event Notification) | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D target LFB class | | | | | +-- LFBInstance =3D target LFB instance | | | | | +-- T =3D operation { REPORT } | | | | | +-- // one or more path targets | | // associated with DATARAW-TLV(s) | +-- T =3D operation { REPORT } | | | | | +-- // one or more path targets | | // associated with DATARAW-TLV(s) Figure 25 6.8 Packet Redirect Message Packet redirect message is used to transfer data packets between CE and FE. Usually these data packets are IP packets, though they may sometimes associated with some metadata generated by other LFBs in the model, or they may occasionally be other protocol packets, which usually happen when CE and FE are jointly implementing some high- touch operations. Packets redirected from FE to CE are the data packets that come from forwarding plane, and usually are the data packets that need high-touch operations in CE,or packets for which the IP destination address is the NE. Packets redirected from CE to FE are the data packets that come from the CE and are decided by CE to put into forwarding plane in FE. Supplying such a redirect path between CE and FE actually leads to a possibility of this path being DoS attacked. Attackers may maliciously try to send huge spurious packets that will be redirected by FE to CE, making the redirect path been congested. ForCES protocol and the TML layer will jointly supply approaches to prevent such DoS attack. To define a specific 'Packet Redirect Message' makes TML and CE able to distinguish the redirect messages from other ForCES protocol messages. By properly configuring related LFBs in FE, a packet can also be Doria (Ed.), et al. Expires February 28, 2006 [Page 55] =0C Internet-Draft ForCES August 2005 mirrored to CE instead of purely redirected to CE, i.e., the packet is duplicated and one is redirected to CE and the other continues its way in the LFB topology. The Packet Redirect Message data format is formated as follows: Message Direction: CE to FE or FE to CE Message Header: The Message Type in the header is set to MessageType=3D 'PacketRedirect'. The ACK flags in the header SHOULD be set 'NoACK', meaning no response is expected by this message. If the ACK flag is set other values, the meanings will be ignored. Message Body: Consists of (at least) one or more than one TLV that describes the packet redirection. The TLV is specifically a Redirect TLV (with the TLV Type=3D"Redirect"). Detailed data format of a Redirect = TLV for packet redirect message is as below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D Redirect | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Class ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LFB Instance ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redirect Data TLV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 26 LFB class ID: There are only two possible LFB classes here, the 'RedirectSink' LFB or the 'RedirectSource' LFB[FE-MODEL]. If the message is from FE to CE, the LFB class should be 'RedirectSink'. If the message is from CE to FE, the LFB class should be 'RedirectSource'. Doria (Ed.), et al. Expires February 28, 2006 [Page 56] =0C Internet-Draft ForCES August 2005 Instance ID: Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. Meta Data TLV: This is a TLV that specifies meta-data associated with followed redirected data. The TLV is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D META-DATA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ILV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ILV | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27 Meta Data ILV: This is an Identifier-Length-Value format that is used to describe one meta data. The ILV has the format as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Meta Data Value | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where, Meta Data ID is an identifier for the meta data, which is statically assigned by the LFB definition. This actually implies a Meta Data ID transcoding mechanism may be necessary if a metadata traverses several LFBs while these LFBs define the metadata with different Meta Data IDs. Usually there are two meta data that are necessary for CE-FE redirect operation. One is the redirected data type (e.g., IP packet, TCP packet, or UDP Packet). For an FE->CE redirect operation, redirected packet type meta data is usually a meta data specified by a Classifier LFB that filter out redirected packets from packet stream and sends the packets to Redirect Sink LFB. For an CE->FE redirect operation, the redirected packet type meta Doria (Ed.), et al. Expires February 28, 2006 [Page 57] =0C Internet-Draft ForCES August 2005 data is usually directly generated by CE. Another meta data that should be associated with redirected data is the port number in a redirect LFB. For a RedirectSink LFB, the port number meta data tells CE from which port in the lFB the redirected data come. For a RedriectSource LFB, via the meta data, CE tells FE which port in the LFB the redirected data should go out. Redirect Data TLV This is a TLV describing one packet of data to be directed via the redirect operation. The TLV format is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D REDIRECTDATA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redirected Data | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Redirected Data: This field presents the whole packet that is to be redirected. The packet should be 32bits aligned. 6.9 Heartbeat Message The Heartbeat (HB) Message is used for one ForCES element (FE or CE) to asynchronously notify one or more other ForCES elements in the same ForCES NE on its liveness. A Heartbeat Message is sent by a ForCES element periodically. The time interval for FE to send heartbeats is managed as an attribute of FE protocol LFB, and can be set by CE via a config message. A little different from other protocol messages, a Heartbeat message is only composed of a common header, with the message body left empty. Detailed description of the message is as below. Message Transfer Direction: FE to CE, or CE to FE Message Header: The Message Type in the message header is set to MessageType =3D 'Heartbeat'. The ACK flag in the header SHOULD be set to 'NoACK', meaning no response from receiver(s) is expected by the message sender. Other values of the ACK flag will always be ignored by the message receiver. Doria (Ed.), et al. Expires February 28, 2006 [Page 58] =0C Internet-Draft ForCES August 2005 Message Body: The message body is empty for the Heartbeat Message. ------=_NextPart_000_0023_01C5AA9C.7596E2D0-- From owner-forces@PEACH.EASE.LSOFT.COM Sat Aug 27 23:13:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9DbX-0000Jm-06 for forces-archive@megatron.ietf.org; Sat, 27 Aug 2005 23:13:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12457 for ; Sat, 27 Aug 2005 23:13:04 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9DcT-0002Bi-Hy for forces-archive@IETF.ORG; Sat, 27 Aug 2005 23:14:12 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010DA6AD@cherry.ease.lsoft.com>; Sat, 27 Aug 2005 23:12:37 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84121847 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 27 Aug 2005 23:12:37 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sat, 27 Aug 2005 23:12:33 -0400 Received: from [220.192.1.226] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Sun, 28 Aug 2005 11:43:03 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> <003a01c5a7a2$63e3c820$1f12fea9@wwm1> <6.2.1.2.0.20050823105005.02d046b8@localhost> <018401c5a8bc$8f976970$c77cc0dc@WwmLapSamsung> <6.2.1.2.0.20050824165452.02d3cba0@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <008f01c5ab7d$328006c0$1f06c0dc@WwmLapSamsung> Date: Sun, 28 Aug 2005 11:03:10 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 34] Header flags To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Joel, After some consideration, I think this ACK flag is for acknowledgement rather than for response control. It is only applied to Config message (note not only SET by also DEL) because other messages have to be constantly defined for there acknowledgement requirements. While for config message, we use such flag only try to give the message acknowledge with some choices like" If you can do this, please let me know", or "If you cannot do this, please let me know". Now, if we then put such flag in Operation TLVs in config message, we may not able to reach the goal above, because it is still vague if a Config Response is required or not when we set all Op TLVs insde with NoACK(NoResponse). As a result, I think to consider a flag in every Operation TLV for response control may still be an issue separated to the ACK flag used in the header. One proposed solution for the ACK flag is, I suppose, still put it in the header, with the define that the flag is only applied to Config message. For all other messages, the flag is ignored, and for all other messages, whether responses are required are expicitly defined in the message definitions. In this way, I can just save the paragraph that describe the individual ACK flag usage for all other messages. Any thoughts? Thanks, Weiming ----- Original Message ----- From: "Joel M. Halpern" To: "Wang,Weiming" ; Sent: Thursday, August 25, 2005 4:55 AM Subject: Re: [issue 34] Header flags > Looking at your more recent not, it seems that these flags only apply to > the SET (Config) Request). If that is so, then they belong in the SET > Operation TLV, or in the format of the Config message. > > Yours, > Joel M. Halpern > > At 10:09 AM 8/24/2005, Wang,Weiming wrote: > >Joel, > > > >Pls allow me to change the titile to issue 34. > > > >I agree with you some what. I also noticed that actualy the ACK flag is only > >useful for Config message after we removed event response function. > > > >The question is, if we don't put it in the common header, as a global flag > >for this message, where can we put then and how we can make it specifically > >for config message only? > > > >I thought of puting the flag in an LFBselect TLV, the operation TLV, (or > >even in a Path flag). In this way, it makes the flag only restricted to the > >LFB selector, the operation, (or even the path). It means some LFBselect > >or operations inside wants response, while others may not. I didn't think it > >further. > > > >Thanks, > >Weiming > > > >----- Original Message ----- > >From: "Joel M. Halpern" > > > > > The text below is an excerpt from a proposed methodology for a particular > > > PL message. > > > It is about event notification messages, and the fact that no responses > >are > > > expected to them. (They are transmitted reliably, and the FE which sends > > > them has no use for an ACK. > > > > > > However, if we are going to take this approach, we render the ack flags > > > much more complex. We should either define the ack flags globally and use > > > them everywhere, or we should not have them in the common message header. > > > If we choose to keep them, then a message receiver should be prepared to > > > generate an ACK for ANY message it receives, if the flags tell it to do > >so. > > > > > > Yours, > > > Joel M. Halpern > > > > > > At 01:20 AM 8/23/2005, Weiming Wang wrote: > > > > header SHOULD be reasonably set to 'NoACK'. If the ACK flag is > > > > set to any other values, the meaning of the flag will then be > > > > ignored. > From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 05:13:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9JE3-00060J-94 for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 05:13:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06136 for ; Sun, 28 Aug 2005 05:13:13 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9JF8-0005uI-Ih for forces-archive@IETF.ORG; Sun, 28 Aug 2005 05:14:24 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.010DA943@cherry.ease.lsoft.com>; 28 Aug 2005 5:13:12 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84131287 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 05:13:11 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 05:13:09 -0400 Received: from [220.192.1.52] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Sun, 28 Aug 2005 17:23:37 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> Date: Sun, 28 Aug 2005 16:42:13 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 36] FE/CE failover To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Jamal, I understand the two policies default values a little differently regarding the trustness. For FE (failover-then-)restart policy, we set the default policy being to start from scratch. This means CE does not trust FE after FE has been failover, therfore does not let it restart from other intermediate state. For CE failover plicy, we set the default policy being to continue running. This means CE trust the FE for its running when it has lost association with the CE. The reason the CE can trust the FE here is because the FE still work properly. I don't think it leads to some contradictory. I have to say the name 'FE restart policy' may not properly describe the case here. I prefer it as the name 'FE failover-then-restart policy' for more fitness. Not sure if it makes sense or not. Thanks, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: [Issue 36] FE/CE failover > Weiming, > Dont close it yet since I am not sure if i commented on this or not: > a) Default behaviors for the two restarts are contradictory. If the > Default FE restart behavior is to start from scratch, that implies an > element of trust involved i.e the FE doesnt trust the state it has > during the disappearance of the CE. OTOH, the CE restart default seems > to say the FE should continue to use the policies it has on > disappearance of the CE which implies it trusts the state it has as > being valid ;-> Is it fair to say we need to choose similar default > policies? > b) Should we enumerate all possibilities in the text for the two restart > policies? > > cheers, > jamal > > On Wed, 2005-24-08 at 19:51 +0800, Wang,Weiming wrote: > > Hi, > > > > The draft has been updated in Section 6.2.1(FE Protocol LFB) according to > > the text proposed below. > > > > The issue 36 can be closed! > [..] > > > I'm based on you two and propose the following: > > > > > > * FE restart policy - This specifies the behavior of the FE > > > during a restart. For example, this would specify if the FE > > > should start from scratch or from a default state after a CE > > > failure in the NE. Default value for this attribute should be to let the > > > FE to start from scratch. > > > > > > * CE failover policy - This specifies the behavior of the FE > > > during a CE failure and restart time interval. For example, > > > this would specify if the FE should continue running or stop > > > operation during a CE failure in the NE. Default value for this > > > attribute should be to let the FE to continue running. > > > > > > Comments please. > > > > > > Thanks, > > > Weiming From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 11:39:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9PFj-0002az-BV for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 11:39:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26136 for ; Sun, 28 Aug 2005 11:39:21 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9PGs-00079K-95 for forces-archive@IETF.ORG; Sun, 28 Aug 2005 11:40:35 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.010DAAB2@cherry.ease.lsoft.com>; 28 Aug 2005 11:39:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84166362 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 11:39:19 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 11:39:17 -0400 Received: from [220.207.85.67] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Mon, 29 Aug 2005 00:10:03 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> <1124807356.6579.13.camel@localhost.localdomain> <013501c5a8ab$7c380fd0$c77cc0dc@WwmLapSamsung> <1124896236.6300.18.camel@localhost.localdomain> <01e801c5a8c5$db97f5c0$c77cc0dc@WwmLapSamsung> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <019e01c5abe5$87905210$1f06c0dc@WwmLapSamsung> Date: Sun, 28 Aug 2005 22:27:42 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 45] Definition of inter-TML protocol level schemes To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Issue 45, the new text was already updated by Jamal in the previous version. can be closed. From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 11:39:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9PFw-0002kV-TA for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 11:39:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26147 for ; Sun, 28 Aug 2005 11:39:31 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9PH3-00079a-3q for forces-archive@IETF.ORG; Sun, 28 Aug 2005 11:40:46 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010DA9C4@cherry.ease.lsoft.com>; 28 Aug 2005 11:39:31 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84166366 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 11:39:31 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 11:39:30 -0400 Received: from [220.207.85.67] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Mon, 29 Aug 2005 00:10:13 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> <1124807356.6579.13.camel@localhost.localdomain> <013501c5a8ab$7c380fd0$c77cc0dc@WwmLapSamsung> <1124896236.6300.18.camel@localhost.localdomain> <01e801c5a8c5$db97f5c0$c77cc0dc@WwmLapSamsung> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <01a101c5abe5$8dfb14f0$1f06c0dc@WwmLapSamsung> Date: Sun, 28 Aug 2005 22:50:37 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 49] Sec 6.1.1.1.6 SET and GET Relationship To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Note sec 6.1.1.1.6 is now sec 6.1.1.1.9. The question raised by the issue has been solved. I just suggest to add a word 'whole' for the sentence and makes it as below: 2. When dumping a whole table in a GET, the GET-RESPONSE, merely editing the T to be SET will endup overwritting the (WHOLE) table. Jamal, just make a notice here that the SET-REPLACE TLV has been agreed to just SET. some of the text, like in the sec 6.1.1.1.9 and in the appendix examples, where SET-REPLACE may need modify to SET. I haven't made this change, leaving it for your turn may be better :) Thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 11:39:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9PFx-0002ku-T5 for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 11:39:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26150 for ; Sun, 28 Aug 2005 11:39:35 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9PH8-00079f-4n for forces-archive@IETF.ORG; Sun, 28 Aug 2005 11:40:50 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.010DAAE6@cherry.ease.lsoft.com>; 28 Aug 2005 11:39:37 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84166372 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 11:39:36 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 11:39:18 -0400 Received: from [220.207.85.67] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Mon, 29 Aug 2005 00:09:54 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> <003a01c5a7a2$63e3c820$1f12fea9@wwm1> <6.2.1.2.0.20050823105005.02d046b8@localhost> <018401c5a8bc$8f976970$c77cc0dc@WwmLapSamsung> <6.2.1.2.0.20050824165452.02d3cba0@localhost> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <019c01c5abe5$827d7e10$1f06c0dc@WwmLapSamsung> Date: Sun, 28 Aug 2005 19:38:00 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 43] Editorial- change GET to SET in section 6.5 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.7 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 was already fixted. can be closed. From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 11:41:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9PHw-0003Ah-4X for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 11:41:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26215 for ; Sun, 28 Aug 2005 11:41:37 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9PJ5-0007Cp-Cd for forces-archive@IETF.ORG; Sun, 28 Aug 2005 11:42:52 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010DAA55@cherry.ease.lsoft.com>; 28 Aug 2005 11:41:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84166407 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 11:41:33 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 11:41:24 -0400 Received: from [220.207.85.67] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Mon, 29 Aug 2005 00:11:16 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> <1124807356.6579.13.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <01a401c5abe5$b39da240$1f06c0dc@WwmLapSamsung> Date: Sun, 28 Aug 2005 23:24:48 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 53] How a path should be defined in Packet Redirect Message? To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea The issue was already solved by weiming's new text about Packet redirect msg in the previous version. The issue can be closed. Weiming From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 11:46:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9PMl-0004C4-2J for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 11:46:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26425 for ; Sun, 28 Aug 2005 11:46:36 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9PNv-0007KO-Ao for forces-archive@IETF.ORG; Sun, 28 Aug 2005 11:47:51 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010DA9CB@cherry.ease.lsoft.com>; 28 Aug 2005 11:46:38 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84166607 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 11:46:37 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 11:46:00 -0400 Received: from [220.207.85.67] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Mon, 29 Aug 2005 00:11:20 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> <1124807356.6579.13.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <01a501c5abe5$b575bda0$1f06c0dc@WwmLapSamsung> Date: Sun, 28 Aug 2005 23:28:49 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 54] correlator in the PL message header To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db This issue is totally a overlap of issue 47, which is now under discussion. This issue can be closed by only leaving issue 47. Weiming From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 11:56:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9PWQ-00060K-Lp for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 11:56:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26812 for ; Sun, 28 Aug 2005 11:56:36 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9PXa-0007YO-18 for forces-archive@IETF.ORG; Sun, 28 Aug 2005 11:57:51 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.010DAA3A@cherry.ease.lsoft.com>; 28 Aug 2005 11:56:36 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84166890 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 11:56:36 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 11:56:34 -0400 Received: from [220.207.85.67] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Mon, 29 Aug 2005 00:11:13 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00ea01c5a47c$97488760$9273c0dc@WwmLapSamsung> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <01a301c5abe5$b1ab6f30$1f06c0dc@WwmLapSamsung> Date: Sun, 28 Aug 2005 23:22:07 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 52] Association Setup. To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 I'v updated the whole text for Association Setup Message as shown in issue 57, by defining the (Optional) Operation TLV for Association Setup msg as REPORT. This issue can be closed if this propose can be agreed. Thanks, Weiming ----- Original Message ----- From: "Wang,Weiming" To: Sent: Friday, August 19, 2005 1:12 PM Subject: Re: [issue 52] Association Setup. > > Issue 52: Association Setup. Unsolicited information can be > transmitted > > in the Association Setup message from the FE, using GET-RESPONSE. CE > can > > set attributes with the Association Setup Response using SET. Accept. > > Updated in tracker. Need text for the draft. > > Hormuzd, > > Could you provide an updated text regarding this issue to let me put in? > Then we can close it. > > Thanks, > Weiming From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 12:00:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Pad-0006m5-42 for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 12:00:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26987 for ; Sun, 28 Aug 2005 12:00:56 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Pbi-0007dL-WA for forces-archive@IETF.ORG; Sun, 28 Aug 2005 12:02:11 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010DAA6C@cherry.ease.lsoft.com>; 28 Aug 2005 12:00:37 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84167042 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 12:00:37 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 12:00:36 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7SFIhXK022101; Sun, 28 Aug 2005 08:18:44 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1125244775.6422.70.camel@localhost.localdomain> Date: Sun, 28 Aug 2005 11:59:35 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [Issue 36] FE/CE failover Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit On Sun, 2005-28-08 at 16:42 +0800, Wang,Weiming wrote: > Jamal, > > I understand the two policies default values a little differently regarding > the trustness. > > For FE (failover-then-)restart policy, we set the default policy being to > start from scratch. This means CE does not trust FE after FE has been > failover, therfore does not let it restart from other intermediate state. > > For CE failover plicy, we set the default policy being to continue running. > This means CE trust the FE for its running when it has lost association with > the CE. The reason the CE can trust the FE here is because the FE still work > properly. > > I don't think it leads to some contradictory. > Ok, I think thats a good way to position it. Perhaps we should say that in the text. > I have to say the name 'FE restart policy' may not properly describe the > case here. I prefer it as the name 'FE failover-then-restart policy' for > more fitness. > > Not sure if it makes sense or not. > It does - maybe just leave it as is then with the explanation from above. I would have suggested "FE Failover-restart-policy" but then that would be misleading because this just describes how you restart and not necessarily that you are restarting because you have failed over. Again, I think we need to enumerate the possible (known) schemes. cheers, jamal > Thanks, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > Subject: Re: [Issue 36] FE/CE failover > > > > Weiming, > > Dont close it yet since I am not sure if i commented on this or not: > > a) Default behaviors for the two restarts are contradictory. If the > > Default FE restart behavior is to start from scratch, that implies an > > element of trust involved i.e the FE doesnt trust the state it has > > during the disappearance of the CE. OTOH, the CE restart default seems > > to say the FE should continue to use the policies it has on > > disappearance of the CE which implies it trusts the state it has as > > being valid ;-> Is it fair to say we need to choose similar default > > policies? > > b) Should we enumerate all possibilities in the text for the two restart > > policies? > > > > cheers, > > jamal > > > > On Wed, 2005-24-08 at 19:51 +0800, Wang,Weiming wrote: > > > Hi, > > > > > > The draft has been updated in Section 6.2.1(FE Protocol LFB) according > to > > > the text proposed below. > > > > > > The issue 36 can be closed! > > [..] > > > > I'm based on you two and propose the following: > > > > > > > > * FE restart policy - This specifies the behavior of the FE > > > > during a restart. For example, this would specify if the FE > > > > should start from scratch or from a default state after a CE > > > > failure in the NE. Default value for this attribute should be to let > the > > > > FE to start from scratch. > > > > > > > > * CE failover policy - This specifies the behavior of the FE > > > > during a CE failure and restart time interval. For example, > > > > this would specify if the FE should continue running or stop > > > > operation during a CE failure in the NE. Default value for > this > > > > attribute should be to let the FE to continue running. > > > > > > > > Comments please. > > > > > > > > Thanks, > > > > Weiming From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 12:01:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9PbL-0006qu-0U for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 12:01:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27022 for ; Sun, 28 Aug 2005 12:01:40 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9PcV-0007eJ-DG for forces-archive@IETF.ORG; Sun, 28 Aug 2005 12:02:55 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.010DAA2E@cherry.ease.lsoft.com>; 28 Aug 2005 12:01:42 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84167258 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 12:01:41 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 12:01:40 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7SFK5XK022118; Sun, 28 Aug 2005 08:20:07 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> <1124807356.6579.13.camel@localhost.localdomain> <013501c5a8ab$7c380fd0$c77cc0dc@WwmLapSamsung> <1124896236.6300.18.camel@localhost.localdomain> <01e801c5a8c5$db97f5c0$c77cc0dc@WwmLapSamsung> <01a101c5abe5$8dfb14f0$1f06c0dc@WwmLapSamsung> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1125244880.6422.72.camel@localhost.localdomain> Date: Sun, 28 Aug 2005 12:01:19 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 49] Sec 6.1.1.1.6 SET and GET Relationship Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <01a101c5abe5$8dfb14f0$1f06c0dc@WwmLapSamsung> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit On Sun, 2005-28-08 at 22:50 +0800, Wang,Weiming wrote: > Note sec 6.1.1.1.6 is now sec 6.1.1.1.9. > The question raised by the issue has been solved. I just suggest to add a > word 'whole' for the sentence and makes it as below: > > 2. When dumping a whole table in a GET, the GET-RESPONSE, merely editing > the T to be SET will endup overwritting the (WHOLE) table. > > Jamal, just make a notice here that the SET-REPLACE TLV has been agreed to > just SET. some of the text, like in the sec 6.1.1.1.9 and in the appendix > examples, where SET-REPLACE may need modify to SET. I haven't made this > change, leaving it for your turn may be better :) > Well, if we can tag it somewhere either in the text or tracker - that would make sure its not forgotten. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 12:04:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Pe7-0007HI-2O for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 12:04:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27149 for ; Sun, 28 Aug 2005 12:04:32 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9PfG-0007ia-G4 for forces-archive@IETF.ORG; Sun, 28 Aug 2005 12:05:47 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.010DABB6@cherry.ease.lsoft.com>; 28 Aug 2005 12:04:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84167405 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 12:04:32 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 12:04:30 -0400 Received: from [220.207.85.67] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Mon, 29 Aug 2005 00:10:10 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> <1124807356.6579.13.camel@localhost.localdomain> <013501c5a8ab$7c380fd0$c77cc0dc@WwmLapSamsung> <1124896236.6300.18.camel@localhost.localdomain> <01e801c5a8c5$db97f5c0$c77cc0dc@WwmLapSamsung> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <01a001c5abe5$8c479890$1f06c0dc@WwmLapSamsung> Date: Sun, 28 Aug 2005 22:30:01 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 48] Data Packing Rules: addressing tables To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Issue 48, Seems Jamal already updated with the text modification, not sure if enough or not. can be closed after Jamal's double check. From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 12:31:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Q4U-0005Rx-4C for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 12:31:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28528 for ; Sun, 28 Aug 2005 12:31:47 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Q5e-0008Tl-N6 for forces-archive@IETF.ORG; Sun, 28 Aug 2005 12:33:02 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010DA954@cherry.ease.lsoft.com>; 28 Aug 2005 12:31:49 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84169273 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 12:31:47 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 12:31:46 -0400 Received: from [220.207.85.67] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Mon, 29 Aug 2005 00:10:07 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> <1124807356.6579.13.camel@localhost.localdomain> <013501c5a8ab$7c380fd0$c77cc0dc@WwmLapSamsung> <1124896236.6300.18.camel@localhost.localdomain> <01e801c5a8c5$db97f5c0$c77cc0dc@WwmLapSamsung> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <019f01c5abe5$89fcbe30$1f06c0dc@WwmLapSamsung> Date: Sun, 28 Aug 2005 22:28:52 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 46] Up to 8 priorities supported by the TML To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Issue 46, I think Hormuzd has updated the text according to Joel's propose. can be closed after Hormuzd's double check. From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 12:44:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9QGr-000810-5U for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 12:44:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28910 for ; Sun, 28 Aug 2005 12:44:34 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9QHz-0000IJ-VQ for forces-archive@IETF.ORG; Sun, 28 Aug 2005 12:45:50 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.010DAAFE@cherry.ease.lsoft.com>; 28 Aug 2005 12:36:33 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84170574 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 12:36:20 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 12:35:02 -0400 Received: from [220.207.85.67] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Mon, 29 Aug 2005 00:09:59 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <019d01c5abe5$859fccb0$1f06c0dc@WwmLapSamsung> Date: Sun, 28 Aug 2005 22:26:01 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 44] FE, CE, and FE protocol LFBs To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Issue 44, the new text was already updated by Jamal in the previous version. can be closed. From owner-forces@PEACH.EASE.LSOFT.COM Sun Aug 28 13:30:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Qz0-0000Di-G5 for forces-archive@megatron.ietf.org; Sun, 28 Aug 2005 13:30:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00963 for ; Sun, 28 Aug 2005 13:30:13 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9R0A-0001QD-IP for forces-archive@IETF.ORG; Sun, 28 Aug 2005 13:31:27 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.010DAB13@cherry.ease.lsoft.com>; 28 Aug 2005 13:30:11 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84177178 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 28 Aug 2005 13:30:10 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Sun, 28 Aug 2005 13:30:08 -0400 Received: from [220.207.85.67] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Mon, 29 Aug 2005 00:10:17 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <001a01c5a3ff$6465ac60$9273c0dc@WwmLapSamsung> <6.2.1.2.0.20050818102932.02cc0d08@localhost> <00cd01c5a46f$72cdc420$9273c0dc@WwmLapSamsung> <1124807356.6579.13.camel@localhost.localdomain> <013501c5a8ab$7c380fd0$c77cc0dc@WwmLapSamsung> <1124896236.6300.18.camel@localhost.localdomain> <01e801c5a8c5$db97f5c0$c77cc0dc@WwmLapSamsung> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <01a201c5abe5$9002a4c0$1f06c0dc@WwmLapSamsung> Date: Sun, 28 Aug 2005 23:16:44 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 50] Fig.11 Sample operation layout: successive breakdown of the path-data To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Note the Fig.11 has been to Fig. 13. I think to modify the figure by adding some KEYs in the first two PATH-DATAs,as Robert suggested, may be a good way to solve the issue, which makes the figure more close to reality, I suppose. Jamal, could this issue be left for your turn? Thanks, Weiming From owner-forces@PEACH.EASE.LSOFT.COM Tue Aug 30 06:41:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA3YV-0005ou-D9 for forces-archive@megatron.ietf.org; Tue, 30 Aug 2005 06:41:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04056 for ; Tue, 30 Aug 2005 06:41:24 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA3Zt-0004yr-Sr for forces-archive@IETF.ORG; Tue, 30 Aug 2005 06:43:02 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.010DC71F@cherry.ease.lsoft.com>; Tue, 30 Aug 2005 6:41:09 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84336679 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 30 Aug 2005 06:41:08 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Tue, 30 Aug 2005 06:41:04 -0400 Received: from [220.192.119.94] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Tue, 30 Aug 2005 19:12:27 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> Date: Tue, 30 Aug 2005 18:31:19 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 36] FE/CE failover To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Jamal and Robert, We'v currently put the FE protocol LFB definitions in Appendix C. When going through current Section 6.2 (Core ForCES LFBs), I feel that we may need to make it clear how these two places address the LFBs separately. I'm not sure if now we follow the way that Section 6.2 only mentions the names (and the default value) for all attributes while detailed defintions are in the Appendix (or other document later when we decide). Anyway, I'd like to put the following text in the Section 6.2 for the FE/CE policy attributes first. If necessary, I hope Robert can move it to Appendix C during your turn of editing or manage it in other way, is it ok? * FE restart policy - This specifies the behavior of the FE during a FE restart. The restart may be from a FE failure or other reasons that have made FE down and then need to restart. 0(default) just restart the FE from scratch. In this case, the FE should start from pre- association phase definitely. 1 restart the FE from an intermediate state. In this case, the FE itself decides from which state it restarts. For example, if the FE still keeps enough infomation of pre-association phase after some failure, it then has the right just to start from post-associatin phase with this policy case. Others Reserved * CE failover policy - This specifies the behavior of the FE during a CE failure and restart time interval, or when the FE loses the CE association. A timeout parameter is associated with this attribute. (The default value for the timeout is set to 30 seconds). 0(default) The FE should continue running and do what it can even without an associated CE. This basically makes the FE support CE Graceful restart. Note that if the CE still has not been restarted or hasn't been associated back to the FE, after a time interval specified by the timeout parameter, the FE will go down completely. 1 FE should go down to stop functioning immediately. 2 FE should go inactive to temporarily stop functioning. If the CE still has not been restarted after a time interval of specified by the timeout parameter, the FE will go down completely. Others Reserved The reasons to set above policy values are some from the requirements from RFC3746 Section 4.3.1 (CE graceful restart) and Section 4.3.2 (FE restart). For FE restart policy, the text in Section 4.3.2 as below makes sence: When FE1 decides to rejoin again, or when it restarts again after the failure, FE1 needs to re-discover its master (CE). This can be achieved by several means. It may re-enter the pre-association phase and get that information from its FE manager. It may retrieve the previous CE information from its cache, if it can validate the information freshness. Once it discovers its CE, it starts message exchange with the CE to re-establish the association, as outlined in Figure 9, with the possible exception that it might be able to bypass the transport of the complete initial configuration. Suppose that FE1 still has its routing table and other state information from the last association. Instead of re-sending all the information, it may be able to use a more efficient mechanism to re-sync the state with its CE, if such a mechanism is supported by the ForCES Protocol. For example, CRC-32 of the state might give a quick indication of whether or not the state is in-sync with its CE. By comparing its state with the CE first, it sends an information update only if it is needed. The ForCES Protocol may choose to implement similar optimization mechanisms, but it may also choose not to, as this is not a requirement. For CE Failover policy, the following text in Section 4.3.1 makes sense: ForCES should be able to support a CE graceful restart easily. When the association is established the first time, the CE must inform the FEs what to do in the case of a CE failure. If graceful restart is not supported, the FEs may be told to stop packet processing all together if its CE fails. If graceful restart is supported, the FEs should be told to cache and hold on to its FE state, including the forwarding tables across the restarts. A timer must be included so that the timeout causes such a cached state to eventually expire. Those timers should be settable by the CE. Thanks, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > On Sun, 2005-28-08 at 16:42 +0800, Wang,Weiming wrote: > > Jamal, > > > > I understand the two policies default values a little differently regarding > > the trustness. > > > > For FE (failover-then-)restart policy, we set the default policy being to > > start from scratch. This means CE does not trust FE after FE has been > > failover, therfore does not let it restart from other intermediate state. > > > > For CE failover plicy, we set the default policy being to continue running. > > This means CE trust the FE for its running when it has lost association with > > the CE. The reason the CE can trust the FE here is because the FE still work > > properly. > > > > I don't think it leads to some contradictory. > > > > Ok, I think thats a good way to position it. Perhaps we should say that > in the text. > > > I have to say the name 'FE restart policy' may not properly describe the > > case here. I prefer it as the name 'FE failover-then-restart policy' for > > more fitness. > > > > Not sure if it makes sense or not. > > > > It does - maybe just leave it as is then with the explanation from > above. I would have suggested "FE Failover-restart-policy" but then that > would be misleading because this just describes how you restart and not > necessarily that you are restarting because you have failed over. > Again, I think we need to enumerate the possible (known) schemes. > > cheers, > jamal > > > > Thanks, > > Weiming > > > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > Subject: Re: [Issue 36] FE/CE failover > > > > > > > Weiming, > > > Dont close it yet since I am not sure if i commented on this or not: > > > a) Default behaviors for the two restarts are contradictory. If the > > > Default FE restart behavior is to start from scratch, that implies an > > > element of trust involved i.e the FE doesnt trust the state it has > > > during the disappearance of the CE. OTOH, the CE restart default seems > > > to say the FE should continue to use the policies it has on > > > disappearance of the CE which implies it trusts the state it has as > > > being valid ;-> Is it fair to say we need to choose similar default > > > policies? > > > b) Should we enumerate all possibilities in the text for the two restart > > > policies? > > > > > > cheers, > > > jamal > > > > > > On Wed, 2005-24-08 at 19:51 +0800, Wang,Weiming wrote: > > > > Hi, > > > > > > > > The draft has been updated in Section 6.2.1(FE Protocol LFB) according > > to > > > > the text proposed below. > > > > > > > > The issue 36 can be closed! > > > [..] > > > > > I'm based on you two and propose the following: > > > > > > > > > > * FE restart policy - This specifies the behavior of the FE > > > > > during a restart. For example, this would specify if the FE > > > > > should start from scratch or from a default state after a CE > > > > > failure in the NE. Default value for this attribute should be to let > > the > > > > > FE to start from scratch. > > > > > > > > > > * CE failover policy - This specifies the behavior of the FE > > > > > during a CE failure and restart time interval. For example, > > > > > this would specify if the FE should continue running or stop > > > > > operation during a CE failure in the NE. Default value for > > this > > > > > attribute should be to let the FE to continue running. > > > > > > > > > > Comments please. > > > > > > > > > > Thanks, > > > > > Weiming From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 31 01:29:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EALA4-0004Gd-8a for forces-archive@megatron.ietf.org; Wed, 31 Aug 2005 01:29:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03258 for ; Wed, 31 Aug 2005 01:29:23 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EALBi-0001dw-Kc for forces-archive@IETF.ORG; Wed, 31 Aug 2005 01:31:09 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.010DD930@cherry.ease.lsoft.com>; Wed, 31 Aug 2005 1:29:20 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84446654 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 31 Aug 2005 01:29:13 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 31 Aug 2005 01:29:13 -0400 Received: from [220.192.120.190] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 31 Aug 2005 13:15:36 +0800 (CST) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Approved-By: "Wang,Weiming" Message-ID: <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> Date: Wed, 31 Aug 2005 12:35:40 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [Issue 51]Operation Summary table To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Hi, the Section of Operation SUmmary has been updated as below. Pls show your comments. Thanks, Weiming 6.10 Operation Summary The following table summarizes the TLVs that compose messages, and the applicabiity of operation TLVs to the messages. +----------------------------+-----------+----------------------------+ | Messages | TLVs | Operations | +----------------------------+-----------+----------------------------+ | Association Setup | LFBselect | REPORT | | | | | | Association Setup Response | ASRresult | None | | | | | | Association Teardown | ASTreason | None | | | | | | Config | LFBselect | SET, DEL | | | | | | Config Response | LFBselect | SET-RESPONSE, DEL-RESPONSE | | | | | | Query | LFBselect | GET | | | | | | Query Response | LFBselect | GET-RESPONSE | | | | | | Event Notification | LFBselect | REPORT | | | | | | Packet Redirect | Redirect | None | | | | | | Heartbeat | None | None | +----------------------------+-----------+----------------------------+ The following talbe summarises the applicability of the DATARAW TLV and the RESULT TLV to the Operation TLVs. +--------------+-------------+------------+ | Operations | DATARAW TLV | RESULT TLV | +--------------+-------------+------------+ | SET | MUST | MUST NOT | | | | | | SET-RESPONSE | MAY | MUST | | | | | | DEL | MAY | MUST NOT | | | | | | DEL-RESPONSE | MAY | MUST | | | | | | GET | MUST NOT | MUST NOT | | | | | | GET-RESPONSE | MUST | MAY | | | | | | REPORT | MAY | MUST NOT | +--------------+-------------+------------+ From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 31 05:06:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAOYB-0002wJ-Th for forces-archive@megatron.ietf.org; Wed, 31 Aug 2005 05:06:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09222 for ; Wed, 31 Aug 2005 05:06:29 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAOZo-0007JH-DV for forces-archive@IETF.ORG; Wed, 31 Aug 2005 05:08:18 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.010DDBC7@cherry.ease.lsoft.com>; Wed, 31 Aug 2005 5:06:24 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84453212 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 31 Aug 2005 05:06:23 -0400 Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 31 Aug 2005 05:06:21 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 54342.804536222; Wed, 31 Aug 2005 17:37:37 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Wed, 31 Aug 2005 17:05:46 +0800 References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> <003a01c5a7a2$63e3c820$1f12fea9@wwm1> <6.2.1.2.0.20050823105005.02d046b8@localhost> <018401c5a8bc$8f976970$c77cc0dc@WwmLapSamsung> <6.2.1.2.0.20050824165452.02d3cba0@localhost> <008f01c5ab7d$328006c0$1f06c0dc@WwmLapSamsung> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Approved-By: "Wang,Weiming" Message-ID: <023401c5ae0b$2e615090$1152010a@Necom.hzic.edu.cn> Date: Wed, 31 Aug 2005 17:05:49 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: [issue 34] Header flags To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 4.0 (++++) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: base64 SGksDQoNClRoZSBmb2xsb3dpbmcgaXMgdGhlIGxhdGVzdCBkZWZpbml0aW9uIGZvciBBQ0sgZmxh Zywgd2hpY2ggaGFzIGJlZW4gcHV0IGluIHRoZSBkcmFmdC4gUGxzIGNvbnRpbnVlIGNvbW1lbnRz IG9uOg0KDQo8dGV4dD4NCiAgIEZsYWdzKDMyIGJpdHMpOg0KICAgICAgIElkZW50aWZpZWQgc28g ZmFyOg0KDQogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAgMw0KICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgfEFDS3wgIFBy aSAgfEJhdHxBfCAgICAgICAgICAgICBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQogICAgICAgLSBBQ0s6IEFDSyBpbmRpY2F0b3IoMiBiaXQpDQogICAg ICAgICAgIFRoZSBBQ0sgaW5kaWNhdG9yIGZsYWcgaXMgb25seSB1c2VkIGJ5IGEgQ29uZmlnIE1l c3NhZ2UNCiAgICAgICAgICAgc2VuZGVyIHRvIGluZGljYXRlIHRoZSBtZXNzYWdlIHJlY2VpdmVy IHdoZXRoZXIgb3Igbm90IGENCiAgICAgICAgICAgY29uZmlnIHJlc3BvbnNlIGlzIHJlcXVpcmVk IGJ5IHRoZSBzZW5kZXIuICBOb3RlIHRoYXQgYWxsDQogICAgICAgICAgIG90aGVyIG1lc3NhZ2Vz IHRoYW4gQ29uZmlnIE1lc3NhZ2UgTVVTVCBpZ25vcmUgdGhpcyBmbGFnLg0KDQogICAgICAgICAg IFRoZSBmbGFnIHZhbHVlcyBhcmUgZGVmaW5lZCBhcyBiZWxvdzoNCg0KICAgICAgICAgICAgICAg J05vQUNLJyAoMDApIC0gdG8gaW5kaWNhdGUgdGhlIG1lc3NhZ2UgcmVjZWl2ZXIgbm90IHRvDQog ICAgICAgICAgICAgICBzZW5kIGFueSByZXNwb25zZSBtZXNzYWdlIGJhY2sgdG8gdGhpcyBtZXNz YWdlIHNlbmRlci4NCg0KICAgICAgICAgICAgICAgJ1N1Y2Nlc3NBQ0snKDAxKSAtIHRvIGluaWRj YXRlIHRoZSBtZXNzYWdlIHJlY2VpdmVyIHRvDQogICAgICAgICAgICAgICBzZW5kIGEgcmVzcG9u c2UgbWVzc2FnZSBiYWNrIG9ubHkgd2hlbiB0aGUgbWVzc2FnZSBoYXMNCiAgICAgICAgICAgICAg IGJlZW4gc3VjY2Vzc2Z1bGx5IHByb2Nlc3NlZCBieSB0aGUgcmVjZWl2ZXIuDQoNCiAgICAgICAg ICAgICAgICdGYWlsdXJlQUNLJygxMCkgLSB0byBpbmRpY2F0ZSB0aGUgbWVzc2FnZSByZWNlaXZl ciB0bw0KICAgICAgICAgICAgICAgc2VuZCBhIHJlc3BvbnNlIG1lc3NhZ2UgYmFjayBvbmx5IHdo ZW4gdGhlcmUgaXMgYW55DQogICAgICAgICAgICAgICBmYWlsdXJlIGZvciB0aGUgcmVjZWl2ZXIg dG8gcHJvY2VzcyhleGVjdXRlKSB0aGUgbWVzc2FnZS4NCiAgICAgICAgICAgICAgIEluIG90aGVy IHdvcmRzLCBpZiB0aGUgbWVzc2FnZSBjYW4gYmUgcHJvY2Vzc2VkDQogICAgICAgICAgICAgICBz dWNjZXNzZnVsbHksIHRoZSBzZW5kZXIgd2lsbCBub3QgZXhwZWN0IGFueSByZXNwb25zZQ0KICAg ICAgICAgICAgICAgZnJvbSB0aGUgcmVjZWl2ZXIuDQoNCiAgICAgICAgICAgICAgICdBbHdheXNB Q0snICgxMSkgLSB0byBpbmRpY2F0ZSB0aGUgbWVzc2FnZSByZWNlaXZlciB0bw0KICAgICAgICAg ICAgICAgc2VuZCBhIHJlc3BvbnNlIG1lc3NhZ2UgYmFjayBpbiBhbnkgY2FzZS4NCg0KDQoNCg0K DQoNCkRvcmlhIChFZC4pLCBldCBhbC4gICAgICAgRXhwaXJlcyBNYXJjaCA0LCAyMDA2ICAgICAg ICAgICAgICAgIFtQYWdlIDI3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAg Rm9yQ0VTICAgICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDA1DQoNCg0KICAgICAgICAgICBO b3RlIHRoYXQgaW4gYWJvdmUgZGVmaW5pdGlvbnMsIHRoZSBzdWNjZXNzIG1lYW5zIGEgY29tcGxl dGUNCiAgICAgICAgICAgZXhjdXRpb24gd2l0aG91dCBhbnkgZmFpbHVyZSBvZiB0aGUgbWVzc2Fn ZS4gIFdoaWxlIGFueXRoaW5nDQogICAgICAgICAgIGVsc2UgdGhhbiBhIGNvbXBsZXRlIHN1Y2Nl c3NmdWwgZXhlY3V0aW9uIGlzIGRlZmluZWQgYXMgYQ0KICAgICAgICAgICBmYWlsdXJlIGZvciB0 aGUgbWVzc2FnZSBwcm9jZXNzaW5nLiAgQXMgYSByZXN1bHQsIGZvciB0aGUNCiAgICAgICAgICAg ZXhlY3V0aW9uIG1vZGVzIChkZWZpbmVkIGluIFNlY3Rpb24gMy4zLjEuMSkgbGlrZSBleGVjdXRl LQ0KICAgICAgICAgICBhbGwtb3Itbm9uZSwgZXhlY3V0ZS11bnRpbC1mYWlsdXJlLCBhbmQgY29u dGludWUtZXhlY3V0ZS1vbi0NCiAgICAgICAgICAgZmFpbHVyZSwgaWYgYW55IHNpbmdsZSBvcGVy YXRpb24gYW1vbmcgc2V2ZXJhbCBvcGVyYXRpb25zIGluDQogICAgICAgICAgIHRoZSBzYW1lIG1l c3NhZ2UgZmFpbHMsIGl0IHdpbGwgYmUgdHJlYXRlZCBhcyBhIGZhaWx1cmUgYW5kDQogICAgICAg ICAgIHJlc3VsdCBpbiBhIHJlc3BvbnNlIGlmIHRoZSBBQ0sgaW5kaWNhdG9yIGhhcyBiZWVuIHNl dCB0bw0KICAgICAgICAgICAnRmFpbHVyZUFDSycuDQoNCiAgICAgICAgICAgQWxzbyBub3RlIHRo YXQgb3RoZXIgbWVzc2FnZXMgdGhhbiBDb25maWcgTWVzc2FnZSwgd2hvc2UNCiAgICAgICAgICAg cmVxdWlyZW1lbnRzIGZvciByZXNwb25zZXMgYXJlIHN0YXRpc3RpY2FsbHkgcHJlc2NyaWJlZCBi eQ0KICAgICAgICAgICB0aGUgbWVzc2FnZSBkZWZpbml0aW9ucyBpbiB0aGUgZm9sbG93ZWQgU2Vj dGlvbnMuICBUaGUgQUNLDQogICAgICAgICAgIGluZGljYXRvcnMgaW4gdGhlc2UgbWVzc2FnZXMg TVVTVCBiZSBpZ25vcmVkLg0KDQogICAgICAgICAgIFdlIGluIGFkdmFuY2Ugc3VtbWFyaXNlIHRo ZSBkZWZhdXQgcmVxdWlyZW1lbnRzIG9mIHRoZXNlDQogICAgICAgICAgIG1lc3NhZ2VzLCB0aGVp ciByZXF1aXJlbWVudHMgZm9yIHJlc3BvbnNlcyBhcyBiZWxvdywgd2hpbGUNCiAgICAgICAgICAg ZGV0YWlsZWQgZGVzY3JpcHRpb25zIGNhbiBiZSBmb3VuZCBpbiB0aGUgaW5kaXZpZHVhbCBtZXNz YWdlDQogICAgICAgICAgIGRlZmluaXRpb25zOg0KDQogICAgICAgICAgICsgICBBc3NvY2lhdGlv biBTZXR1cCBNZXNzYWdlIGFsd2F5cyBleHBlY3RzIGEgcmVzcG9uc2UuDQoNCiAgICAgICAgICAg KyAgIEFzc29jaWF0aW9uIFRlYXJkb3duIE1lc3NhZ2UsIFBhY2tldCBSZWRpcmVjdCBNZXNzYWdl LA0KICAgICAgICAgICAgICAgYW5kIEhlYXJ0YmVhdCBNZXNzYWdlIG5ldmVyIGV4cGVjdCByZXNw b25zZXMuDQoNCiAgICAgICAgICAgKyAgIFF1ZXJ5IE1lc3NhZ2UgYWx3YXlzIGV4cGVjdHMgYSBy ZXNwb25zZS4NCg0KICAgICAgICAgICArICAgQW55IGtpbmQgb2YgcmVzcG9uc2UgbWVzc2FnZXMg bmV2ZXIgZXhwZWN0IGZ1cnRoZXINCiAgICAgICAgICAgICAgIHJlc3BvbnNlcy4NCjwvdGV4dD4N Cg0KVGhhbmtzLA0KV2VpbWluZw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJv bTogIldhbmcsV2VpbWluZyIgPHdtd2FuZ0BtYWlsLnpqZ3N1LmVkdS5jbj4NCg0KPiBKb2VsLA0K PiANCj4gQWZ0ZXIgc29tZSBjb25zaWRlcmF0aW9uLCBJIHRoaW5rIHRoaXMgQUNLIGZsYWcgaXMg Zm9yIGFja25vd2xlZGdlbWVudA0KPiByYXRoZXIgdGhhbiBmb3IgcmVzcG9uc2UgY29udHJvbC4g IEl0IGlzIG9ubHkgYXBwbGllZCB0byBDb25maWcgbWVzc2FnZQ0KPiAobm90ZSBub3Qgb25seSBT RVQgYnkgYWxzbyBERUwpIGJlY2F1c2Ugb3RoZXIgbWVzc2FnZXMgaGF2ZSB0byBiZSBjb25zdGFu dGx5DQo+IGRlZmluZWQgZm9yIHRoZXJlIGFja25vd2xlZGdlbWVudCByZXF1aXJlbWVudHMuIFdo aWxlIGZvciBjb25maWcgbWVzc2FnZSwgd2UNCj4gdXNlIHN1Y2ggZmxhZyBvbmx5IHRyeSB0byBn aXZlIHRoZSBtZXNzYWdlIGFja25vd2xlZGdlIHdpdGggc29tZSBjaG9pY2VzDQo+IGxpa2UiIElm IHlvdSBjYW4gZG8gdGhpcywgcGxlYXNlIGxldCBtZSBrbm93Iiwgb3IgIklmIHlvdSBjYW5ub3Qg ZG8gdGhpcywNCj4gcGxlYXNlIGxldCBtZSBrbm93Ii4NCj4gDQo+IE5vdywgaWYgd2UgdGhlbiBw dXQgc3VjaCBmbGFnIGluIE9wZXJhdGlvbiBUTFZzIGluIGNvbmZpZyBtZXNzYWdlLCB3ZSBtYXkN Cj4gbm90IGFibGUgdG8gcmVhY2ggdGhlIGdvYWwgYWJvdmUsIGJlY2F1c2UgaXQgaXMgc3RpbGwg dmFndWUgaWYgYSBDb25maWcNCj4gUmVzcG9uc2UgaXMgcmVxdWlyZWQgb3Igbm90IHdoZW4gd2Ug c2V0IGFsbCBPcCBUTFZzIGluc2RlIHdpdGgNCj4gTm9BQ0soTm9SZXNwb25zZSkuDQo+IA0KPiBB cyBhIHJlc3VsdCwgSSB0aGluayB0byBjb25zaWRlciBhIGZsYWcgaW4gZXZlcnkgT3BlcmF0aW9u IFRMViBmb3IgcmVzcG9uc2UNCj4gY29udHJvbCBtYXkgc3RpbGwgYmUgYW4gaXNzdWUgc2VwYXJh dGVkIHRvIHRoZSBBQ0sgZmxhZyB1c2VkIGluIHRoZSBoZWFkZXIuDQo+IA0KPiBPbmUgcHJvcG9z ZWQgc29sdXRpb24gZm9yIHRoZSBBQ0sgZmxhZyBpcywgSSBzdXBwb3NlLCBzdGlsbCBwdXQgaXQg aW4gdGhlDQo+IGhlYWRlciwgd2l0aCB0aGUgZGVmaW5lIHRoYXQgdGhlIGZsYWcgaXMgb25seSBh cHBsaWVkIHRvIENvbmZpZyBtZXNzYWdlLiBGb3INCj4gYWxsIG90aGVyIG1lc3NhZ2VzLCB0aGUg ZmxhZyBpcyBpZ25vcmVkLCBhbmQgZm9yIGFsbCBvdGhlciBtZXNzYWdlcywNCj4gd2hldGhlciBy ZXNwb25zZXMgYXJlIHJlcXVpcmVkIGFyZSBleHBpY2l0bHkgZGVmaW5lZCBpbiB0aGUgbWVzc2Fn ZQ0KPiBkZWZpbml0aW9ucy4gIEluIHRoaXMgd2F5LCBJIGNhbiBqdXN0IHNhdmUgdGhlIHBhcmFn cmFwaCB0aGF0IGRlc2NyaWJlIHRoZQ0KPiBpbmRpdmlkdWFsIEFDSyBmbGFnIHVzYWdlIGZvciBh bGwgb3RoZXIgbWVzc2FnZXMuDQo+IA0KPiBBbnkgdGhvdWdodHM/DQo+IA0KPiBUaGFua3MsDQo+ IFdlaW1pbmcNCj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogIkpv ZWwgTS4gSGFscGVybiIgPGpvZWxAc3RldmVjcm9ja2VyLmNvbT4NCj4gVG86ICJXYW5nLFdlaW1p bmciIDx3bXdhbmdAbWFpbC56amdzdS5lZHUuY24+OyA8Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQu Q09NPg0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDI1LCAyMDA1IDQ6NTUgQU0NCj4gU3ViamVj dDogUmU6IFtpc3N1ZSAzNF0gSGVhZGVyIGZsYWdzDQo+IA0KPiANCj4gPiBMb29raW5nIGF0IHlv dXIgbW9yZSByZWNlbnQgbm90LCBpdCBzZWVtcyB0aGF0IHRoZXNlIGZsYWdzIG9ubHkgYXBwbHkg dG8NCj4gPiB0aGUgU0VUIChDb25maWcpIFJlcXVlc3QpLiAgSWYgdGhhdCBpcyBzbywgdGhlbiB0 aGV5IGJlbG9uZyBpbiB0aGUgU0VUDQo+ID4gT3BlcmF0aW9uIFRMViwgb3IgaW4gdGhlIGZvcm1h dCBvZiB0aGUgQ29uZmlnIG1lc3NhZ2UuDQo+ID4NCj4gPiBZb3VycywNCj4gPiBKb2VsIE0uIEhh bHBlcm4NCj4gPg0KPiA+IEF0IDEwOjA5IEFNIDgvMjQvMjAwNSwgV2FuZyxXZWltaW5nIHdyb3Rl Og0KPiA+ID5Kb2VsLA0KPiA+ID4NCj4gPiA+UGxzIGFsbG93IG1lIHRvIGNoYW5nZSB0aGUgdGl0 aWxlIHRvIGlzc3VlIDM0Lg0KPiA+ID4NCj4gPiA+SSBhZ3JlZSB3aXRoIHlvdSBzb21lIHdoYXQu IEkgYWxzbyBub3RpY2VkIHRoYXQgYWN0dWFseSB0aGUgQUNLIGZsYWcgaXMNCj4gb25seQ0KPiA+ ID51c2VmdWwgZm9yIENvbmZpZyBtZXNzYWdlIGFmdGVyIHdlIHJlbW92ZWQgZXZlbnQgcmVzcG9u c2UgZnVuY3Rpb24uDQo+ID4gPg0KPiA+ID5UaGUgcXVlc3Rpb24gaXMsIGlmIHdlIGRvbid0IHB1 dCBpdCBpbiB0aGUgY29tbW9uIGhlYWRlciwgYXMgYSBnbG9iYWwNCj4gZmxhZw0KPiA+ID5mb3Ig dGhpcyBtZXNzYWdlLCB3aGVyZSBjYW4gd2UgcHV0IHRoZW4gYW5kIGhvdyB3ZSBjYW4gbWFrZSBp dA0KPiBzcGVjaWZpY2FsbHkNCj4gPiA+Zm9yIGNvbmZpZyBtZXNzYWdlIG9ubHk/DQo+ID4gPg0K PiA+ID5JIHRob3VnaHQgb2YgcHV0aW5nIHRoZSBmbGFnIGluIGFuIExGQnNlbGVjdCBUTFYsIHRo ZSBvcGVyYXRpb24gVExWLCAgKG9yDQo+ID4gPmV2ZW4gaW4gYSBQYXRoIGZsYWcpLiBJbiB0aGlz IHdheSwgaXQgbWFrZXMgdGhlIGZsYWcgb25seSByZXN0cmljdGVkIHRvDQo+IHRoZQ0KPiA+ID5M RkIgc2VsZWN0b3IsIHRoZSBvcGVyYXRpb24sICAob3IgZXZlbiB0aGUgcGF0aCkuICBJdCBtZWFu cyBzb21lDQo+IExGQnNlbGVjdA0KPiA+ID5vciBvcGVyYXRpb25zIGluc2lkZSB3YW50cyByZXNw b25zZSwgd2hpbGUgb3RoZXJzIG1heSBub3QuIEkgZGlkbid0IHRoaW5rDQo+IGl0DQo+ID4gPmZ1 cnRoZXIuDQo+ID4gPg0KPiA+ID5UaGFua3MsDQo+ID4gPldlaW1pbmcNCj4gPiA+DQo+ID4gPi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiA+RnJvbTogIkpvZWwgTS4gSGFscGVybiIg PGpvZWxAc3RldmVjcm9ja2VyLmNvbT4NCj4gPiA+DQo+ID4gPiA+IFRoZSB0ZXh0IGJlbG93IGlz IGFuIGV4Y2VycHQgZnJvbSBhIHByb3Bvc2VkIG1ldGhvZG9sb2d5IGZvciBhDQo+IHBhcnRpY3Vs YXINCj4gPiA+ID4gUEwgbWVzc2FnZS4NCj4gPiA+ID4gSXQgaXMgYWJvdXQgZXZlbnQgbm90aWZp Y2F0aW9uIG1lc3NhZ2VzLCBhbmQgdGhlIGZhY3QgdGhhdCBubw0KPiByZXNwb25zZXMNCj4gPiA+ YXJlDQo+ID4gPiA+IGV4cGVjdGVkIHRvIHRoZW0uICAoVGhleSBhcmUgdHJhbnNtaXR0ZWQgcmVs aWFibHksIGFuZCB0aGUgRkUgd2hpY2gNCj4gc2VuZHMNCj4gPiA+ID4gdGhlbSBoYXMgbm8gdXNl IGZvciBhbiBBQ0suDQo+ID4gPiA+DQo+ID4gPiA+IEhvd2V2ZXIsIGlmIHdlIGFyZSBnb2luZyB0 byB0YWtlIHRoaXMgYXBwcm9hY2gsIHdlIHJlbmRlciB0aGUgYWNrDQo+IGZsYWdzDQo+ID4gPiA+ IG11Y2ggbW9yZSBjb21wbGV4LiAgV2Ugc2hvdWxkIGVpdGhlciBkZWZpbmUgdGhlIGFjayBmbGFn cyBnbG9iYWxseSBhbmQNCj4gdXNlDQo+ID4gPiA+IHRoZW0gZXZlcnl3aGVyZSwgb3Igd2Ugc2hv dWxkIG5vdCBoYXZlIHRoZW0gaW4gdGhlIGNvbW1vbiBtZXNzYWdlDQo+IGhlYWRlci4NCj4gPiA+ ID4gSWYgd2UgY2hvb3NlIHRvIGtlZXAgdGhlbSwgdGhlbiBhIG1lc3NhZ2UgcmVjZWl2ZXIgc2hv dWxkIGJlIHByZXBhcmVkDQo+IHRvDQo+ID4gPiA+IGdlbmVyYXRlIGFuIEFDSyBmb3IgQU5ZIG1l c3NhZ2UgaXQgcmVjZWl2ZXMsIGlmIHRoZSBmbGFncyB0ZWxsIGl0IHRvDQo+IGRvDQo+ID4gPnNv Lg0KPiA+ID4gPg0KPiA+ID4gPiBZb3VycywNCj4gPiA+ID4gSm9lbCBNLiBIYWxwZXJuDQo+ID4g PiA+DQo+ID4gPiA+IEF0IDAxOjIwIEFNIDgvMjMvMjAwNSwgV2VpbWluZyBXYW5nIHdyb3RlOg0K PiA+ID4gPiA+ICAgICAgIGhlYWRlciBTSE9VTEQgYmUgcmVhc29uYWJseSBzZXQgdG8gJ05vQUNL Jy4gIElmIHRoZSBBQ0sgZmxhZw0KPiBpcw0KPiA+ID4gPiA+ICAgICAgIHNldCB0byBhbnkgb3Ro ZXIgdmFsdWVzLCB0aGUgbWVhbmluZyBvZiB0aGUgZmxhZyB3aWxsIHRoZW4gYmUNCj4gPiA+ID4g PiAgICAgICBpZ25vcmVkLg0KPiA+ From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 31 07:22:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAQg9-0007Kp-QP for forces-archive@megatron.ietf.org; Wed, 31 Aug 2005 07:22:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14554 for ; Wed, 31 Aug 2005 07:22:50 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAQhp-0002PT-Au for forces-archive@IETF.ORG; Wed, 31 Aug 2005 07:24:39 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.010DDB88@cherry.ease.lsoft.com>; Wed, 31 Aug 2005 7:21:49 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84464347 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 31 Aug 2005 07:21:48 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 31 Aug 2005 07:21:47 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7VAdaXK051869; Wed, 31 Aug 2005 03:39:37 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <009d01c5a413$9b61f7f0$9273c0dc@WwmLapSamsung> <013401c5a8ab$770e3160$c77cc0dc@WwmLapSamsung> <1124895533.6300.7.camel@localhost.localdomain> <012501c5abac$c3dad3f0$1f06c0dc@WwmLapSamsung> <1125244775.6422.70.camel@localhost.localdomain> <006501c5ad4e$383b9390$c078c0dc@WwmLapSamsung> <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1125487290.6354.12.camel@localhost.localdomain> Date: Wed, 31 Aug 2005 07:21:30 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [Issue 51]Operation Summary table Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <003101c5ade5$8134bbc0$be78c0dc@WwmLapSamsung> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Hi Weiming, Since you MAY have this already in your text. On Wed, 2005-31-08 at 12:35 +0800, Wang,Weiming wrote: > Hi, > > the Section of Operation SUmmary has been updated as below. Pls show your > comments. > > Thanks, > Weiming > > > 6.10 Operation Summary > > The following table summarizes the TLVs that compose messages, and > the applicabiity of operation TLVs to the messages. > So what happens if someone adds a new TLV or operation that goes in addition with the already defined one? I think we need to specify the behavior. Example it could be "Ignore". Actually i think it should be "Ignore" for backward compatibility reasons. cheers, jamal > +----------------------------+-----------+----------------------------+ > | Messages | TLVs | Operations | > +----------------------------+-----------+----------------------------+ > | Association Setup | LFBselect | REPORT | > | | | | > | Association Setup Response | ASRresult | None | > | | | | > | Association Teardown | ASTreason | None | > | | | | > | Config | LFBselect | SET, DEL | > | | | | > | Config Response | LFBselect | SET-RESPONSE, DEL-RESPONSE | > | | | | > | Query | LFBselect | GET | > | | | | > | Query Response | LFBselect | GET-RESPONSE | > | | | | > | Event Notification | LFBselect | REPORT | > | | | | > | Packet Redirect | Redirect | None | > | | | | > | Heartbeat | None | None | > +----------------------------+-----------+----------------------------+ > > The following talbe summarises the applicability of the DATARAW TLV > and the RESULT TLV to the Operation TLVs. > > +--------------+-------------+------------+ > | Operations | DATARAW TLV | RESULT TLV | > +--------------+-------------+------------+ > | SET | MUST | MUST NOT | > | | | | > | SET-RESPONSE | MAY | MUST | > | | | | > | DEL | MAY | MUST NOT | > | | | | > | DEL-RESPONSE | MAY | MUST | > | | | | > | GET | MUST NOT | MUST NOT | > | | | | > | GET-RESPONSE | MUST | MAY | > | | | | > | REPORT | MAY | MUST NOT | > +--------------+-------------+------------+ From owner-forces@PEACH.EASE.LSOFT.COM Wed Aug 31 07:51:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAR7Z-0007bX-AH for forces-archive@megatron.ietf.org; Wed, 31 Aug 2005 07:51:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15589 for ; Wed, 31 Aug 2005 07:51:11 -0400 (EDT) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAR9G-00037L-AY for forces-archive@IETF.ORG; Wed, 31 Aug 2005 07:53:01 -0400 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.010DDCC0@cherry.ease.lsoft.com>; Wed, 31 Aug 2005 7:51:08 -0400 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.4) with spool id 84465643 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 31 Aug 2005 07:50:51 -0400 Received: from 208.2.156.141 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0m) with TCP; Wed, 31 Aug 2005 07:50:50 -0400 Received: from localhost.localdomain (electra.znyx.com [208.2.156.2]) by mailhub.znyx.com (8.12.9/8.12.9) with ESMTP id j7VB8kXK052096; Wed, 31 Aug 2005 04:08:47 -0700 (PDT) References: <468F3FDA28AA87429AD807992E22D07E0618E3A9@orsmsx408> <42F8998F.9060109@zurich.ibm.com> <43020D11.5030400@zurich.ibm.com> <00f501c5a47e$820be7a0$9273c0dc@WwmLapSamsung> <004601c5a742$fd5c9370$1f12fea9@wwm1> <002601c5a794$499bc1b0$1f12fea9@wwm1> <003a01c5a7a2$63e3c820$1f12fea9@wwm1> <6.2.1.2.0.20050823105005.02d046b8@localhost> <018401c5a8bc$8f976970$c77cc0dc@WwmLapSamsung> <6.2.1.2.0.20050824165452.02d3cba0@localhost> <008f01c5ab7d$328006c0$1f06c0dc@WwmLapSamsung> <023401c5ae0b$2e615090$1152010a@Necom.hzic.edu.cn> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit Approved-By: Jamal Hadi Salim Message-ID: <1125489040.6354.31.camel@localhost.localdomain> Date: Wed, 31 Aug 2005 07:50:40 -0400 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 34] Header flags Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <023401c5ae0b$2e615090$1152010a@Necom.hzic.edu.cn> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit On Wed, 2005-31-08 at 17:05 +0800, Wang,Weiming wrote: > Hi, > > The following is the latest definition for ACK flag, which has been put in the draft. Pls continue comments on: > > > Flags(32 bits): > Identified so far: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |ACK| Pri |Bat|A| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > - ACK: ACK indicator(2 bit) > The ACK indicator flag is only used by a Config Message > sender to indicate the message receiver whether or not a > config response is required by the sender. Note that all > other messages than Config Message MUST ignore this flag. > I apologize to bring this up at the last minute; I missed following up this discussion that you had with Joel. Also, in your discussion with Joel you said the flag was for "acknowledgement rather than response"; I dont see the difference between the two. Must we use such strong language above? Example, while probably not very likely, a) I could send a heartbeat (which is not a Config msg) that i request a response for - setting the ACK flag allows me to and b) I may not wish to recieve a response for a certain config. Shall we reduce it to a recommendation?: "The ACK indicator flag is used by the sender to indicate to the receiver how it wishes to see a response. As an example Config Message SHOULD always set this flag while other message types SHOULD NOT" I used the word "example" because you have more clarifying text below. > The flag values are defined as below: > > 'NoACK' (00) - to indicate the message receiver not to > send any response message back to this message sender. [..] > Also note that other messages than Config Message, whose > requirements for responses are statistically prescribed by > the message definitions in the followed Sections. The ACK > indicators in these messages MUST be ignored. > Another use of the term MUST above. cheers, jamal