From mailman-bounces@ietf.org Fri Oct 1 06:02:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12591 for ; Fri, 1 Oct 2004 06:02:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDKNM-0003Io-Bp for forces-protocol-web-archive@ietf.org; Fri, 01 Oct 2004 06:10:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJXk-0006KF-CB for forces-protocol-web-archive@ietf.org; Fri, 01 Oct 2004 05:17:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: forces-protocol-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:03:44 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for forces-protocol-web-archive@ietf.org: List Password // URL ---- -------- forces-protocol@ietf.org ocehap https://www1.ietf.org/mailman/options/forces-protocol/forces-protocol-web-archive%40ietf.org From forces-protocol-bounces@ietf.org Thu Oct 7 12:50:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03910 for ; Thu, 7 Oct 2004 12:50:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbdH-0000hL-Dl for forces-protocol-web-archive@ietf.org; Thu, 07 Oct 2004 13:00:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbQQ-0006VH-Sg; Thu, 07 Oct 2004 12:47:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFbH1-0004mR-Hz for forces-protocol@megatron.ietf.org; Thu, 07 Oct 2004 12:37:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03143 for ; Thu, 7 Oct 2004 12:37:41 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFbQi-0008Lj-Dq for forces-protocol@ietf.org; Thu, 07 Oct 2004 12:47:49 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004100709401474:16860 ; Thu, 7 Oct 2004 09:40:14 -0700 From: Jamal Hadi Salim To: "Joel M. Halpern" In-Reply-To: <1095186094.1032.53.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <5.1.0.14.0.20040914134714.02497d00@mail.megisto.com> <1095186094.1032.53.camel@jzny.localdomain> Organization: Znyx Networks Message-Id: <1097167049.1045.6.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Oct 2004 12:37:29 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/07/2004 09:40:15 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/07/2004 09:40:26 AM, Serialize complete at 10/07/2004 09:40:26 AM Content-Type: multipart/mixed; boundary="=-jOhEd9LehIsm76dg4oPn" X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: ram.gopal@nokia.com, Steve Blake , avri@psg.com, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 --=-jOhEd9LehIsm76dg4oPn Content-Type: text/plain Content-Transfer-Encoding: 7bit Joel and myself have put an update to the earlier doc. Its now a singular view. The issue on the tables and attribute update is open pending on discussions on the table doc currently being discussed. The decision on how things get laid out is in the hands of the protocol team although this document bridges a lot of the views between the model and the protocol side of things and so is a very good start. Lets please start the ball rolling again on this and discuss. cheers, jamal --=-jOhEd9LehIsm76dg4oPn Content-Disposition: attachment; filename=msg-discuss.txt Content-Type: text/plain; name=msg-discuss.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is a document that captures thoughts discussed starting at the SD IETF and thereafter in many many emails involving the model team. It is only meant as a guidance, the Protocol design team may decide to rearrange things as long as the requirements discussed are met. PL level PDU : = MAINHDR+ LFBselect := LFBCLASSID+ LFBTARGET:=LFBInstance+ OPER:= ]*>+ - MAINHDR defines msg type, Target FE/CE ID etc. - LFBCLASSID is a 32 bit unique identifier per LFB class defined at class creation time. - LFBInstance is a 32 bit unique instance identifier of an LFB class - OPERATION is one of {ADD,DEL,GET, ??} path-data identifies the exact element targeted. It may have zero or more data values associated. In summary the described approach has the following characteristic: - there can be one or more LFB Classes targeted in a message (batch) - there can be one or more LFB instanceids per class targetted (batch) - There can one or more operation on an addressed LFB instanceid (batch) - There can be one or more targets per operation (batch) - paths may have zero or more data values associated (flexibility) To illustrate, -------------- main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = 0x45 | | | +---T = LFBTARGET | | | | | +-- LFBInstance = 0x1234 | | | | | +-- T = ADD | | | | | | | +-- // one or more targets | | | // with their data here to be added | | | | | +-- T = DEL | | . | | | . +-- // one or more targets to be deleted | | | | | +---T = LFBTARGET | | | | | +-- LFBInstance = 0x145 | | | | . | // at row index 7, replace foo1 | . + -- T= ADD | . | | | . | | . | // Block del operation on row 1-4 of table X | . + -- T= DEL | . | | . | // at row index 70, get the value of foo2 | . + -- T= GET | | +--- T = LFBselect | +-- LFBCLASSID = 0x145 | +---T = LFBTARGET | | | +-- LFBInstance = 0x14 . . . Main Hdr: -------- As shown above the layout begins with the main header identifies the the msg type such as "config". The main header identifies the source and target FEid/CEid. LFBselect --------- A TLV. The value contains the LFB class being selected and and one or TLVs (LFBTARGET) identifying the instances of that class that are being targeted. LFBInstance ----------- A TLV. The value contains the instance being targeted and one or more TLVs defining various operations executed on the LFB instance. Operation --------- A TLV. The T defines the type of operation eg ADD. The value contains one or more path-data. path-data ---------- The layout is still under discussion and so is left out from this text. Each accessible attribute within an LFB is expected to have a 32 bit identifier. Attributes that are defined at class definition time and which are immutable are reffered as "static". Attributes created at runtime are "dynamic" - example a table row is "dynamic". The path-data will have a map derived from the static as well as dynamic IDs. Below is an illustration of a complex example and how the different attributes could be accessed. Assume LFB Class A. It contains two Arrays, B, and C (assigned identifiers 1 and 2) A also contains a structure of type Stoo with a human name F. F is assigned ID 3. A also contains two attributes, D and E assigned identifiers 4 and 5. Array B is an array, indexed as a table, whose contents are int32s. Array C is an array, indexed as a table, whose contents are a structure named Star. Stoo type structures contain elements X and Y, each characters, assigned identifiers 1 and 2. Star contains An element N (a sting), assigned identifier 1, and an array Arr, assigned identifier 2, indexed as a table, containing int32s. To reference entities within an LFB instance of Class A, selectors are as follows: 1, meaning the full array B 3, meaning the full structure named F. 2, 7 meaning the full structure in the seventh entry of the array C. 4 means the attribute D 2, 8, 2, 9 meaning the 9th number in the array in the structure in the eigth slot of the array C. Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct type definition. Since the model team has asserted that class definitions can only change (version) in ways that leave existing references intact and usable it means backward compatibility is supported. Other Issues that came up -------------------------- 1) Scope of Ts. It is expected that most of the Ts would be global. There may be however desire to have localy scoped Ts depending on the LFB class 2) Can the same Ts be repeated multiple times within a hierachy? Yes. $Log: msg-discuss.txt,v $ Revision 1.5 2004/10/06 15:10:37 hadi More discussions with Joel - I think we have reached a compromise Removed any references to how paths are achieved; leave that to the Doc from Steve and Zsolt (for now at least) Revision 1.4 2004/08/28 18:11:25 hadi reached semi-convergence with Joel Revision 1.3 2004/08/27 01:06:34 hadi Adding Joels views on the OPER approach Revision 1.2 2004/08/12 12:47:21 hadi updated diagram per Zsolts comments Revision 1.1 2004/08/12 11:34:25 hadi Initial revision --=-jOhEd9LehIsm76dg4oPn Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=-jOhEd9LehIsm76dg4oPn-- From forces-protocol-bounces@ietf.org Thu Oct 7 15:18:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14083 for ; Thu, 7 Oct 2004 15:18:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdwI-0003cd-Hc for forces-protocol-web-archive@ietf.org; Thu, 07 Oct 2004 15:28:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdgw-0004Wr-4A; Thu, 07 Oct 2004 15:12:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFdXd-0006Jc-Jx for forces-protocol@megatron.ietf.org; Thu, 07 Oct 2004 15:03:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11575 for ; Thu, 7 Oct 2004 15:03:03 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFdhO-0002b4-71 for forces-protocol@ietf.org; Thu, 07 Oct 2004 15:13:10 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i97J2nxA024565; Thu, 7 Oct 2004 19:02:50 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i97J4t1U025266; Thu, 7 Oct 2004 19:05:40 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100712021714593 ; Thu, 07 Oct 2004 12:02:18 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 12:02:18 -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 Date: Thu, 7 Oct 2004 12:02:16 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02CEB630@orsmsx408> Thread-Topic: updated notes on BNF and layout Thread-Index: AcSsi/8MbrJ4szTmQeuuArICf/svqwAE5LYA From: "Khosravi, Hormuzd M" To: , "Joel M. Halpern" X-OriginalArrivalTime: 07 Oct 2004 19:02:18.0013 (UTC) FILETIME=[2A72D4D0:01C4ACA0] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Steve Blake , avri@psg.com, donglg@mail.hzic.edu.cn, zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , "Deleganes, Ellen M" , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] RE: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Jamal, Joel, This looks very good, I am glad you guys have worked out your differences. Thanks for the effort! It is also in line with the text that Steve, Zsolt have sent out. The next thing that needs to be done, I think is the protocol team should start working on the draft, having conference calls, etc. if needed. The deadline for the draft submission is 25th Oct so we should shoot to have something by the 22nd. Anyways I will send out an email to the protocol team to discuss this in more detail. Thanks again & regards Hormuzd=20 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Thursday, October 07, 2004 9:37 AM To: Joel M. Halpern Cc: ram.gopal@nokia.com; Steve Blake; avri@psg.com; donglg@mail.hzic.edu.cn; Khosravi, Hormuzd M; zsolt@petri-meat.com; Yang, Lily L; forces-protocol@ietf.org; Alan DeKok; Deleganes, Ellen M; wmwang@mail.hzic.edu.cn; Robert Haas Subject: updated notes on BNF and layout Joel and myself have put an update to the earlier doc. Its now a singular view. The issue on the tables and attribute update is open pending on discussions on the table doc currently being discussed. The decision on how things get laid out is in the hands of the protocol team although this document bridges a lot of the views between the model and the protocol side of things and so is a very good start. Lets please start the ball rolling again on this and discuss. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 7 18:00:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02444 for ; Thu, 7 Oct 2004 18:00:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFgSq-0007ga-RR for forces-protocol-web-archive@ietf.org; Thu, 07 Oct 2004 18:10:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFg87-0007Bv-4D; Thu, 07 Oct 2004 17:48:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFftj-0001bj-4e for forces-protocol@megatron.ietf.org; Thu, 07 Oct 2004 17:34:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00019 for ; Thu, 7 Oct 2004 17:34:00 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFg3V-0006Bj-8w for forces-protocol@ietf.org; Thu, 07 Oct 2004 17:44:09 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i97Lax8c001500; Thu, 7 Oct 2004 21:36:59 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i97Laj1E011711; Thu, 7 Oct 2004 21:36:52 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100714332709846 ; Thu, 07 Oct 2004 14:33:27 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 14:33:27 -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 Date: Thu, 7 Oct 2004 14:33:25 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02CEBA13@orsmsx408> Thread-Topic: ForCES protocol update for the IETF Thread-Index: AcQx3VLGid4GPZZ9T2i/8IuCQuX3+AAVufqAAfvMRxAcpEyPMA== From: "Khosravi, Hormuzd M" To: , , , , , "Robert Haas" X-OriginalArrivalTime: 07 Oct 2004 21:33:27.0007 (UTC) FILETIME=[47FD7EF0:01C4ACB5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: "Putzolu, David" , forces-protocol@ietf.org Subject: [Forces-protocol] ForCES protocol update for the IETF X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Hi Team, Sorry I haven't been much in touch for the last couple of weeks, extremely busy with other things at work. The deadline for draft submission for this IETF is the Oct 25th which is coming up pretty soon. We made a lot of progress before the last IETF and I hope to continue with that momentum. Some of the reasons for our success was timelines and distribution of work...so I will try the same again. Here are some timelines we can use... Now - Oct 15th - Individual owners update their respective sections acc. to the comments we have received and discussions with the protocol team Oct 15th - Oct 22nd - Discuss the updates and start incorporating the text into the drafts. Does this sound reasonable ? If you guys would like to have a conference call early next week, let me know...although I guess this might not be needed at the moment. Here are the section owners/volunteers (from last draft)-=20 Abstract - Avri 1. Introduction - Avri 2. Definitions - Weiming 3. Protocol Overview - Jamal 4. TML Requirements - Jamal 5. Common Header - Weiming, Ligang (Jamal/Robert) 6. Protocol Messages - Hormuzd, Weiming (I expect everyone to be involved with this one) 7. Protocol Scenarios - Hormuzd, Ram 8. High Availability - Hormuzd 9. Security Considerations - Ram 10. References - Avri 11. Acknowledgments - All Appendix A. Implementation Notes - All? Pls let us know your thoughts on any of this, Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 8 09:38:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23390 for ; Fri, 8 Oct 2004 09:38:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFv6g-0006iK-SE for forces-protocol-web-archive@ietf.org; Fri, 08 Oct 2004 09:48:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFuwK-00025U-0d; Fri, 08 Oct 2004 09:37:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFusO-0001fr-0w for forces-protocol@megatron.ietf.org; Fri, 08 Oct 2004 09:33:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23197 for ; Fri, 8 Oct 2004 09:33:39 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFv2J-0006dq-E8 for forces-protocol@ietf.org; Fri, 08 Oct 2004 09:43:55 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004100806361928:18154 ; Fri, 8 Oct 2004 06:36:19 -0700 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02CEBA13@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02CEBA13@orsmsx408> Organization: ZNYX Networks Message-Id: <1097242414.1043.686.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Oct 2004 09:33:35 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/08/2004 06:36:19 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/08/2004 06:36:22 AM, Serialize complete at 10/08/2004 06:36:22 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org, avri@psg.com, "Putzolu, David" , donglg@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] Re: ForCES protocol update for the IETF X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Hormuzd, Good stuff, lets get moving. One of the things to immediately look at is the effect of the model team into the existing draft. Lets hope everyone reviews before the concall. cheers, jamal On Thu, 2004-10-07 at 17:33, Khosravi, Hormuzd M wrote: > Hi Team, > > Sorry I haven't been much in touch for the last couple of weeks, > extremely busy with other things at work. The deadline for draft > submission for this IETF is the Oct 25th which is coming up pretty soon. > We made a lot of progress before the last IETF and I hope to continue > with that momentum. Some of the reasons for our success was timelines > and distribution of work...so I will try the same again. > > Here are some timelines we can use... > > Now - Oct 15th - Individual owners update their respective sections acc. > to the comments we have received and discussions with the protocol team > Oct 15th - Oct 22nd - Discuss the updates and start incorporating the > text into the drafts. > > Does this sound reasonable ? If you guys would like to have a conference > call early next week, let me know...although I guess this might not be > needed at the moment. > > Here are the section owners/volunteers (from last draft)- > > Abstract - Avri > 1. Introduction - Avri > 2. Definitions - Weiming > 3. Protocol Overview - Jamal > 4. TML Requirements - Jamal > 5. Common Header - Weiming, Ligang (Jamal/Robert) > 6. Protocol Messages - Hormuzd, Weiming (I expect everyone to be > involved with this one) > 7. Protocol Scenarios - Hormuzd, Ram > 8. High Availability - Hormuzd > 9. Security Considerations - Ram > 10. References - Avri > 11. Acknowledgments - All > Appendix > A. Implementation Notes - All? > > Pls let us know your thoughts on any of this, > > Thanks > Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 8 11:04:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02350 for ; Fri, 8 Oct 2004 11:04:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFwSK-0000Tz-EA for forces-protocol-web-archive@ietf.org; Fri, 08 Oct 2004 11:14:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFw6f-0000jz-8E; Fri, 08 Oct 2004 10:52:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFw0j-0007Cd-E5 for forces-protocol@megatron.ietf.org; Fri, 08 Oct 2004 10:46:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00825 for ; Fri, 8 Oct 2004 10:46:20 -0400 (EDT) Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFwAc-0008OA-O9 for forces-protocol@ietf.org; Fri, 08 Oct 2004 10:56:38 -0400 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.41) id 1CFvzY-0000Bq-Iu; Fri, 08 Oct 2004 10:45:08 -0400 From: Steven Blake To: hadi@znyx.com In-Reply-To: <1097167049.1045.6.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <5.1.0.14.0.20040914134714.02497d00@mail.megisto.com> <1095186094.1032.53.camel@jzny.localdomain> <1097167049.1045.6.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1097246704.2341.124.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 08 Oct 2004 10:45:05 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, avri@psg.com, forces-protocol@ietf.org, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , "Joel M. Halpern" , Alan DeKok , Ellen M Deleganes , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] Re: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit On Thu, 2004-10-07 at 12:37, Jamal Hadi Salim wrote: > PL level PDU : = MAINHDR+ > LFBselect := LFBCLASSID+ > LFBTARGET:=LFBInstance+ > OPER:= ]*>+ > > - MAINHDR defines msg type, Target FE/CE ID etc. > - LFBCLASSID is a 32 bit unique identifier per LFB class defined > at class creation time. > - LFBInstance is a 32 bit unique instance identifier of an LFB class > - OPERATION is one of {ADD,DEL,GET, ??} I suggest that LFBselect and LFBTARGET should be collapsed, like so: LFBselect := LFBCLASSID:LFBInstance+ If you want to target another instance of LFB class W in a PL-level PDU, just add an additional LFBselect TLV. I also wonder if we need LFBCLASSID:LFBInstance to be 32:32 instead of 16:16. > path-data identifies the exact element targeted. > It may have zero or more data values associated. > > In summary the described approach has the following characteristic: > - there can be one or more LFB Classes targeted in a message (batch) Ok > - there can be one or more LFB instanceids per class targetted (batch) Ok, but I would suggest doing that with another LFBselect TLV > - There can one or more operation on an addressed LFB instanceid > (batch) Ok > - There can be one or more targets per operation (batch) Shouldn't this be the other way around: one or more operations per target? > - paths may have zero or more data values associated (flexibility) You need this for GET. [snip] > path-data > ---------- > The layout is still under discussion and so is left out from this > text. > > Each accessible attribute within an LFB is expected to have a 32 bit > identifier. Attributes that are defined at class definition time > and which are immutable are reffered as "static". Attributes created > at runtime are "dynamic" - example a table row is "dynamic". > > The path-data will have a map derived from the static as well as > dynamic IDs. This is the first I've heard of attributes that are "created at runtime", and not defined in the class definition. I have no idea how this would work. Regards, // Steve _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 8 11:42:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05674 for ; Fri, 8 Oct 2004 11:42:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFx38-0001Sp-0X for forces-protocol-web-archive@ietf.org; Fri, 08 Oct 2004 11:52:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFwqr-0002aH-Sf; Fri, 08 Oct 2004 11:40:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFwl4-0001Gt-6R for forces-protocol@megatron.ietf.org; Fri, 08 Oct 2004 11:34:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04936 for ; Fri, 8 Oct 2004 11:34:13 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFwv0-0001EF-Ag for forces-protocol@ietf.org; Fri, 08 Oct 2004 11:44:31 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004100808365324:18312 ; Fri, 8 Oct 2004 08:36:53 -0700 From: Jamal Hadi Salim To: Steve Blake In-Reply-To: <1097246704.2341.124.camel@localhost.localdomain> References: <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <5.1.0.14.0.20040914134714.02497d00@mail.megisto.com> <1095186094.1032.53.camel@jzny.localdomain> <1097167049.1045.6.camel@jzny.localdomain> <1097246704.2341.124.camel@localhost.localdomain> Organization: Znyx Networks Message-Id: <1097249647.1076.28.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Oct 2004 11:34:08 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/08/2004 08:36:53 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/08/2004 08:36:55 AM, Serialize complete at 10/08/2004 08:36:55 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, avri@psg.com, forces-protocol@ietf.org, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , "Joel M. Halpern" , Alan DeKok , Ellen M Deleganes , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] Re: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit On Fri, 2004-10-08 at 10:45, Steven Blake wrote: > On Thu, 2004-10-07 at 12:37, Jamal Hadi Salim wrote: > > > PL level PDU : = MAINHDR+ > > LFBselect := LFBCLASSID+ > > LFBTARGET:=LFBInstance+ > > OPER:= ]*>+ > > > > - MAINHDR defines msg type, Target FE/CE ID etc. > > - LFBCLASSID is a 32 bit unique identifier per LFB class defined > > at class creation time. > > - LFBInstance is a 32 bit unique instance identifier of an LFB class > > - OPERATION is one of {ADD,DEL,GET, ??} > > I suggest that LFBselect and LFBTARGET should be collapsed, like so: > > LFBselect := LFBCLASSID:LFBInstance+ > > If you want to target another instance of LFB class W in a PL-level > PDU, just add an additional LFBselect TLV. > Its a flexibility issue. You end up wasting more bits for the scenario of "class A instance 1,2,3,4,5,6,7,8,..x" imagine X being a large number. If above is not going a common case then i agree. The danger is assuming what a common case is at this point in the design. > I also wonder if we need LFBCLASSID:LFBInstance to be 32:32 instead of > 16:16. We could do this. Note: It would not make any difference in the protocol layout. 16 bits sounds like a good stick-finger-to-check-wind estimate. But if we find we needed a little tiny more, we would have to change the structure of that layout. So after going back and forth we just picked 32 bits. > > path-data identifies the exact element targeted. > > It may have zero or more data values associated. > > > > In summary the described approach has the following characteristic: > > - there can be one or more LFB Classes targeted in a message (batch) > > Ok > > > - there can be one or more LFB instanceids per class targetted (batch) > > Ok, but I would suggest doing that with another LFBselect TLV > Refer to my comments above. > > - There can one or more operation on an addressed LFB instanceid > > (batch) > > Ok > > > - There can be one or more targets per operation (batch) > > Shouldn't this be the other way around: one or more operations per > target? > target in this case implies path targets. So you could have: ADD { [path1,data}, {path2, data} ..} GET { path3, path4, etc} DEL { path7, path 8} Does that make sense? > > - paths may have zero or more data values associated (flexibility) > > You need this for GET. > Indeed. > [snip] > > > path-data > > ---------- > > The layout is still under discussion and so is left out from this > > text. > > > > Each accessible attribute within an LFB is expected to have a 32 bit > > identifier. Attributes that are defined at class definition time > > and which are immutable are reffered as "static". Attributes created > > at runtime are "dynamic" - example a table row is "dynamic". > > > > The path-data will have a map derived from the static as well as > > dynamic IDs. > > This is the first I've heard of attributes that are "created at > runtime", and not defined in the class definition. I have no idea how > this would work. > This is my fault. But lets see if we can come up with proper wording. In the simple case of NOOP LFB which has a table of dummy structs; each dummy struct constituing a u32 foo1 and u32 foo2 then the following is true of path map: a) datatable and foo1, foo2 identifiers are defined at class definition time. b) table indexes are created post class definition at runtime. its b) above that is refered to as "dynamic" What would be more approriate terminology? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 8 12:55:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10428 for ; Fri, 8 Oct 2004 12:55:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFyBR-0002qK-FT for forces-protocol-web-archive@ietf.org; Fri, 08 Oct 2004 13:05:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFxw4-0004jH-IM; Fri, 08 Oct 2004 12:49:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFxui-0004Sk-BK for forces-protocol@megatron.ietf.org; Fri, 08 Oct 2004 12:48:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09987 for ; Fri, 8 Oct 2004 12:48:15 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFy4f-0002hR-D5 for forces-protocol@ietf.org; Fri, 08 Oct 2004 12:58:34 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i98Gm4Fi009094; Fri, 8 Oct 2004 16:48:05 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i98GcnVI032328; Fri, 8 Oct 2004 16:38:51 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100809473115450 ; Fri, 08 Oct 2004 09:47: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.0); Fri, 8 Oct 2004 09:47:29 -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 Date: Fri, 8 Oct 2004 09:47:14 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791A7@orsmsx408> Thread-Topic: ForCES protocol update for the IETF Thread-Index: AcStO3DKy1jm/zYhQGqN/L7tPBXkQQAGsuFw From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 08 Oct 2004 16:47:29.0784 (UTC) FILETIME=[7FE6C780:01C4AD56] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org, avri@psg.com, "Putzolu, David" , donglg@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] RE: ForCES protocol update for the IETF X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Thanks Jamal. I am not sure if we need a concall...team pls let me know about this soon with your day/time preference? In the mean time, we can start updating our sections and send out emails along those lines. Regards Hormuzd=20 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Friday, October 08, 2004 6:34 AM To: Khosravi, Hormuzd M Cc: wmwang@mail.hzic.edu.cn; avri@psg.com; ram.gopal@nokia.com; donglg@mail.hzic.edu.cn; Robert Haas; forces-protocol@ietf.org; Putzolu, David Subject: Re: ForCES protocol update for the IETF Hormuzd, Good stuff, lets get moving. One of the things to immediately look at is the effect of the model team into the existing draft. Lets hope everyone reviews before the concall. cheers, jamal On Thu, 2004-10-07 at 17:33, Khosravi, Hormuzd M wrote: > Hi Team, >=20 > Sorry I haven't been much in touch for the last couple of weeks, > extremely busy with other things at work. The deadline for draft > submission for this IETF is the Oct 25th which is coming up pretty soon. > We made a lot of progress before the last IETF and I hope to continue > with that momentum. Some of the reasons for our success was timelines > and distribution of work...so I will try the same again. >=20 > Here are some timelines we can use... >=20 > Now - Oct 15th - Individual owners update their respective sections acc. > to the comments we have received and discussions with the protocol team > Oct 15th - Oct 22nd - Discuss the updates and start incorporating the > text into the drafts. >=20 > Does this sound reasonable ? If you guys would like to have a conference > call early next week, let me know...although I guess this might not be > needed at the moment. >=20 > Here are the section owners/volunteers (from last draft)-=20 >=20 > Abstract - Avri > 1. Introduction - Avri > 2. Definitions - Weiming > 3. Protocol Overview - Jamal > 4. TML Requirements - Jamal > 5. Common Header - Weiming, Ligang (Jamal/Robert) > 6. Protocol Messages - Hormuzd, Weiming (I expect everyone to be > involved with this one) > 7. Protocol Scenarios - Hormuzd, Ram > 8. High Availability - Hormuzd > 9. Security Considerations - Ram > 10. References - Avri > 11. Acknowledgments - All > Appendix > A. Implementation Notes - All? >=20 > Pls let us know your thoughts on any of this, >=20 > Thanks > Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 8 17:53:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21198 for ; Fri, 8 Oct 2004 17:53:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2po-0005uK-Og for forces-protocol-web-archive@ietf.org; Fri, 08 Oct 2004 18:03:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2ZL-0007wC-9J; Fri, 08 Oct 2004 17:46:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG2Tf-0004qv-Q0 for forces-protocol@megatron.ietf.org; Fri, 08 Oct 2004 17:40:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20097 for ; Fri, 8 Oct 2004 17:40:37 -0400 (EDT) Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG2de-0005a4-KU for forces-protocol@ietf.org; Fri, 08 Oct 2004 17:50:59 -0400 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.41) id 1CG2Sp-0002k9-1m; Fri, 08 Oct 2004 17:39:47 -0400 From: Steven Blake To: hadi@znyx.com In-Reply-To: <1097249647.1076.28.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <5.1.0.14.0.20040914134714.02497d00@mail.megisto.com> <1095186094.1032.53.camel@jzny.localdomain> <1097167049.1045.6.camel@jzny.localdomain> <1097246704.2341.124.camel@localhost.localdomain> <1097249647.1076.28.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1097271582.11637.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 08 Oct 2004 17:39:42 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, avri@psg.com, forces-protocol@ietf.org, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , "Joel M. Halpern" , Alan DeKok , Ellen M Deleganes , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] Re: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit On Fri, 2004-10-08 at 11:34, Jamal Hadi Salim wrote: > On Fri, 2004-10-08 at 10:45, Steven Blake wrote: > > On Thu, 2004-10-07 at 12:37, Jamal Hadi Salim wrote: > > > > > PL level PDU : = MAINHDR+ > > > LFBselect := LFBCLASSID+ > > > LFBTARGET:=LFBInstance+ > > > OPER:= ]*>+ > > > > > > - MAINHDR defines msg type, Target FE/CE ID etc. > > > - LFBCLASSID is a 32 bit unique identifier per LFB class defined > > > at class creation time. > > > - LFBInstance is a 32 bit unique instance identifier of an LFB class > > > - OPERATION is one of {ADD,DEL,GET, ??} > > > > I suggest that LFBselect and LFBTARGET should be collapsed, like so: > > > > LFBselect := LFBCLASSID:LFBInstance+ > > > > If you want to target another instance of LFB class W in a PL-level > > PDU, just add an additional LFBselect TLV. > > > > Its a flexibility issue. You end up wasting more bits for the scenario > of "class A instance 1,2,3,4,5,6,7,8,..x" > imagine X being a large number. > If above is not going a common case then i agree. The danger is assuming > what a common case is at this point in the design. Assuming T:L is 16:16 bits, in your proposal (split LFBCLASSID and LFBInstance specification into two TLVs) there are 32 wasted bits every time a new LFBCLASSID needs to be specified (relative to my proposal), while in my proposal (collapse them into one TLV) there are 32 wasted bits every time a new instance is specified for the same class (relative to your proposal). For the case where one class/instance needs to be specified in the PL message, your proposal has 32 bits of additional overhead (relative to mine). My gut feel is that is that my proposal will wind up being more efficient, but it is noise either way. Collapsing them into one TLV is one less TLV to worry about in the spec. > > I also wonder if we need LFBCLASSID:LFBInstance to be 32:32 instead of > > 16:16. > > We could do this. > Note: It would not make any difference in the protocol > layout. 16 bits sounds like a good stick-finger-to-check-wind estimate. > But if we find we needed a little tiny more, we would have to change the > structure of that layout. So after going back and forth we just picked > 32 bits. And you are worried about overhead? :) I'm satisfied either way, but I really think 16:16 is a safe choice. > > > path-data identifies the exact element targeted. > > > It may have zero or more data values associated. > > > > > > In summary the described approach has the following characteristic: > > > - there can be one or more LFB Classes targeted in a message (batch) > > > > Ok > > > > > - there can be one or more LFB instanceids per class targetted (batch) > > > > Ok, but I would suggest doing that with another LFBselect TLV > > > > Refer to my comments above. > > > > - There can one or more operation on an addressed LFB instanceid > > > (batch) > > > > Ok > > > > > - There can be one or more targets per operation (batch) > > > > Shouldn't this be the other way around: one or more operations per > > target? > > > > target in this case implies path targets. > So you could have: > ADD { [path1,data}, {path2, data} ..} > GET { path3, path4, etc} > DEL { path7, path 8} > > Does that make sense? Yeah, but I don't like it. Now you have to have a more complicated OPER TLV header to specify how many {path, data} sets it contains. In the end it will probably be much simpler to stick to one {path, data} set per-OPER TLV. > > > - paths may have zero or more data values associated (flexibility) > > > > You need this for GET. > > > > Indeed. > > > [snip] > > > > > path-data > > > ---------- > > > The layout is still under discussion and so is left out from this > > > text. > > > > > > Each accessible attribute within an LFB is expected to have a 32 bit > > > identifier. Attributes that are defined at class definition time > > > and which are immutable are reffered as "static". Attributes created > > > at runtime are "dynamic" - example a table row is "dynamic". > > > > > > The path-data will have a map derived from the static as well as > > > dynamic IDs. > > > > This is the first I've heard of attributes that are "created at > > runtime", and not defined in the class definition. I have no idea how > > this would work. > > > > This is my fault. But lets see if we can come up with proper wording. > In the simple case of NOOP LFB which has a table of dummy structs; each > dummy struct constituing a u32 foo1 and u32 foo2 then the following is > true of path map: > a) datatable and foo1, foo2 identifiers are defined at class definition > time. > b) table indexes are created post class definition at runtime. > > its b) above that is refered to as "dynamic" > > What would be more approriate terminology? Yes. Now I understand. Regards, // Steve _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 8 20:45:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05238 for ; Fri, 8 Oct 2004 20:45:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG5W9-0001Iz-GC for forces-protocol-web-archive@ietf.org; Fri, 08 Oct 2004 20:55:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG5Et-0000Mw-W2; Fri, 08 Oct 2004 20:37:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG5Am-00072p-9o for forces-protocol@megatron.ietf.org; Fri, 08 Oct 2004 20:33:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04493 for ; Fri, 8 Oct 2004 20:33:18 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG5Km-00014F-P2 for forces-protocol@ietf.org; Fri, 08 Oct 2004 20:43:41 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004100817355047:18881 ; Fri, 8 Oct 2004 17:35:50 -0700 From: Jamal Hadi Salim To: Steve Blake In-Reply-To: <1097271582.11637.22.camel@localhost.localdomain> References: <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <5.1.0.14.0.20040914134714.02497d00@mail.megisto.com> <1095186094.1032.53.camel@jzny.localdomain> <1097167049.1045.6.camel@jzny.localdomain> <1097246704.2341.124.camel@localhost.localdomain> <1097249647.1076.28.camel@jzny.localdomain> <1097271582.11637.22.camel@localhost.localdomain> Organization: ZNYX Networks Message-Id: <1097281985.1052.143.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 08 Oct 2004 20:33:05 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/08/2004 05:35:51 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/08/2004 05:36:01 PM, Serialize complete at 10/08/2004 05:36:01 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, avri@psg.com, forces-protocol@ietf.org, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , "Joel M. Halpern" , Alan DeKok , Ellen M Deleganes , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] Re: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit On Fri, 2004-10-08 at 17:39, Steven Blake wrote: > On Fri, 2004-10-08 at 11:34, Jamal Hadi Salim wrote: [..] > > Its a flexibility issue. You end up wasting more bits for the scenario > > of "class A instance 1,2,3,4,5,6,7,8,..x" > > imagine X being a large number. > > If above is not going a common case then i agree. The danger is assuming > > what a common case is at this point in the design. > > Assuming T:L is 16:16 bits, in your proposal (split LFBCLASSID and > LFBInstance specification into two TLVs) there are 32 wasted bits > every time a new LFBCLASSID needs to be specified (relative to my > proposal), yes. > while in my proposal (collapse them into one TLV) there are > 32 wasted bits every time a new instance is specified for the same class > (relative to your proposal). yes > For the case where one class/instance > needs to be specified in the PL message, your proposal has 32 bits of > additional overhead (relative to mine). > yes > My gut feel is that is that my proposal will wind up being more > efficient, but it is noise either way. Collapsing them into one TLV is > one less TLV to worry about in the spec. > The proposal has optimization for _many instances_ in one class. Your proposal has one less TLV hierachy and uses less bits if there was one instance per class. I think the breakeven point you start gaining is at around 1.5 factor. Start going into two instances or even more interesting go into 10 (I have 6 LPM tables in a chip i use which typically are to be updated with the same data in the brute force scheme) and it clearly becomes beneficial to have it the way the doc positions it. (I should say most of the chips I work with tend to have multiple instances of the same tables for classification efficiency purposes) OTOH, this may not be a very common case - in which case we should optimize towards what you propose. I am indifferent - I like it the way it is but if people say its not the common case, we should change it. It is common case for me. > > > I also wonder if we need LFBCLASSID:LFBInstance to be 32:32 instead of > > > 16:16. > > > > We could do this. > > Note: It would not make any difference in the protocol > > layout. 16 bits sounds like a good stick-finger-to-check-wind estimate. > > But if we find we needed a little tiny more, we would have to change the > > structure of that layout. So after going back and forth we just picked > > 32 bits. > > And you are worried about overhead? :) > > I'm satisfied either way, but I really think 16:16 is a safe choice. 16:16 sounds like a safe choice. We could go 16:16; Joel and I doodled on this for a while. The logic is it is easier to just make it 32 bits now and not worry about extending it for a lot longer. If people wanna go 16:16 then i am fine with it. > > target in this case implies path targets. > > So you could have: > > ADD { [path1,data}, {path2, data} ..} > > GET { path3, path4, etc} > > DEL { path7, path 8} > > > > Does that make sense? > > Yeah, but I don't like it. Now you have to have a more complicated OPER > TLV header to specify how many {path, data} sets it contains. In the > end it will probably be much simpler to stick to one {path, data} set > per-OPER TLV. > I dont think it will be that complicated or adds additional compute cost. If you look at { pathx, data} as a TLV, then what you have is a series of TLVs in the same hierachy level. I could enumerate possible layouts for what you guys proposed for the table index proposal - I was hoping to do that later. > > This is my fault. But lets see if we can come up with proper wording. > > In the simple case of NOOP LFB which has a table of dummy structs; each > > dummy struct constituing a u32 foo1 and u32 foo2 then the following is > > true of path map: > > a) datatable and foo1, foo2 identifiers are defined at class definition > > time. > > b) table indexes are created post class definition at runtime. > > > > its b) above that is refered to as "dynamic" > > > > What would be more approriate terminology? > > Yes. Now I understand. > Is the term "dynamic" then acceptable? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 9 00:52:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28578 for ; Sat, 9 Oct 2004 00:52:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG9NP-0005PM-LF for forces-protocol-web-archive@ietf.org; Sat, 09 Oct 2004 01:02:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG9CC-0000wB-MC; Sat, 09 Oct 2004 00:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CG9Bm-0000hJ-U7 for forces-protocol@megatron.ietf.org; Sat, 09 Oct 2004 00:50:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28506 for ; Sat, 9 Oct 2004 00:50:35 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CG9Lo-0005Mg-5I for forces-protocol@ietf.org; Sat, 09 Oct 2004 01:01:01 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i994nKul009605; Sat, 9 Oct 2004 04:49:20 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i994rIhd003171; Sat, 9 Oct 2004 04:53:18 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004100821495406808 ; Fri, 08 Oct 2004 21:49:54 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 8 Oct 2004 21:49:54 -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 Date: Fri, 8 Oct 2004 21:49:36 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791AF@orsmsx408> Thread-Topic: updated notes on BNF and layout Thread-Index: AcStRYIU/K9A2rcdTtGG4FWavK3kpAAdJXaQ From: "Khosravi, Hormuzd M" To: "Steven Blake" , X-OriginalArrivalTime: 09 Oct 2004 04:49:54.0353 (UTC) FILETIME=[6B472210:01C4ADBB] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, avri@psg.com, forces-protocol@ietf.org, donglg@mail.hzic.edu.cn, zsolt@petri-meat.com, "Yang, Lily L" , "Joel M. Halpern" , Alan DeKok , "Deleganes, Ellen M" , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] RE: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Steve, What you have proposed below is exactly what we already have in the protocol today i.e. LFBCLASSID:LFBInstance+, with LFBCLASSID:LFBInstance be 16:16. It almost seems like we are going in circles at this point. I had the impression that the model team was proposing this different scheme for some reasons...may be not? In any case, what youre suggesting is definitely the more common case i.e. 1 LFB instance is all I have seen in most implementations. Also, 16 bits is quite sufficient. The important thing at this point is we should atleast get a single recommendation from the model team, the protocol team will eventually decide the no of bits, etc but it would help if we don't keep going back and forth on these issues. regards Hormuzd -----Original Message----- From: Steven Blake [mailto:slblake@petri-meat.com]=20 Sent: Friday, October 08, 2004 7:45 AM To: hadi@znyx.com Cc: Joel M. Halpern; ram.gopal@nokia.com; avri@psg.com; donglg@mail.hzic.edu.cn; Khosravi, Hormuzd M; zsolt@petri-meat.com; Yang, Lily L; forces-protocol@ietf.org; Alan DeKok; Deleganes, Ellen M; wmwang@mail.hzic.edu.cn; Robert Haas Subject: Re: updated notes on BNF and layout On Thu, 2004-10-07 at 12:37, Jamal Hadi Salim wrote: > PL level PDU : =3D MAINHDR+=20 > LFBselect :=3D LFBCLASSID+ > LFBTARGET:=3DLFBInstance+ > OPER:=3D ]*>+ > > - MAINHDR defines msg type, Target FE/CE ID etc. > - LFBCLASSID is a 32 bit unique identifier per LFB class defined > at class creation time. > - LFBInstance is a 32 bit unique instance identifier of an LFB class > - OPERATION is one of {ADD,DEL,GET, ??} I suggest that LFBselect and LFBTARGET should be collapsed, like so: LFBselect :=3D LFBCLASSID:LFBInstance+ If you want to target another instance of LFB class W in a PL-level PDU, just add an additional LFBselect TLV. I also wonder if we need LFBCLASSID:LFBInstance to be 32:32 instead of 16:16. > path-data identifies the exact element targeted. > It may have zero or more data values associated. > > In summary the described approach has the following characteristic: > - there can be one or more LFB Classes targeted in a message (batch) Ok > - there can be one or more LFB instanceids per class targetted (batch) Ok, but I would suggest doing that with another LFBselect TLV > - There can one or more operation on an addressed LFB instanceid=20 > (batch) Ok > - There can be one or more targets per operation (batch) Shouldn't this be the other way around: one or more operations per target? > - paths may have zero or more data values associated (flexibility) You need this for GET. [snip] > path-data > ---------- > The layout is still under discussion and so is left out from this=20 > text. > > Each accessible attribute within an LFB is expected to have a 32 bit > identifier. Attributes that are defined at class definition time=20 > and which are immutable are reffered as "static". Attributes created > at runtime are "dynamic" - example a table row is "dynamic". > > The path-data will have a map derived from the static as well as=20 > dynamic IDs. This is the first I've heard of attributes that are "created at runtime", and not defined in the class definition. I have no idea how this would work. Regards, // Steve _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 10 01:16:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00536 for ; Sun, 10 Oct 2004 01:16:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGWE5-0004Ok-9w for forces-protocol-web-archive@ietf.org; Sun, 10 Oct 2004 01:26:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGW2w-0007TE-Na; Sun, 10 Oct 2004 01:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGW26-0007M2-8L for forces-protocol@megatron.ietf.org; Sun, 10 Oct 2004 01:14:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00433 for ; Sun, 10 Oct 2004 01:14:09 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGWCB-0004Ms-D2 for forces-protocol@ietf.org; Sun, 10 Oct 2004 01:24:46 -0400 Received: from JLaptop.megisto.com ([192.168.20.228]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 10 Oct 2004 01:13:36 -0400 Message-Id: <5.1.0.14.0.20041010010702.0233a138@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 10 Oct 2004 01:13:10 -0400 To: hadi@znyx.com From: "Joel M. Halpern" In-Reply-To: <1097167049.1045.6.camel@jzny.localdomain> References: <1095186094.1032.53.camel@jzny.localdomain> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <5.1.0.14.0.20040914134714.02497d00@mail.megisto.com> <1095186094.1032.53.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Oct 2004 05:13:37.0095 (UTC) FILETIME=[E5B61570:01C4AE87] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ram.gopal@nokia.com, Steve Blake , avri@psg.com, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] Re: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Just to clarify one aspect, the separation of class and instance into TLVs is an idea I can live with, but one I personally do not consider necessary. (Jamal and I went back and forth on that in trying to arrive at the compromise he summarized that we both can live with.) It does seem (from other discussions) that there is rough consensus on including the class explicitly in the message, rather than having the remote end infer it from other tables. THis does make debugging easier, which is probably enough reason all by itself. With regard to the sizes of the identifiers, I have a couple of minor comments. Firstly, with regard to the instance identifier size, even within a class, I can imagine an FE with more than 64K worth of LFBs. FOr a simple, if slightly unlikely, case, consider an FE handling an OC48 that is prepared to subchannel it down to DS0s. It may choose to represent each interface with its own LFB. (That is not mandatory, but I can easily imagine it.) With regard to class identifiers, we need to remmber that we have to allow for versioning of classes. It would be nice if that could be easily separated for examination. Which leads to a byte for version in the class id. And we clearly need more than one byte for classes. Thus, I am concluding that 32:32 may be what we need, even though it is ugly. (We could probably do 24:24, but I don't think anyone really wants to go there.) Yours, Joel At 12:37 PM 10/7/2004 -0400, Jamal Hadi Salim wrote: >Joel and myself have put an update to the earlier doc. Its now a >singular view. The issue on the tables and attribute update is open >pending on discussions on the table doc currently being discussed. >The decision on how things get laid out is in the hands of the protocol >team although this document bridges a lot of the views between the model >and the protocol side of things and so is a very good start. > >Lets please start the ball rolling again on this and discuss. > >cheers, >jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 10 04:24:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22424 for ; Sun, 10 Oct 2004 04:24:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGZAL-0002x7-EB for forces-protocol-web-archive@ietf.org; Sun, 10 Oct 2004 04:34:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGYzR-00006u-RN; Sun, 10 Oct 2004 04:23:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGYyf-0007fW-Bp for forces-protocol@megatron.ietf.org; Sun, 10 Oct 2004 04:22:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22343 for ; Sun, 10 Oct 2004 04:22:46 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CGZ8h-0002uF-Vb for forces-protocol@ietf.org; Sun, 10 Oct 2004 04:33:27 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 88704.341813895; Sun, 10 Oct 2004 16:37:56 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Sun, 10 Oct 2004 16:22:37 +0800 Message-ID: <022c01c4aea1$d225b230$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E025791AF@orsmsx408> Subject: Re: [Forces-protocol] RE: updated notes on BNF and layout Date: Sun, 10 Oct 2004 16:19:10 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: ram.gopal@nokia.com, Steven Blake , avri@psg.com, "Joel M. Halpern" , donglg@mail.hzic.edu.cn, zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Hi, Actually I'm not very sure if it will be extremely important and affect the protocol greatly in terms of things like where to put the LFBtype ID and Instance ID. Although number of bits for the ids are important, they are still quntitative issue instead of qunlitative one, and I think we can have it open for a long period while currently just choose one scheme (16 or 32 bits) , before we can gain experience more and then decide it. I personally think if we should instead pay more attention to issues like below so that we can roll forth more quickly: 1. If such a scheme of LFBClassID:LFBInstanceID is enough to include all cases for LFB addressing. One thing I'v thought of is we may need to do some operations between LFBs. For instance, we may need to establish a datapath between LFBs, and also we may very often need to setup Metadata along two connected LFBs. These all imply it may be much more efficient to address more than one LFB or LFB instances at a time using current scheme (LFBaddressing followed by Op), or to use other scheme like (OpTLV followed by LFBTLVs). For datapath setup, I even cannot think of other way if we address one LFB at a time using current scheme. 2. The Index issue. I'v been trying to understand Joel's idea on the advantage ( easy management ) of Index used at the protocol layer, but based on my testbed implementation, I just find it seems not an easy thing as we may think to do this. I have to do extra things like matching and managing the Index in CE to protocol application layer and matching and managing the Index in FE protocol terminator to base in LFB. Without using this Index, I don't need to pay these extra attentions, just let the protocol application layer directly manage the LFB base. Although I think the above issues worth discussing, I agree with Hormuzd that we protocol team may need to begin the paper work now for the new version protocol draft right now, therefore I can currently live with current scheme, which actually quite the same as we'v had in the current draft, while leaving the above issues for more discussion. Thank you. Weiming BTW, I don't oppose to use concall to solve issues moer quickly, but the list may be more fit for my group to do. ----- Original Message ----- From: "Khosravi, Hormuzd M" Subject: [Forces-protocol] RE: updated notes on BNF and layout Steve, What you have proposed below is exactly what we already have in the protocol today i.e. LFBCLASSID:LFBInstance+, with LFBCLASSID:LFBInstance be 16:16. It almost seems like we are going in circles at this point. I had the impression that the model team was proposing this different scheme for some reasons...may be not? In any case, what youre suggesting is definitely the more common case i.e. 1 LFB instance is all I have seen in most implementations. Also, 16 bits is quite sufficient. The important thing at this point is we should atleast get a single recommendation from the model team, the protocol team will eventually decide the no of bits, etc but it would help if we don't keep going back and forth on these issues. regards Hormuzd -----Original Message----- From: Steven Blake [mailto:slblake@petri-meat.com] Sent: Friday, October 08, 2004 7:45 AM To: hadi@znyx.com Cc: Joel M. Halpern; ram.gopal@nokia.com; avri@psg.com; donglg@mail.hzic.edu.cn; Khosravi, Hormuzd M; zsolt@petri-meat.com; Yang, Lily L; forces-protocol@ietf.org; Alan DeKok; Deleganes, Ellen M; wmwang@mail.hzic.edu.cn; Robert Haas Subject: Re: updated notes on BNF and layout On Thu, 2004-10-07 at 12:37, Jamal Hadi Salim wrote: > PL level PDU : = MAINHDR+ > LFBselect := LFBCLASSID+ > LFBTARGET:=LFBInstance+ > OPER:= ]*>+ > > - MAINHDR defines msg type, Target FE/CE ID etc. > - LFBCLASSID is a 32 bit unique identifier per LFB class defined > at class creation time. > - LFBInstance is a 32 bit unique instance identifier of an LFB class > - OPERATION is one of {ADD,DEL,GET, ??} I suggest that LFBselect and LFBTARGET should be collapsed, like so: LFBselect := LFBCLASSID:LFBInstance+ If you want to target another instance of LFB class W in a PL-level PDU, just add an additional LFBselect TLV. I also wonder if we need LFBCLASSID:LFBInstance to be 32:32 instead of 16:16. > path-data identifies the exact element targeted. > It may have zero or more data values associated. > > In summary the described approach has the following characteristic: > - there can be one or more LFB Classes targeted in a message (batch) Ok > - there can be one or more LFB instanceids per class targetted (batch) Ok, but I would suggest doing that with another LFBselect TLV > - There can one or more operation on an addressed LFB instanceid > (batch) Ok > - There can be one or more targets per operation (batch) Shouldn't this be the other way around: one or more operations per target? > - paths may have zero or more data values associated (flexibility) You need this for GET. [snip] > path-data > ---------- > The layout is still under discussion and so is left out from this > text. > > Each accessible attribute within an LFB is expected to have a 32 bit > identifier. Attributes that are defined at class definition time > and which are immutable are reffered as "static". Attributes created > at runtime are "dynamic" - example a table row is "dynamic". > > The path-data will have a map derived from the static as well as > dynamic IDs. This is the first I've heard of attributes that are "created at runtime", and not defined in the class definition. I have no idea how this would work. Regards, // Steve _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 10 11:41:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19758 for ; Sun, 10 Oct 2004 11:41:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGfz4-0001Bc-Fx for forces-protocol-web-archive@ietf.org; Sun, 10 Oct 2004 11:51:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGfll-0005LA-65; Sun, 10 Oct 2004 11:37:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGfkl-0005CY-FF for forces-protocol@megatron.ietf.org; Sun, 10 Oct 2004 11:36:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19387 for ; Sun, 10 Oct 2004 11:36:53 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGfux-00016b-Hq for forces-protocol@ietf.org; Sun, 10 Oct 2004 11:47:38 -0400 Received: from JLaptop.megisto.com ([192.168.20.233]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 10 Oct 2004 11:36:38 -0400 Message-Id: <5.1.0.14.0.20041010113017.0231ed20@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 10 Oct 2004 11:36:07 -0400 To: "Wang,Weiming" , "Khosravi, Hormuzd M" From: "Joel M. Halpern" Subject: Re: [Forces-protocol] RE: updated notes on BNF and layout In-Reply-To: <022c01c4aea1$d225b230$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E025791AF@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Oct 2004 15:36:38.0613 (UTC) FILETIME=[EED51050:01C4AEDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram.gopal@nokia.com, Steven Blake , avri@psg.com, donglg@mail.hzic.edu.cn, zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 My current view (and I could be mistaken) is that this will generally actually be easier by addressing specific LFBs. Setting up a data path segment is done by updating tables in the FE object. For metadata to be passed between LFBs there are actually potentially two different operations. One (which may already be done for receiving data from some third LFB) to set up the receive processing, typically creating a table entry, and one on the sending LFB to fill in what metadata to send. These are different updates and we ought not combine them into a single operation. Note that it is valid using this identification scheme and the generally proposed protocol structure, to include updates to multiple LFBs in the same request. I would expect that to be common. would however expect those to be different updates to the different LFBs, not a single update to multiple LFBs in the FE. There are some cases where multiple LFBs may need changing (for example if the CE decides to change a configuration timer that is used in multiple places in the FE.) I do not see this as the common case. With regard to the table structuruing, I suspect I am misreading your note, so I am having trouble responding in a helpful clarifying fashion. The only thing I can think to articulate at this point (which is probably not the aspect you don't see in your code) is that I assume that the CE is maintaining a set of tables that mirror the FE state. It is the presence of those tables that make the indexing practical. Yours, Joel At 04:19 PM 10/10/2004 +0800, Wang,Weiming wrote: >1. If such a scheme of LFBClassID:LFBInstanceID is enough to include all cases >for LFB addressing. >One thing I'v thought of is we may need to do some operations between >LFBs. For >instance, we may need to establish a datapath between LFBs, and also we >may very >often need to setup Metadata along two connected LFBs. These all imply it >may be >much more efficient to address more than one LFB or LFB instances at a time >using current scheme (LFBaddressing followed by Op), or to use other >scheme like >(OpTLV followed by LFBTLVs). For datapath setup, I even cannot think of other >way if we address one LFB at a time using current scheme. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 10 15:22:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04102 for ; Sun, 10 Oct 2004 15:22:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGjQy-0005BV-F7 for forces-protocol-web-archive@ietf.org; Sun, 10 Oct 2004 15:32:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGjGR-0002PV-1R; Sun, 10 Oct 2004 15:21:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGjAD-00081K-5k for forces-protocol@megatron.ietf.org; Sun, 10 Oct 2004 15:15:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03505 for ; Sun, 10 Oct 2004 15:15:22 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGjKa-00055f-Lc for forces-protocol@ietf.org; Sun, 10 Oct 2004 15:26:09 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101012175913:19911 ; Sun, 10 Oct 2004 12:17:59 -0700 From: Jamal Hadi Salim To: "Joel M. Halpern" In-Reply-To: <5.1.0.14.0.20041010010702.0233a138@mail.megisto.com> References: <1095186094.1032.53.camel@jzny.localdomain> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <5.1.0.14.0.20040914134714.02497d00@mail.megisto.com> <1095186094.1032.53.camel@jzny.localdomain> <5.1.0.14.0.20041010010702.0233a138@mail.megisto.com> Organization: ZNYX Networks Message-Id: <1097435715.1049.202.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Oct 2004 15:15:15 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/10/2004 12:17:59 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/10/2004 12:18:04 PM, Serialize complete at 10/10/2004 12:18:04 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Steve Blake , avri@psg.com, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] Re: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit On Sun, 2004-10-10 at 01:13, Joel M. Halpern wrote: > Just to clarify one aspect, the separation of class and instance into TLVs > is an idea I can live with, but one I personally do not consider > necessary. (Jamal and I went back and forth on that in trying to arrive at > the compromise he summarized that we both can live with.) > I am also indifferent to whether class and instance identifiers are in two different TLV or the same one. What would be nice however is to do a technical evaluation and explore the pros/cons of each scheme. To remind people, the pros/cons: 1) Both items in one TLV Has advantage if the common case is going to be one of PL message constituting a target of _one Class and one instance of that class_. 2) Items on two different TLVs Has advantage if #1 above is not true. My thinking is we dont know the answer to the above, hence #2 is safer. Again lets evaluate, hopefuly without reasons which sound like "we have done it like this before" - that does not fit as a technical evaluation. Its an excuse. > With regard to the sizes of the identifiers, I have a couple of minor comments. > Firstly, with regard to the instance identifier size, even within a class, > I can imagine an FE with more than 64K worth of LFBs. did you mean 64K instances of a LFB class? > FOr a simple, if > slightly unlikely, case, consider an FE handling an OC48 that is prepared > to subchannel it down to DS0s. It may choose to represent each interface > with its own LFB. (That is not mandatory, but I can easily imagine it.) > With regard to class identifiers, we need to remmber that we have to allow > for versioning of classes. It would be nice if that could be easily > separated for examination. Which leads to a byte for version in the class > id. And we clearly need more than one byte for classes. > > Thus, I am concluding that 32:32 may be what we need, even though it is > ugly. (We could probably do 24:24, but I don't think anyone really wants > to go there.) Thanks for bringing this example. Again iam also indifferent on the size. I prefer to err by increasing the bit sizes to 32 from 16. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 10 15:23:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04187 for ; Sun, 10 Oct 2004 15:23:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGjSq-0005DJ-Hk for forces-protocol-web-archive@ietf.org; Sun, 10 Oct 2004 15:34:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGjHZ-00033U-6t; Sun, 10 Oct 2004 15:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGjHJ-0002rh-TA for forces-protocol@megatron.ietf.org; Sun, 10 Oct 2004 15:22:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04136 for ; Sun, 10 Oct 2004 15:22:43 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGjRh-0005CB-9n for forces-protocol@ietf.org; Sun, 10 Oct 2004 15:33:29 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101012252274:19919 ; Sun, 10 Oct 2004 12:25:22 -0700 From: Jamal Hadi Salim To: "Wang,Weiming" In-Reply-To: <022c01c4aea1$d225b230$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E025791AF@orsmsx408> <022c01c4aea1$d225b230$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1097436159.1047.209.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Oct 2004 15:22:39 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/10/2004 12:25:23 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/10/2004 12:25:25 PM, Serialize complete at 10/10/2004 12:25:25 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Steve Blake , avri@psg.com, forces-protocol@ietf.org, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , "Joel M. Halpern" , Alan DeKok , Ellen M Deleganes , Robert Haas Subject: [Forces-protocol] LFB dependencies WAS(Re: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7bit >From Weimings posting, something else that is probably related (since he mentions inter LFB metadatum): LFB dependencies. As an example (not sure if its a good example) consider a LPM/NH LFB may require that a port LFB being in existence and probably both admin&oper up before it can consider whatever state it is being populated with is valid. I dont think the LFB topology layout is sufficient. Is this something expected in the xml template for the LFB? I am just recovering from a bad flu - brain a little slow so i may be asking the obvious. cheers, jamal On Sun, 2004-10-10 at 04:19, Wang,Weiming wrote: > Hi, > > Actually I'm not very sure if it will be extremely important and affect the > protocol greatly in terms of things like where to put the LFBtype ID and > Instance ID. Although number of bits for the ids are important, they are still > quntitative issue instead of qunlitative one, and I think we can have it open > for a long period while currently just choose one scheme (16 or 32 bits) , > before we can gain experience more and then decide it. > > I personally think if we should instead pay more attention to issues like below > so that we can roll forth more quickly: > > 1. If such a scheme of LFBClassID:LFBInstanceID is enough to include all cases > for LFB addressing. > One thing I'v thought of is we may need to do some operations between LFBs. For > instance, we may need to establish a datapath between LFBs, and also we may very > often need to setup Metadata along two connected LFBs. These all imply it may be > much more efficient to address more than one LFB or LFB instances at a time > using current scheme (LFBaddressing followed by Op), or to use other scheme like > (OpTLV followed by LFBTLVs). For datapath setup, I even cannot think of other > way if we address one LFB at a time using current scheme. > > 2. The Index issue. > I'v been trying to understand Joel's idea on the advantage ( easy management ) > of Index used at the protocol layer, but based on my testbed implementation, I > just find it seems not an easy thing as we may think to do this. I have to do > extra things like matching and managing the Index in CE to protocol application > layer and matching and managing the Index in FE protocol terminator to base in > LFB. Without using this Index, I don't need to pay these extra attentions, just > let the protocol application layer directly manage the LFB base. > > Although I think the above issues worth discussing, I agree with Hormuzd that we > protocol team may need to begin the paper work now for the new version protocol > draft right now, therefore I can currently live with current scheme, which > actually quite the same as we'v had in the current draft, while leaving the > above issues for more discussion. > > Thank you. > Weiming > > BTW, I don't oppose to use concall to solve issues moer quickly, but the list > may be more fit for my group to do. > > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > Subject: [Forces-protocol] RE: updated notes on BNF and layout > > > Steve, > > What you have proposed below is exactly what we already have in the > protocol today i.e. LFBCLASSID:LFBInstance+, with > LFBCLASSID:LFBInstance be 16:16. It almost seems like we are going in > circles at this point. I had the impression that the model team was > proposing this different scheme for some reasons...may be not? > > In any case, what youre suggesting is definitely the more common case > i.e. 1 LFB instance is all I have seen in most implementations. Also, 16 > bits is quite sufficient. The important thing at this point is we should > atleast get a single recommendation from the model team, the protocol > team will eventually decide the no of bits, etc but it would help if we > don't keep going back and forth on these issues. > > regards > Hormuzd > > -----Original Message----- > From: Steven Blake [mailto:slblake@petri-meat.com] > Sent: Friday, October 08, 2004 7:45 AM > To: hadi@znyx.com > Cc: Joel M. Halpern; ram.gopal@nokia.com; avri@psg.com; > donglg@mail.hzic.edu.cn; Khosravi, Hormuzd M; zsolt@petri-meat.com; > Yang, Lily L; forces-protocol@ietf.org; Alan DeKok; Deleganes, Ellen M; > wmwang@mail.hzic.edu.cn; Robert Haas > Subject: Re: updated notes on BNF and layout > > On Thu, 2004-10-07 at 12:37, Jamal Hadi Salim wrote: > > > PL level PDU : = MAINHDR+ > > LFBselect := LFBCLASSID+ > > LFBTARGET:=LFBInstance+ > > OPER:= ]*>+ > > > > - MAINHDR defines msg type, Target FE/CE ID etc. > > - LFBCLASSID is a 32 bit unique identifier per LFB class defined > > at class creation time. > > - LFBInstance is a 32 bit unique instance identifier of an LFB class > > - OPERATION is one of {ADD,DEL,GET, ??} > > I suggest that LFBselect and LFBTARGET should be collapsed, like so: > > LFBselect := LFBCLASSID:LFBInstance+ > > If you want to target another instance of LFB class W in a PL-level > PDU, just add an additional LFBselect TLV. > > I also wonder if we need LFBCLASSID:LFBInstance to be 32:32 instead of > 16:16. > > > path-data identifies the exact element targeted. > > It may have zero or more data values associated. > > > > In summary the described approach has the following characteristic: > > - there can be one or more LFB Classes targeted in a message (batch) > > Ok > > > - there can be one or more LFB instanceids per class targetted (batch) > > Ok, but I would suggest doing that with another LFBselect TLV > > > - There can one or more operation on an addressed LFB instanceid > > (batch) > > Ok > > > - There can be one or more targets per operation (batch) > > Shouldn't this be the other way around: one or more operations per > target? > > > - paths may have zero or more data values associated (flexibility) > > You need this for GET. > > [snip] > > > path-data > > ---------- > > The layout is still under discussion and so is left out from this > > text. > > > > Each accessible attribute within an LFB is expected to have a 32 bit > > identifier. Attributes that are defined at class definition time > > and which are immutable are reffered as "static". Attributes created > > at runtime are "dynamic" - example a table row is "dynamic". > > > > The path-data will have a map derived from the static as well as > > dynamic IDs. > > This is the first I've heard of attributes that are "created at > runtime", and not defined in the class definition. I have no idea how > this would work. > > > Regards, > > // Steve > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 10 15:54:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06457 for ; Sun, 10 Oct 2004 15:54:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGjw2-0005ty-09 for forces-protocol-web-archive@ietf.org; Sun, 10 Oct 2004 16:04:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGjcj-0003eY-VN; Sun, 10 Oct 2004 15:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGjbY-000352-4c for forces-protocol@megatron.ietf.org; Sun, 10 Oct 2004 15:43:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05629 for ; Sun, 10 Oct 2004 15:43:38 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGjll-0005Xi-DG for forces-protocol@ietf.org; Sun, 10 Oct 2004 15:54:24 -0400 Received: from JLaptop.megisto.com ([192.168.20.233]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 10 Oct 2004 15:43:27 -0400 Message-Id: <5.1.0.14.0.20041010154243.035f8db8@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 10 Oct 2004 15:42:54 -0400 To: hadi@znyx.com, "Wang,Weiming" From: "Joel M. Halpern" In-Reply-To: <1097436159.1047.209.camel@jzny.localdomain> References: <022c01c4aea1$d225b230$845c21d2@Necom.hzic.edu.cn> <468F3FDA28AA87429AD807992E22D07E025791AF@orsmsx408> <022c01c4aea1$d225b230$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Oct 2004 19:43:27.0845 (UTC) FILETIME=[69D28950:01C4AF01] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ram.gopal@nokia.com, Steve Blake , avri@psg.com, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , Robert Haas Subject: [Forces-protocol] Re: LFB dependencies WAS(Re: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Actually, I would hope that two other aspects will prevent this from being an issue. Firstly, I would expect that usually, the processing LFB can be populated / established / activated with the processing data, with its operation controlled by either the data path sending packets or by packets arriving with the relevant meta-data. Then the access port can be enabled by the CE. Secondly, if we really need to have disabled table entries, I would expect the table entry to have an "enable" flag. Then when it is ready the CE can send a set to the two related LFBs, enabling the related entries. (This is related to why, at least within an FE, one may need atomicity.) Yours, Joel At 03:22 PM 10/10/2004 -0400, Jamal Hadi Salim wrote: > >From Weimings posting, something else that is probably related (since he >mentions inter LFB metadatum): >LFB dependencies. >As an example (not sure if its a good example) consider a LPM/NH LFB may >require that a port LFB being in existence and probably both admin&oper >up before it can consider whatever state it is being populated with is >valid. I dont think the LFB topology layout is sufficient. >Is this something expected in the xml template for the LFB? > >I am just recovering from a bad flu - brain a little slow so i may be >asking the obvious. > >cheers, >jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 10 21:51:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01768 for ; Sun, 10 Oct 2004 21:51:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGpWP-0003i3-7L for forces-protocol-web-archive@ietf.org; Sun, 10 Oct 2004 22:02:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGpDb-00005N-Ca; Sun, 10 Oct 2004 21:43:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGp3S-0007lG-BP for forces-protocol@megatron.ietf.org; Sun, 10 Oct 2004 21:32:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00862 for ; Sun, 10 Oct 2004 21:32:47 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGpDt-0003Py-1e for forces-protocol@ietf.org; Sun, 10 Oct 2004 21:43:37 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101018352621:20080 ; Sun, 10 Oct 2004 18:35:26 -0700 Subject: Re: [Forces-protocol] Re: LFB dependencies WAS(Re: updated notes on BNF and layout From: Jamal Hadi Salim To: "Joel M. Halpern" In-Reply-To: <5.1.0.14.0.20041010154243.035f8db8@mail.megisto.com> References: <022c01c4aea1$d225b230$845c21d2@Necom.hzic.edu.cn> <468F3FDA28AA87429AD807992E22D07E025791AF@orsmsx408> <022c01c4aea1$d225b230$845c21d2@Necom.hzic.edu.cn> <5.1.0.14.0.20041010154243.035f8db8@mail.megisto.com> Organization: ZNYX Networks Message-Id: <1097458362.1049.240.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 10 Oct 2004 21:32:43 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/10/2004 06:35:26 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/10/2004 06:35:29 PM, Serialize complete at 10/10/2004 06:35:29 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Steve Blake , avri@psg.com, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , "Wang, Weiming" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit On Sun, 2004-10-10 at 15:42, Joel M. Halpern wrote: > Actually, I would hope that two other aspects will prevent this from being > an issue. > Firstly, I would expect that usually, the processing LFB can be populated / > established / activated with the processing data, with its operation > controlled by either the data path sending packets or by packets arriving > with the relevant meta-data. Then the access port can be enabled by the CE. > Secondly, if we really need to have disabled table entries, I would expect > the table entry to have an "enable" flag. Then when it is ready the CE can > send a set to the two related LFBs, enabling the related entries. (This is > related to why, at least within an FE, one may need atomicity.) So things like atomicity and possibly 2pc may answer this; But what about runtime events - example a link (port LFB entity) going down and affecting 10 other LFBs? Clearly one could offload these dependency resolutions to the FE, but you seem to be hinting at CE (the all-knower) to be in charge. BTW, "enable" flag is something that needs to be defined at class definition time in all LFBs then? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 11 11:19:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14023 for ; Mon, 11 Oct 2004 11:19:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH28V-0001Nd-5X for forces-protocol-web-archive@ietf.org; Mon, 11 Oct 2004 11:30:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH1x2-0002Cg-Qf; Mon, 11 Oct 2004 11:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH1uw-0001sR-HR for forces-protocol@megatron.ietf.org; Mon, 11 Oct 2004 11:17:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13795 for ; Mon, 11 Oct 2004 11:16:52 -0400 (EDT) Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH25U-0001KF-Sb for forces-protocol@ietf.org; Mon, 11 Oct 2004 11:27:49 -0400 Received: from [204.85.2.252] (helo=[192.168.168.45]) by server26.totalchoicehosting.com with esmtp (Exim 4.43) id 1CH1u0-0006HJ-SR; Mon, 11 Oct 2004 11:15:57 -0400 From: Zsolt Haraszti To: Jamal Hadi Salim In-Reply-To: <1097281985.1052.143.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <5.1.0.14.0.20040914134714.02497d00@mail.megisto.com> <1095186094.1032.53.camel@jzny.localdomain> <1097167049.1045.6.camel@jzny.localdomain> <1097246704.2341.124.camel@localhost.localdomain> <1097249647.1076.28.camel@jzny.localdomain> <1097271582.11637.22.camel@localhost.localdomain> <1097281985.1052.143.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1097507566.3492.75.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 11 Oct 2004 11:12:47 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , avri@psg.com, forces-protocol@ietf.org, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , "Yang, Lily L" , "Joel M. Halpern" , Alan DeKok , Ellen M Deleganes , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] Re: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zsolt@nc.rr.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit On Fri, 2004-10-08 at 20:33, Jamal Hadi Salim wrote: > On Fri, 2004-10-08 at 17:39, Steven Blake wrote: > > On Fri, 2004-10-08 at 11:34, Jamal Hadi Salim wrote: > > [..] > > > Its a flexibility issue. You end up wasting more bits for the scenario > > > of "class A instance 1,2,3,4,5,6,7,8,..x" > > > imagine X being a large number. > > > If above is not going a common case then i agree. The danger is assuming > > > what a common case is at this point in the design. > > > > Assuming T:L is 16:16 bits, in your proposal (split LFBCLASSID and > > LFBInstance specification into two TLVs) there are 32 wasted bits > > every time a new LFBCLASSID needs to be specified (relative to my > > proposal), > > yes. > > > while in my proposal (collapse them into one TLV) there are > > 32 wasted bits every time a new instance is specified for the same class > > (relative to your proposal). > > yes > > > For the case where one class/instance > > needs to be specified in the PL message, your proposal has 32 bits of > > additional overhead (relative to mine). > > > > yes > > > My gut feel is that is that my proposal will wind up being more > > efficient, but it is noise either way. Collapsing them into one TLV is > > one less TLV to worry about in the spec. > > > > The proposal has optimization for _many instances_ in one class. > Your proposal has one less TLV hierachy and uses less bits if there was > one instance per class. I think the breakeven point you start gaining is > at around 1.5 factor. > Start going into two instances or even more interesting go into 10 (I > have 6 LPM tables in a chip i use which typically are to be updated with > the same data in the brute force scheme) and it clearly becomes > beneficial to have it the way the doc positions it. > (I should say most of the chips I work with tend to have multiple > instances of the same tables for classification efficiency purposes) > > OTOH, this may not be a very common case - in which case we should > optimize towards what you propose. > I am indifferent - I like it the way it is but if people say its not the > common case, we should change it. It is common case for me. > The primary purpose of the currently proposed [:] tuple is to provide an FE-unique identifier for each LFB instance of the FE. Strictly speaking, we do not need a structured address (tuple) just for that. A flat numbering schema would suffice. Assuming flat, a 32-bit id would be clearly sufficient (as it is unlikely we will need more than 4 billion LFB instances per FE). (I know that you may compare this to IPv4 and may say "remember?", but this is a different story; the number of LFB instances in an FE should not grow proportionally with the speed or # of users of the Internet.) Structuring the address into a [:] serves only a secondary purpose: diagnostics. I think it is a good purpose. I do not really like to bloat the id to 64-bit just for that purpose, but I can live with that, AS LONG AS THE ID APPEARS AS ONE 64-BIT BLOCK IN THE PROTOCOL. I think it is a very bad idea to split the 64-bit id into 2 separate TLVs. Many entities involved in the ForCES protocol handling will not care about the class and would like to treat the LFB instance ID as a flat logical address. For these, it is a benefit if the id is in one continuous block in the PL payload. > > > > b) table indexes are created post class definition at runtime. > > > > > > its b) above that is refered to as "dynamic" > > > > > > What would be more approriate terminology? > > > > Yes. Now I understand. > > > > Is the term "dynamic" then acceptable? > Not for attributes. In the terminology used in the model, attribute refers to the top-level attributes of the class (thinks about these as the local variables of a C++ class). These are defined in the class specification, hence are static. Attributes may include tables with variable content. Yes, entries in such tables are typically dynamic. But we should not call these table entries attributes, to avoid confusion. /zsolt _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 11 13:15:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23379 for ; Mon, 11 Oct 2004 13:15:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH3wC-0003ji-OE for forces-protocol-web-archive@ietf.org; Mon, 11 Oct 2004 13:26:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH3dg-0005rX-6O; Mon, 11 Oct 2004 13:07:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH3bl-0005Sz-MT for forces-protocol@megatron.ietf.org; Mon, 11 Oct 2004 13:05:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22541 for ; Mon, 11 Oct 2004 13:05:10 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH3mL-0003Tf-19 for forces-protocol@ietf.org; Mon, 11 Oct 2004 13:16:09 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101110074640:20625 ; Mon, 11 Oct 2004 10:07:46 -0700 From: Jamal Hadi Salim To: zsolt@nc.rr.com In-Reply-To: <1097507566.3492.75.camel@localhost.localdomain> References: <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <5.1.0.14.0.20040914134714.02497d00@mail.megisto.com> <1095186094.1032.53.camel@jzny.localdomain> <1097167049.1045.6.camel@jzny.localdomain> <1097246704.2341.124.camel@localhost.localdomain> <1097249647.1076.28.camel@jzny.localdomain> <1097271582.11637.22.camel@localhost.localdomain> <1097281985.1052.143.camel@jzny.localdomain> <1097507566.3492.75.camel@localhost.localdomain> Organization: ZNYX Networks Message-Id: <1097514303.15083.35.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 11 Oct 2004 13:05:03 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/11/2004 10:07:47 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/11/2004 10:07:52 AM, Serialize complete at 10/11/2004 10:07:52 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , avri@psg.com, forces-protocol@ietf.org, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , "Yang, Lily L" , "Joel M. Halpern" , Alan DeKok , Ellen M Deleganes , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] Re: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit On Mon, 2004-10-11 at 11:12, Zsolt Haraszti wrote: > On Fri, 2004-10-08 at 20:33, Jamal Hadi Salim wrote: > The primary purpose of the currently proposed > [:] tuple is to provide an > FE-unique identifier for each LFB instance of the FE. > > Strictly speaking, we do not need a structured address (tuple) just > for that. A flat numbering schema would suffice. Assuming flat, a > 32-bit id would be clearly sufficient (as it is unlikely we will need > more than 4 billion LFB instances per FE). > > (I know that you may compare this to IPv4 and may say "remember?", but > this is a different story; the number of LFB instances in an FE should > not grow proportionally with the speed or # of users of the Internet.) > > Structuring the address into a > [:] serves only a secondary > purpose: diagnostics. I think it is a good purpose. I do not really > like to bloat the id to 64-bit just for that purpose, but I can live > with that, AS LONG AS THE ID APPEARS AS ONE 64-BIT BLOCK IN THE > PROTOCOL. I think it is a very bad idea to split the 64-bit id into 2 > separate TLVs. Many entities involved in the ForCES protocol handling > will not care about the class and would like to treat the LFB instance > ID as a flat logical address. For these, it is a benefit if the id is > in one continuous block in the PL payload. Ok, folks - how about we move forward assuming the two are in the same TLV. There are bigger issues to be tackled and i think time spent on this has exceeded its value threshold(I am using the term "I" since i am the only one it seems arguing for the separation). I will update the doc. So 32 bit (16:16) or 64 bit (32:32)? > > Is the term "dynamic" then acceptable? > > > Not for attributes. In the terminology used in the model, attribute > refers to the top-level attributes of the class (thinks about these > as the local variables of a C++ class). These are defined in the > class specification, hence are static. > > Attributes may include tables with variable content. Yes, entries in > such tables are typically dynamic. But we should not call these > table entries attributes, to avoid confusion. > I cant think of anything other than tables that will have variable elements - so you may be right; need to think cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 11 14:13:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28729 for ; Mon, 11 Oct 2004 14:13:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4qp-0005ET-Nl for forces-protocol-web-archive@ietf.org; Mon, 11 Oct 2004 14:24:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4Uu-0006Bm-SB; Mon, 11 Oct 2004 14:02:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH4Rf-0005AW-V0 for forces-protocol@megatron.ietf.org; Mon, 11 Oct 2004 13:58:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27808 for ; Mon, 11 Oct 2004 13:58:50 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH4cF-0004xZ-II for forces-protocol@ietf.org; Mon, 11 Oct 2004 14:09:48 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9BHvBkb021799; Mon, 11 Oct 2004 17:57:11 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9BI0nfJ023667; Mon, 11 Oct 2004 18:00:49 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101110551215852 ; Mon, 11 Oct 2004 10:55:25 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 10:55:02 -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 Date: Mon, 11 Oct 2004 10:54:46 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791BB@orsmsx408> Thread-Topic: updated notes on BNF and layout Thread-Index: AcSvtH+OpWWSyKsRSo2BTdprvDZ7iAABhu3w From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 11 Oct 2004 17:55:02.0538 (UTC) FILETIME=[6EC536A0:01C4AFBB] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, "Steven \"Blake \(petri-meat\)" , avri@psg.com, "Joel M. Halpern" , donglg@mail.hzic.edu.cn, "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , "Deleganes, Ellen M" , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] RE: updated notes on BNF and layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Jamal, -----Original Message----- > Structuring the address into a=20 > [:] serves only a secondary > purpose: diagnostics. I think it is a good purpose. I do not really > like to bloat the id to 64-bit just for that purpose, but I can live > with that, AS LONG AS THE ID APPEARS AS ONE 64-BIT BLOCK IN THE > PROTOCOL. I think it is a very bad idea to split the 64-bit id into 2 > separate TLVs. Many entities involved in the ForCES protocol handling > will not care about the class and would like to treat the LFB instance > ID as a flat logical address. For these, it is a benefit if the id is > in one continuous block in the PL payload. Ok, folks - how about we move forward assuming the two are in the same TLV. There are bigger issues to be tackled and i think time spent on this has exceeded its value threshold(I am using the term "I" since i am the only one it seems arguing for the separation).=20 I will update the doc. So 32 bit (16:16) or 64 bit (32:32)? =20 [HK] Thanks for coming to an agreement on this. I agree there are bigger issues, not sure why we spent so much energy on this one. Lets go with 16:16 for now, we can always change this in later versions of the draft if absolutely needed. So essentially, the draft needs no update on this issue :-) _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 11 22:56:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24118 for ; Mon, 11 Oct 2004 22:56:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHD10-0002ti-P7 for forces-protocol-web-archive@ietf.org; Mon, 11 Oct 2004 23:07:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHCnC-00062A-Nc; Mon, 11 Oct 2004 22:53:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHCep-0003eY-Vf for forces-protocol@megatron.ietf.org; Mon, 11 Oct 2004 22:45:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23041 for ; Mon, 11 Oct 2004 22:44:57 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHCpO-0002fr-LZ for forces-protocol@ietf.org; Mon, 11 Oct 2004 22:56:00 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CHCef-0000SL-7v for forces-protocol@ietf.org; Mon, 11 Oct 2004 22:44:49 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 88704.341813895; Tue, 12 Oct 2004 11:01:13 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Tue, 12 Oct 2004 10:45:31 +0800 Message-ID: <034c01c4b005$0e872740$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , "Joel M. Halpern" References: <468F3FDA28AA87429AD807992E22D07E025791AF@orsmsx408> <5.1.0.14.0.20041010113017.0231ed20@mail.megisto.com> Subject: Re: [Forces-protocol] RE: updated notes on BNF and layout Date: Tue, 12 Oct 2004 10:42:00 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ram.gopal@nokia.com, Steven Blake , avri@psg.com, donglg@mail.hzic.edu.cn, zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Joel, thank you for reply. ----- Original Message ----- From: "Joel M. Halpern" > My current view (and I could be mistaken) is that this will generally > actually be easier by addressing specific LFBs. > Setting up a data path segment is done by updating tables in the FE object. Maybe it's possible to do this in the FE object, I'm not very sure currently. Another reason I think to address multipul LFB(or instances) I though is just from your example. I.e., to use thousands of LFBs for OC-48 demux to DSx. In this case, to address one LFB at one time may make things even impossible. Remember that I mentioned in my LfbTLV scheme, we can just use a range of LFB instance addressing to solve this very easily. This actually means multipul LFB addressing is more flexible for users. I can also think of other duplicate configuration case where multipule LFB addressing is much more efficient. > For metadata to be passed between LFBs there are actually potentially two > different operations. One (which may already be done for receiving data > from some third LFB) to set up the receive processing, typically creating a > table entry, and one on the sending LFB to fill in what metadata to > send. These are different updates and we ought not combine them into a > single operation. I just think of Metadata setup may be also some kind of duplicate setup process, therefore multipul LFB addressing may greatly ease the operation. > Note that it is valid using this identification scheme and the generally > proposed protocol structure, to include updates to multiple LFBs in the > same request. I would expect that to be common. would however expect those > to be different updates to the different LFBs, not a single update to > multiple LFBs in the FE. There are some cases where multiple LFBs may need > changing (for example if the CE decides to change a configuration timer > that is used in multiple places in the FE.) I do not see this as the > common case. As mentioned above, my view different from you is this may be a very common case. > > With regard to the table structuruing, I suspect I am misreading your note, > so I am having trouble responding in a helpful clarifying fashion. The > only thing I can think to articulate at this point (which is probably not > the aspect you don't see in your code) is that I assume that the CE is > maintaining a set of tables that mirror the FE state. It is the presence > of those tables that make the indexing practical. I agree CE will maintain these FE mirrored tables. The difference between us is I think it then dos not mean the protocol layer should be responsible to keep the index so as to maintain the tables. Without the protocol layer index and with the index defined by FE data model, this can be maintianed well. Actually I don't agree with your idea that the index defined by protocol and by FE model will lead to difference of Index based searching and content based searching, while content based searching is less efficient. I just think Index defined by FE data model will also lead to index searching and will not lessen efficiency. I see some disadvanges of index defined by protocol is: 1. Sometimes, especially for some very small tables, we do needn't index, but if we use protocol index, we then have to use it. 2. Make the index definition quite limited and inflexible. For instance, I'm not sure if the protocol index is global in all FEs or not. If not, then form the case where there is a main table in CE while scattered tables in FEs, the maintainance of Index may become very complicated. On contrary, if the index is defined by FE data model or even by users, we may have more flexible scheme to deal with this, e.g., using segmented Index. 3. Complicate the definition of protocols greatly. > > Yours, > Joel > > At 04:19 PM 10/10/2004 +0800, Wang,Weiming wrote: > >1. If such a scheme of LFBClassID:LFBInstanceID is enough to include all cases > >for LFB addressing. > >One thing I'v thought of is we may need to do some operations between > >LFBs. For > >instance, we may need to establish a datapath between LFBs, and also we > >may very > >often need to setup Metadata along two connected LFBs. These all imply it > >may be > >much more efficient to address more than one LFB or LFB instances at a time > >using current scheme (LFBaddressing followed by Op), or to use other > >scheme like > >(OpTLV followed by LFBTLVs). For datapath setup, I even cannot think of other > >way if we address one LFB at a time using current scheme. > BTW, I'm quite busy these days till next monday, so please excuse me if I can not reply to you very on time. Thank you. Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 11 23:24:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25602 for ; Mon, 11 Oct 2004 23:24:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHDSB-0003Ix-Bg for forces-protocol-web-archive@ietf.org; Mon, 11 Oct 2004 23:35:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHDAx-0005HF-3W; Mon, 11 Oct 2004 23:18:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHD4X-0003vW-Ld for forces-protocol@megatron.ietf.org; Mon, 11 Oct 2004 23:11:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25056 for ; Mon, 11 Oct 2004 23:11:30 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHDF1-000370-EP for forces-protocol@ietf.org; Mon, 11 Oct 2004 23:22:34 -0400 Received: from JLaptop.megisto.com ([192.168.20.228]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 11 Oct 2004 23:11:06 -0400 Message-Id: <5.1.0.14.0.20041011230041.02307ee0@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Oct 2004 23:09:47 -0400 To: "Wang,Weiming" , "Khosravi, Hormuzd M" From: "Joel M. Halpern" Subject: Re: [Forces-protocol] RE: updated notes on BNF and layout In-Reply-To: <034c01c4b005$0e872740$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E025791AF@orsmsx408> <5.1.0.14.0.20041010113017.0231ed20@mail.megisto.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 12 Oct 2004 03:11:06.0904 (UTC) FILETIME=[1D7B7180:01C4B009] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ram.gopal@nokia.com, Steven Blake , avri@psg.com, donglg@mail.hzic.edu.cn, zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 I suspect I am missing some useful ideas you are trying to communicate, because I am not following the items you list. With regard to item 1, indices are needed for small tables and for big tables. The appropriateness of direct indexing versus content indexing is quite independent of table size. With regard to item 2, my point is hat in order for the CE to be able to go through and extract the contents of the table, there must be direct (non-content) indices. This extraction is necessary since the FE may initially have created table entries for any tables, and the CE needs to know about these. (It becomes even more important in failover scenarios, but since we have not spelled those out, I want to be cautious about using those to justify anything.) In some sense, these tables are limited. In order to avoid needing to create the equivalent of SNMP get next, we need something whose behavior is more predictable than arbitrary indices. With regard to item 3, I believe that if we just use 32 bit indices, the protocol can be greatly simplified. We simply include the index in the appropriate position in the element selector. So if item 1 of an LFB is a table, then 1.7 is the 7th entry in the table. If the table includes a strucutre, which is an item 2, then 1.7.2 is the element selected by tag 2 from th structure at the seventh position of the array selected by tag 1. And so on. This allows a single, simple mechanism to reference any element within an LFB, no atter how many arrays or structures it is nested within. Assuming we can assign suitable identifiers for the related properties of an array (which I believe is also easy) we can get away with a small number of operations for the entire LFB element operation suite (GET, SET, CREATE and DELETE for array entries). Yours, Joel M. Halpern At 10:42 AM 10/12/2004 +0800, Wang,Weiming wrote: >1. Sometimes, especially for some very small tables, we do needn't index, but >if we use protocol index, we then have to use it. >2. Make the index definition quite limited and inflexible. >For instance, I'm not sure if the protocol index is global in all FEs or >not. If >not, then form the case where there is a main table in CE while scattered >tables >in FEs, the maintainance of Index may become very complicated. On contrary, if >the index is defined by FE data model or even by users, we may have more >flexible scheme to deal with this, e.g., using segmented Index. >3. Complicate the definition of protocols greatly. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 12 00:43:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00500 for ; Tue, 12 Oct 2004 00:43:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHEg0-0004hz-Eq for forces-protocol-web-archive@ietf.org; Tue, 12 Oct 2004 00:54:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHERt-00075i-Jo; Tue, 12 Oct 2004 00:39:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHEOH-0005uq-RY for forces-protocol@megatron.ietf.org; Tue, 12 Oct 2004 00:36:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29973 for ; Tue, 12 Oct 2004 00:35:58 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHEYx-0004bF-1f for forces-protocol@ietf.org; Tue, 12 Oct 2004 00:47:03 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9C4D2ep007316; Tue, 12 Oct 2004 06:13:04 +0200 In-Reply-To: <5.1.0.14.0.20041010010702.0233a138@mail.megisto.com> References: <1095186094.1032.53.camel@jzny.localdomain> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <468F3FDA28AA87429AD807992E22D07E027F065B@orsmsx408> <5.1.0.14.0.20040914134714.02497d00@mail.megisto.com> <1095186094.1032.53.camel@jzny.localdomain> <5.1.0.14.0.20041010010702.0233a138@mail.megisto.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2ED7E7BD-1C08-11D9-A3E1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Re: updated notes on BNF and layout Date: Tue, 12 Oct 2004 00:35:45 -0400 To: "Joel M. Halpern" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Steve Blake , donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , Ellen M Deleganes , wmwang@mail.hzic.edu.cn, Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit i have been following along without saying much, and believe this is the the right alternative for the reasons you give. I also agree that the version byte should be in the class id. a. On 10 okt 2004, at 01.13, Joel M. Halpern wrote: > Thus, I am concluding that 32:32 may be what we need, _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 12 02:28:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21950 for ; Tue, 12 Oct 2004 02:28:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHGK5-0006Q7-N9 for forces-protocol-web-archive@ietf.org; Tue, 12 Oct 2004 02:39:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHG5C-0006I7-4M; Tue, 12 Oct 2004 02:24:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHFyk-0002iq-2n for forces-protocol@megatron.ietf.org; Tue, 12 Oct 2004 02:17:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20797 for ; Tue, 12 Oct 2004 02:17:45 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHG9Q-0006GN-0W for forces-protocol@ietf.org; Tue, 12 Oct 2004 02:28:48 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9C6GLpF031534; Tue, 12 Oct 2004 06:16:21 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9C6K93J004948; Tue, 12 Oct 2004 06:20:17 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101123164918258 ; Mon, 11 Oct 2004 23:16:49 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 23:16:49 -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 Subject: RE: [Forces-protocol] RE: updated notes on BNF and layout Date: Mon, 11 Oct 2004 23:16:37 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791C4@orsmsx408> Thread-Topic: [Forces-protocol] RE: updated notes on BNF and layout Thread-Index: AcSuoiGuXRpw6lJGSdGDP+5MVJ7wAwBGzO+w From: "Khosravi, Hormuzd M" To: "Wang,Weiming" X-OriginalArrivalTime: 12 Oct 2004 06:16:49.0689 (UTC) FILETIME=[0F198090:01C4B023] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Steven Blake , avri@psg.com, "Joel M. Halpern" , donglg@mail.hzic.edu.cn, zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Weiming, Thanks for posting and breaking your silence after a long time! Pls see my comments below...(I didn't comment on 1 since it seems like we have already resolved it for now) -----Original Message----- 2. The Index issue. I'v been trying to understand Joel's idea on the advantage ( easy management ) of Index used at the protocol layer, but based on my testbed implementation, I just find it seems not an easy thing as we may think to do this. I have to do extra things like matching and managing the Index in CE to protocol application layer and matching and managing the Index in FE protocol terminator to base in LFB. Without using this Index, I don't need to pay these extra attentions, just let the protocol application layer directly manage the LFB base. [HK] I have similar experience on this. The index will add complexity to the protocol depending on how and how much we use it. The main reason why it was proposed (as I understand) was to support Get/Query functions. If we could have some restrictions on these operations, it would probably make like a lot easier. The thing that we do need in addition to LFBClass:LFBInstanceID, is an identifier for the TableID...so that would be the in Zsolt/Steve's text. After that all you need in most cases is an array of entries, that you would like to Add/Del, etc from the FE. The index could be part of each entry itself if defined in the data model instead of being specified separately as part of the Although I think the above issues worth discussing, I agree with Hormuzd that we protocol team may need to begin the paper work now for the new version protocol draft right now, therefore I can currently live with current scheme, which actually quite the same as we'v had in the current draft, while leaving the above issues for more discussion. [HK] Thanks Weiming. I plan to send updates to my sections in the draft to the protocol team in this week... Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 12 02:47:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22858 for ; Tue, 12 Oct 2004 02:47:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHGcT-0006ei-Cn for forces-protocol-web-archive@ietf.org; Tue, 12 Oct 2004 02:58:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHGLO-0005Rf-EW; Tue, 12 Oct 2004 02:41:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHGGI-0003ex-Md for forces-protocol@megatron.ietf.org; Tue, 12 Oct 2004 02:35:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22290 for ; Tue, 12 Oct 2004 02:35:53 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHGQy-0006VC-QQ for forces-protocol@ietf.org; Tue, 12 Oct 2004 02:46:57 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9C6Zam2019904; Tue, 12 Oct 2004 06:35:37 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9C6cZ3F014867; Tue, 12 Oct 2004 06:38:35 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101123350721303 ; Mon, 11 Oct 2004 23:35:07 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Oct 2004 23:35:07 -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 Subject: RE: [Forces-protocol] RE: updated notes on BNF and layout Date: Mon, 11 Oct 2004 23:34:53 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791C5@orsmsx408> Thread-Topic: [Forces-protocol] RE: updated notes on BNF and layout Thread-Index: AcSwCSneOzhv0OVZS5eP+WbVuYPg+AAGgNAA From: "Khosravi, Hormuzd M" To: "Joel M. Halpern" , "Wang,Weiming" X-OriginalArrivalTime: 12 Oct 2004 06:35:07.0398 (UTC) FILETIME=[9D629A60:01C4B025] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Steven Blake , avri@psg.com, donglg@mail.hzic.edu.cn, zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable Joel, Based on my implementation experience, I must say that Weiming has pointed out some very good points regarding indexing as is being proposed currently. I have to agree with the points that Weiming is making. On 1, if you have a small table, if needed you can query the entire table, thus you don't need any indexing. On 2, I think you have misunderstood Weiming's point, but I may be wrong. In any case, in the example that you have given there is no need of indexing atleast in the Query/Get operation since the CE would like to get the entire table that has been created on a FE during initialization, not individual entries. On 3, using indexing defined in the FE model e.g., as part of the data structure which defines an entry in a table, will be a lot easier to manage in the protocol than having it separated as part of the before the actual data. Anyways these are just some clarifications, based on my point of view...i am fine with the current scheme if most of you think its necessary. regards Hormuzd -----Original Message----- From: Joel M. Halpern [mailto:jhalpern@MEGISTO.com]=20 Sent: Monday, October 11, 2004 8:10 PM To: Wang,Weiming; Khosravi, Hormuzd M Cc: ram.gopal@nokia.com; avri@psg.com; forces-protocol@ietf.org; donglg@mail.hzic.edu.cn; zsolt@petri-meat.com; Yang, Lily L; Alan DeKok; Deleganes, Ellen M; Robert Haas; Steven Blake; hadi@znyx.com Subject: Re: [Forces-protocol] RE: updated notes on BNF and layout I suspect I am missing some useful ideas you are trying to communicate,=20 because I am not following the items you list. With regard to item 1, indices are needed for small tables and for big=20 tables. The appropriateness of direct indexing versus content indexing is=20 quite independent of table size. With regard to item 2, my point is hat in order for the CE to be able to go=20 through and extract the contents of the table, there must be direct=20 (non-content) indices. This extraction is necessary since the FE may=20 initially have created table entries for any tables, and the CE needs to know about these. (It becomes even more important in failover scenarios,=20 but since we have not spelled those out, I want to be cautious about using=20 those to justify anything.) In some sense, these tables are limited. In order to avoid needing to=20 create the equivalent of SNMP get next, we need something whose behavior is=20 more predictable than arbitrary indices. With regard to item 3, I believe that if we just use 32 bit indices, the protocol can be greatly simplified. We simply include the index in the=20 appropriate position in the element selector. So if item 1 of an LFB is a table, then 1.7 is the 7th entry in the=20 table. If the table includes a strucutre, which is an item 2, then 1.7.2=20 is the element selected by tag 2 from th structure at the seventh position=20 of the array selected by tag 1. And so on. This allows a single, simple mechanism to reference any element within an=20 LFB, no atter how many arrays or structures it is nested within. Assuming we can assign suitable identifiers for the related properties of=20 an array (which I believe is also easy) we can get away with a small number=20 of operations for the entire LFB element operation suite (GET, SET, CREATE=20 and DELETE for array entries). Yours, Joel M. Halpern At 10:42 AM 10/12/2004 +0800, Wang,Weiming wrote: >1. Sometimes, especially for some very small tables, we do needn't index, but >if we use protocol index, we then have to use it. >2. Make the index definition quite limited and inflexible. >For instance, I'm not sure if the protocol index is global in all FEs or=20 >not. If >not, then form the case where there is a main table in CE while scattered=20 >tables >in FEs, the maintainance of Index may become very complicated. On contrary, if >the index is defined by FE data model or even by users, we may have more >flexible scheme to deal with this, e.g., using segmented Index. >3. Complicate the definition of protocols greatly. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 12 07:38:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09991 for ; Tue, 12 Oct 2004 07:38:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHL9J-0002pr-4o for forces-protocol-web-archive@ietf.org; Tue, 12 Oct 2004 07:49:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHKvX-0003jU-2s; Tue, 12 Oct 2004 07:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHKpK-000209-3Q for forces-protocol@megatron.ietf.org; Tue, 12 Oct 2004 07:28:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09498 for ; Tue, 12 Oct 2004 07:28:21 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHKzs-0002ft-Fk for forces-protocol@ietf.org; Tue, 12 Oct 2004 07:39:27 -0400 Received: from JLaptop.megisto.com ([192.168.20.228]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Oct 2004 07:28:09 -0400 Message-Id: <5.1.0.14.0.20041012071000.02398e08@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Oct 2004 07:27:04 -0400 To: "Khosravi, Hormuzd M" , "Wang,Weiming" From: "Joel M. Halpern" Subject: RE: [Forces-protocol] RE: updated notes on BNF and layout In-Reply-To: <468F3FDA28AA87429AD807992E22D07E025791C4@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 12 Oct 2004 11:28:09.0856 (UTC) FILETIME=[8D58C800:01C4B04E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ram.gopal@nokia.com, Steven Blake , avri@psg.com, donglg@mail.hzic.edu.cn, zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Thank you Hormuz, and my apology Weiming. I now see why there is some distinction if all tables are small. However, I think that we need to be able to fetch and update entries in small and large tables. Let me try describing the element selection process with content addressing, as a contrast to the process I described with just indexing (where the index appears in the path selection.) Let us suppose we have a structure which can be abbreviated: lfbclass: element fa-1: some type definition element fb-2: array of structure ? index ga-0: uint32 ? key element ga-1: some type definition element ga-2: some type definition element ga-3: array of structure ? index ha-0 ? key element ha-1: some type definition element ha-2: some type definition Then, to select an ha-2, I would need a triple, the path fa-2, ga-3, ha-2 the pair ga-1 and a value for the specific key 1 the pair ha-1 and a value for the specific key 1 Including the explicit index as an entry in the structure does make things simpler, as it means that translation to that is just a GET. Even if we only support indexing, I do not object to making the index a structure member. And If we are going to support content indexing, we can avoid creating multiple operations by using the ga-0 and ha-0 where I put the ga-1 and ha-1 above. That still seems more complex than just sending the path fa-2, index value 1, ga-3, index value 2, ha-2 I believe the key difference lies in the assumption about structuring th CE. I assume the CE will need to have all the entries. If it has the entries, then the CE can always provide the index, since in the worst case it just stores the index information with the other information it will need to find to look up the entry. (Note that it always needs to check for entry existence before creating or modifying entries.) So even if the preferred structure for the CE is some content tree, it can still easily use the index. I do agree that this makes some more work for the FE in some cases. As I am not sure which aspect is most important in peoples consideration, I will note that if it makes people happier to have the index in the structure even if we only index by simple uint32, that does not bother me. Yours, Joel At 11:16 PM 10/11/2004 -0700, Khosravi, Hormuzd M wrote: >Weiming, > >Thanks for posting and breaking your silence after a long time! >Pls see my comments below...(I didn't comment on 1 since it seems like >we have already resolved it for now) > >-----Original Message----- >2. The Index issue. >I'v been trying to understand Joel's idea on the advantage ( easy >management ) >of Index used at the protocol layer, but based on my testbed >implementation, I >just find it seems not an easy thing as we may think to do this. I have >to do >extra things like matching and managing the Index in CE to protocol >application >layer and matching and managing the Index in FE protocol terminator to >base in >LFB. Without using this Index, I don't need to pay these extra >attentions, just >let the protocol application layer directly manage the LFB base. > >[HK] I have similar experience on this. The index will add complexity to >the protocol depending on how and how much we use it. The main reason >why it was proposed (as I understand) was to support Get/Query >functions. If we could have some restrictions on these operations, it >would probably make like a lot easier. The thing that we do need in >addition to LFBClass:LFBInstanceID, is an identifier for the >TableID...so that would be the in Zsolt/Steve's text. After that >all you need in most cases is an array of entries, that you would like >to Add/Del, etc from the FE. The index could be part of each entry >itself if defined in the data model instead of being specified >separately as part of the > > >Although I think the above issues worth discussing, I agree with Hormuzd >that we >protocol team may need to begin the paper work now for the new version >protocol >draft right now, therefore I can currently live with current scheme, >which >actually quite the same as we'v had in the current draft, while leaving >the >above issues for more discussion. > >[HK] Thanks Weiming. I plan to send updates to my sections in the draft >to the protocol team in this week... > > >Regards >Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 12 09:23:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19054 for ; Tue, 12 Oct 2004 09:23:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMnm-00053q-3c for forces-protocol-web-archive@ietf.org; Tue, 12 Oct 2004 09:34:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMVx-0004Nk-Vr; Tue, 12 Oct 2004 09:16:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMK7-0001HE-5t for forces-protocol@megatron.ietf.org; Tue, 12 Oct 2004 09:04:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17603 for ; Tue, 12 Oct 2004 09:04:13 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CHMUc-0004hO-W5 for forces-protocol@ietf.org; Tue, 12 Oct 2004 09:15:21 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 88704.341813895; Tue, 12 Oct 2004 21:20:53 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Tue, 12 Oct 2004 21:05:06 +0800 Message-ID: <06a001c4b05b$9c2046d0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , "Joel M. Halpern" References: <5.1.0.14.0.20041012071000.02398e08@mail.megisto.com> Subject: Re: [Forces-protocol] RE: updated notes on BNF and layout Date: Tue, 12 Oct 2004 21:01:37 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: ram.gopal@nokia.com, Steven Blake , avri@psg.com, donglg@mail.hzic.edu.cn, zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Hi Joel, ----- Original Message ----- From: "Joel M. Halpern" > Thank you Hormuz, and my apology Weiming. I was very busy that kept me join less, and will still be busy till next Monday, I even can not reply your this email very fully :( >I now see why there is some > distinction if all tables are small. However, I think that we need to be > able to fetch and update entries in small and large tables. > > Let me try describing the element selection process with content > addressing, as a contrast to the process I described with just indexing > (where the index appears in the path selection.) > > Let us suppose we have a structure which can be abbreviated: > lfbclass: > element fa-1: some type definition > element fb-2: array of structure > ? index ga-0: uint32 ? > key element ga-1: some type definition > element ga-2: some type definition > element ga-3: array of structure > ? index ha-0 ? > key element ha-1: some type definition > element ha-2: some type definition > > Then, to select an ha-2, I would need a triple, > the path fa-2, ga-3, ha-2 > the pair ga-1 and a value for the specific key 1 > the pair ha-1 and a value for the specific key 1 > > Including the explicit index as an entry in the structure does make things > simpler, as it means that translation to that is just a GET. Even if we > only support indexing, I do not object to making the index a structure member. > And If we are going to support content indexing, we can avoid creating > multiple operations by using the ga-0 and ha-0 where I put the ga-1 and > ha-1 above. That's just the point. Then the path will appear just as: fa-2: ga-0: ha-0 I don't see the difference with what you use protocol index as below. Could you explain more on the difference? I can see the only difference is the above is defined in the protocol Data entry while the below will be defined outside the entry. > > That still seems more complex than just sending > the path fa-2, index value 1, ga-3, index value 2, ha-2 >From this point, I see more about what I mentioned the protocol 32bit index will quite be limited. In this case above(index for recursive tables), it seems the 32bit protocol index will be segmented. Then this implies the FE model will have to define how the 32 bit index will be used, or else I suppose there will be interoperability problem between different vendors. This actually has lead to a quite embarassing case, that is, the LFB definition in FE model will have to pay attention to terminology (the index) used by the protocol. > I believe the key difference lies in the assumption about structuring th > CE. I assume the CE will need to have all the entries. If it has the > entries, then the CE can always provide the index, since in the worst case > it just stores the index information with the other information it will > need to find to look up the entry. (Note that it always needs to check for > entry existence before creating or modifying entries.) So even if the > preferred structure for the CE is some content tree, it can still easily > use the index. > I do agree that this makes some more work for the FE in some cases. > > As I am not sure which aspect is most important in peoples consideration, I > will note that if it makes people happier to have the index in the > structure even if we only index by simple uint32, that does not bother me. > > Yours, > Joel > > At 11:16 PM 10/11/2004 -0700, Khosravi, Hormuzd M wrote: > >Weiming, > > > >Thanks for posting and breaking your silence after a long time! > >Pls see my comments below...(I didn't comment on 1 since it seems like > >we have already resolved it for now) > > > >-----Original Message----- > >2. The Index issue. > >I'v been trying to understand Joel's idea on the advantage ( easy > >management ) > >of Index used at the protocol layer, but based on my testbed > >implementation, I > >just find it seems not an easy thing as we may think to do this. I have > >to do > >extra things like matching and managing the Index in CE to protocol > >application > >layer and matching and managing the Index in FE protocol terminator to > >base in > >LFB. Without using this Index, I don't need to pay these extra > >attentions, just > >let the protocol application layer directly manage the LFB base. > > > >[HK] I have similar experience on this. The index will add complexity to > >the protocol depending on how and how much we use it. The main reason > >why it was proposed (as I understand) was to support Get/Query > >functions. If we could have some restrictions on these operations, it > >would probably make like a lot easier. The thing that we do need in > >addition to LFBClass:LFBInstanceID, is an identifier for the > >TableID...so that would be the in Zsolt/Steve's text. After that > >all you need in most cases is an array of entries, that you would like > >to Add/Del, etc from the FE. The index could be part of each entry > >itself if defined in the data model instead of being specified > >separately as part of the > > > > > >Although I think the above issues worth discussing, I agree with Hormuzd > >that we > >protocol team may need to begin the paper work now for the new version > >protocol > >draft right now, therefore I can currently live with current scheme, > >which > >actually quite the same as we'v had in the current draft, while leaving > >the > >above issues for more discussion. > > > >[HK] Thanks Weiming. I plan to send updates to my sections in the draft > >to the protocol team in this week... > > > > > >Regards > >Hormuzd > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 12 10:21:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22508 for ; Tue, 12 Oct 2004 10:21:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHNf7-000637-KZ for forces-protocol-web-archive@ietf.org; Tue, 12 Oct 2004 10:30:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMye-0004HZ-ET; Tue, 12 Oct 2004 09:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHMls-0000bv-00 for forces-protocol@megatron.ietf.org; Tue, 12 Oct 2004 09:32:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19719 for ; Tue, 12 Oct 2004 09:32:55 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHMwS-0005E8-JO for forces-protocol@ietf.org; Tue, 12 Oct 2004 09:44:02 -0400 Received: from JLaptop.megisto.com ([192.168.20.163]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 12 Oct 2004 09:32:33 -0400 Message-Id: <5.1.0.14.0.20041012092532.024079c8@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Oct 2004 09:32:02 -0400 To: "Wang,Weiming" , "Khosravi, Hormuzd M" From: "Joel M. Halpern" Subject: Re: [Forces-protocol] RE: updated notes on BNF and layout In-Reply-To: <06a001c4b05b$9c2046d0$845c21d2@Necom.hzic.edu.cn> References: <5.1.0.14.0.20041012071000.02398e08@mail.megisto.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 12 Oct 2004 13:32:33.0407 (UTC) FILETIME=[EDF848F0:01C4B05F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ram.gopal@nokia.com, Steven Blake , avri@psg.com, donglg@mail.hzic.edu.cn, zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 For clarity, no matter which structure we use, with nested tables each table has its own index. With content indexes, each table has a content field that is its key (or maybe more than one such field). With straight indexing, each table has a 32 bit index. We do not try to partition a single 32 bit index across nested tables. That would indeed be extremely ugly. Each entry (fa-2, index value 1, ga-3, index value 2, ha-2) is a 32 bit entry that selects a "thing". fa-2 selects the whole table. index value 1 selects the entry from the table. The difference between the two mechanisms is simply taht when there is only a single, always 32 bit, index, one can naturally include it in the path with no need for type / length indication for the "key". When we do content addressing, we need each key to have at least a length, and for clarity probably a type code (i.e. a number assigned by some library to the type of information used as the index). Yours, Joel PS: While I dislike the complexity of content addressing, it does have value and if the rough consensus is to use it I can live with it. It is not a show stopper for me as long as all tables always have simple indices as well. At 09:01 PM 10/12/2004 +0800, Wang,Weiming wrote: > > That still seems more complex than just sending > > the path fa-2, index value 1, ga-3, index value 2, ha-2 > From this point, I see more about what I mentioned the protocol 32bit > index will >quite be limited. In this case above(index for recursive tables), it seems the >32bit protocol index will be segmented. Then this implies the FE model >will have >to define how the 32 bit index will be used, or else I suppose there will be >interoperability problem between different vendors. This actually has lead >to a >quite embarassing case, that is, the LFB definition in FE model will have to >pay attention to terminology (the index) used by the protocol. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 12 11:17:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29563 for ; Tue, 12 Oct 2004 11:17:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHOa7-0007V4-4T for forces-protocol-web-archive@ietf.org; Tue, 12 Oct 2004 11:28:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHOKn-0006FY-HN; Tue, 12 Oct 2004 11:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHO6F-00025g-It for forces-protocol@megatron.ietf.org; Tue, 12 Oct 2004 10:58:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27446 for ; Tue, 12 Oct 2004 10:58:02 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHOH0-000738-GB for forces-protocol@ietf.org; Tue, 12 Oct 2004 11:09:11 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101208003325:21691 ; Tue, 12 Oct 2004 08:00:33 -0700 Subject: Re: [Forces-protocol] RE: updated notes on BNF and layout From: Jamal Hadi Salim To: "Joel M. Halpern" In-Reply-To: <5.1.0.14.0.20041012092532.024079c8@mail.megisto.com> References: <5.1.0.14.0.20041012071000.02398e08@mail.megisto.com> <5.1.0.14.0.20041012092532.024079c8@mail.megisto.com> Organization: Znyx Networks Message-Id: <1097593071.1029.23.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Oct 2004 10:57:52 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/12/2004 08:00:33 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/12/2004 08:00:41 AM, Serialize complete at 10/12/2004 08:00:41 AM Content-Type: multipart/mixed; boundary="=-7iF34YLe8UkooU3K4qjv" X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: ram.gopal@nokia.com, Steve Blake , avri@psg.com, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , "Wang, Weiming" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 --=-7iF34YLe8UkooU3K4qjv Content-Type: text/plain Content-Transfer-Encoding: 7bit Updated little doc based on recent discussions. I hope i havent missed anything said. cheers, jamal --=-7iF34YLe8UkooU3K4qjv Content-Disposition: attachment; filename=msg-discuss.txt Content-Type: text/plain; name=msg-discuss.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is a document that captures thoughts discussed starting at the SD IETF and thereafter in many many emails involving the model team. It is only meant as a guidance, the Protocol design team may decide to rearrange things as long as the requirements discussed are met. PL level PDU : = MAINHDR+ LFBselect := LFBCLASSID LFBInstance + OPER:= ]*>+ - MAINHDR defines msg type, Target FE/CE ID etc. the MAINHDR also defines the content. As an example the content of a "config" message would be different from an "association" message. - LFBCLASSID is a 32 bit unique identifier per LFB class defined at class creation time. - LFBInstance is a 32 bit unique instance identifier of an LFB class - OPERATION is one of {ADD,DEL,GET, ??} path-data identifies the exact element targeted. It may have zero or more data values associated. In summary the described approach has the following characteristic: - there can be one or more LFB Class + InstanceId combo targeted in a message (batch) - There can one or more operation on an addressed LFB classid+instanceid combo(batch) - There can be one or more path targets per operation (batch) - paths may have zero or more data values associated (flexibility and operation specific) It should be noted that the above is optimized for the case of a a single classid+instance targeting. To target multiple instances within the same class, multiple LFBselect are needed. To illustrate, -------------- main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = 0x45 | | | | | +-- LFBInstance = 0x1234 | | | +-- T = ADD | | | | | +-- // one or more path targets | | // with their data here to be added | | | +-- T = DEL | . | | . +-- // one or more path targets to be deleted | | +--- T = LFBselect | | | +-- LFBCLASSID = 0x45 | | | | | +-- LFBInstance = 0x145 | | | | // at row index 7, replace foo1 | + -- T= ADD | | | | | | | // Block del operation on row 1-4 of table X | + -- T= DEL | | | | // at row index 70, get the value of foo2 | + -- T= GET | | +--- T = LFBselect | +-- LFBCLASSID = 0x145 | +-- LFBInstance = 0x14 . . . Main Hdr: -------- As shown above the layout begins with the main header identifies the the msg type such as "config". The main header identifies the source and target FEid/CEid. LFBselect --------- A TLV. The value contains the LFB class being selected, the instanceid within the LFB class being targetted and and one or operational TLVs defining various operations executed on the LFB instance. Operation --------- A TLV. The T defines the type of operation eg ADD. The value contains one or more path-data. path-data ---------- The layout is still under discussion and so is left out from this text. Each accessible attribute within an LFB is expected to have a 32 bit identifier. The path-data will have a map derived from the static class attribute IDs as well as those derived from variable content such table indices (derived at runtime). Below is an illustration of a complex example and how the different attributes could be accessed. Assume LFB Class A. It contains two Arrays, B, and C (assigned identifiers 1 and 2) A also contains a structure of type Stoo with a human name F. F is assigned ID 3. A also contains two attributes, D and E assigned identifiers 4 and 5. Array B is an array, indexed as a table, whose contents are int32s. Array C is an array, indexed as a table, whose contents are a structure named Star. Stoo type structures contain elements X and Y, each characters, assigned identifiers 1 and 2. Star contains An element N (a sting), assigned identifier 1, and an array Arr, assigned identifier 2, indexed as a table, containing int32s. To reference entities within an LFB instance of Class A, selectors are as follows: 1, meaning the full array B 3, meaning the full structure named F. 2, 7 meaning the full structure in the seventh entry of the array C. 4 means the attribute D 2, 8, 2, 9 meaning the 9th number in the array in the structure in the eigth slot of the array C. Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct type definition. Since the model team has asserted that class definitions can only change (version) in ways that leave existing references intact and usable it means backward compatibility is supported. Other Issues that came up -------------------------- 1) Scope of Ts. It is expected that most of the Ts would be global. There may be however desire to have localy scoped Ts depending on the LFB class 2) Can the same Ts be repeated multiple times within a hierachy? Yes. 3) Need to agree on content addressing $Log: msg-discuss.txt,v $ Revision 1.6 2004/10/12 14:34:40 hadi updated the instance and classid to be in the same TLV Revision 1.5 2004/10/06 15:10:37 hadi More discussions with Joel - I think we have reached a compromise Removed any references to how paths are achieved; leave that to the Doc from Steve and Zsolt (for now at least) Revision 1.4 2004/08/28 18:11:25 hadi reached semi-convergence with Joel Revision 1.3 2004/08/27 01:06:34 hadi Adding Joels views on the OPER approach Revision 1.2 2004/08/12 12:47:21 hadi updated diagram per Zsolts comments Revision 1.1 2004/08/12 11:34:25 hadi Initial revision --=-7iF34YLe8UkooU3K4qjv Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=-7iF34YLe8UkooU3K4qjv-- From forces-protocol-bounces@ietf.org Tue Oct 12 11:32:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01411 for ; Tue, 12 Oct 2004 11:32:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHOon-0007pI-7R for forces-protocol-web-archive@ietf.org; Tue, 12 Oct 2004 11:44:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHOaD-0001ur-Ap; Tue, 12 Oct 2004 11:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHOTT-0008Om-6n for forces-protocol@megatron.ietf.org; Tue, 12 Oct 2004 11:22:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00187 for ; Tue, 12 Oct 2004 11:22:01 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHOeB-0007aX-Rv for forces-protocol@ietf.org; Tue, 12 Oct 2004 11:33:11 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101208243491:21723 ; Tue, 12 Oct 2004 08:24:34 -0700 From: Jamal Hadi Salim To: forces-protocol@ietf.org Organization: Znyx Networks Message-Id: <1097594514.1029.46.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 12 Oct 2004 11:21:54 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/12/2004 08:24:35 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/12/2004 08:24:38 AM, Serialize complete at 10/12/2004 08:24:38 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] effect of new BNF, changes etc etc on protocol X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Folks, I am listing a partial list of items that change the way we view draft 0. 1) BNF changes. Major issue being the query and query response appear to be gone. Instead we now have a CONFIG/GET and CONFIG-resp/GET Unfortunately unless the data-path is well defined this is going to be tricky to move forward on. So i will put some effort in getting the path-data definition going. Please chip in the discussion with the other folks from the model team. 2) The fact that its now a world of "everything is an LFB" and introduction of FE protocol and FEObject LFBs implies that same messages may have to go. Specifically, it seem state maintanance and event messages would need redefining. I know theres an outstanding list of open issues; hopefully someone will post them. It is my belief that draft 1 needs to address these issues to look progressive. It shouldnt matter if we publish it in time or not. Whats important is the presentation at the meeting covers addressed issues and the draft does as well when it gets published. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 13 05:40:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06648 for ; Wed, 13 Oct 2004 05:40:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHfnT-0000PK-PV for forces-protocol-web-archive@ietf.org; Wed, 13 Oct 2004 05:51:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHfPi-0002Tp-V2; Wed, 13 Oct 2004 05:27:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHfOe-00077G-KR for forces-protocol@megatron.ietf.org; Wed, 13 Oct 2004 05:26:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05495 for ; Wed, 13 Oct 2004 05:26:08 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHfZT-00008i-HS for forces-protocol@ietf.org; Wed, 13 Oct 2004 05:37:26 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9D9PYfQ158344; Wed, 13 Oct 2004 09:25:34 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9D9PXHJ198714; Wed, 13 Oct 2004 11:25:33 +0200 Received: from zurich.ibm.com (sig-9-146-219-135.de.ibm.com [9.146.219.135]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA75210; Wed, 13 Oct 2004 11:25:32 +0200 Message-ID: <416CF482.6010801@zurich.ibm.com> Date: Wed, 13 Oct 2004 11:25:22 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com Subject: Re: [Forces-protocol] effect of new BNF, changes etc etc on protocol References: <1097594514.1029.46.camel@jzny.localdomain> In-Reply-To: <1097594514.1029.46.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id i9D9PYfQ158344 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable To add to Jamal's list of open issues, I wanted to remind my co-authors=20 of the following: Some time back, there has been a long thread initiated by comments from=20 Furquan (heartbeats, channels, TMLs vs PL responsibilities, missing FSMs=20 to describe CE and FE behavior in cases such as failover), and a very=20 short thread with valuable comments from Zsolt (TML layering, FE ID=20 allocation by CE, query-response correlation and use of sequence numbers). Did we capture the issues raised in those threads into an open-issue=20 list ? I think we did not agree yet how to answer all of their comments,=20 yet they are essential for a sound base of the ForCES protocol, I think.=20 So I will focus now on some of the issues related to heartbeat,=20 addressing and layering, and bring up proposals to our list so we are=20 all aware and can agree on them. I encourage my co-authors to do the=20 same and revisit those threads if necessary. Incorporating those=20 proposals into the relevant sections of the draft could be the editor's=20 task. Or do we want to proceed differently ? Regards, -Robert Jamal Hadi Salim wrote: >Folks, > >I am listing a partial list of items that change the way we view draft >0. > >1) BNF changes. >Major issue being the query and query response appear to be gone. >Instead we now have a CONFIG/GET and CONFIG-resp/GET >Unfortunately unless the data-path is well defined this is going to be >tricky to move forward on. So i will put some effort in getting the >path-data definition going. Please chip in the discussion with the other >folks from the model team. > >2) The fact that its now a world of "everything is an LFB" and >introduction of FE protocol and FEObject LFBs implies that same messages >may have to go. Specifically, it seem state maintanance and event >messages would need redefining. > >I know theres an outstanding list of open issues; hopefully someone will >post them. >It is my belief that draft 1 needs to address these issues to look >progressive. It shouldnt matter if we publish it in time or not. Whats >important is the presentation at the meeting covers addressed issues >and the draft does as well when it gets published. > >cheers, >jamal > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 13 10:29:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01756 for ; Wed, 13 Oct 2004 10:29:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHkJ7-0006FX-VJ for forces-protocol-web-archive@ietf.org; Wed, 13 Oct 2004 10:40:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHk1E-0002ZX-O5; Wed, 13 Oct 2004 10:22:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHjvl-0000YA-Nn for forces-protocol@megatron.ietf.org; Wed, 13 Oct 2004 10:16:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00025 for ; Wed, 13 Oct 2004 10:16:35 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHk6c-0005y4-UM for forces-protocol@ietf.org; Wed, 13 Oct 2004 10:27:55 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9DEFRjc019868; Wed, 13 Oct 2004 14:15:27 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9DEIvKo025132; Wed, 13 Oct 2004 14:19:28 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101307155903368 ; Wed, 13 Oct 2004 07:15:59 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 07:15: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 Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc on protocol Date: Wed, 13 Oct 2004 07:15:39 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791C9@orsmsx408> Thread-Topic: [Forces-protocol] effect of new BNF, changes etc etc on protocol Thread-Index: AcSxCLNY+LCT87reQEG9Vu/R7ZcWBwAJXJtw From: "Khosravi, Hormuzd M" To: "Robert Haas" , X-OriginalArrivalTime: 13 Oct 2004 14:15:58.0976 (UTC) FILETIME=[296C5000:01C4B12F] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Good point Robert. I was planning to incorporate Furquan's comments on HA to that section and then send it out to the team for review. In general the idea is that each of the previous section owners go through all the comments they have received on the list and propose appropriate changes/text. We can then discuss them and ask our co-editor to incorporate the changes in the draft. I had mentioned this in my previous email to the list last week, not sure if you read it? regards Hormuzd -----Original Message----- From: forces-protocol-bounces@ietf.org [mailto:forces-protocol-bounces@ietf.org] On Behalf Of Robert Haas Sent: Wednesday, October 13, 2004 2:25 AM To: hadi@znyx.com Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] effect of new BNF, changes etc etc on protocol To add to Jamal's list of open issues, I wanted to remind my co-authors=20 of the following: Some time back, there has been a long thread initiated by comments from=20 Furquan (heartbeats, channels, TMLs vs PL responsibilities, missing FSMs to describe CE and FE behavior in cases such as failover), and a very=20 short thread with valuable comments from Zsolt (TML layering, FE ID=20 allocation by CE, query-response correlation and use of sequence numbers). Did we capture the issues raised in those threads into an open-issue=20 list ? I think we did not agree yet how to answer all of their comments, yet they are essential for a sound base of the ForCES protocol, I think. So I will focus now on some of the issues related to heartbeat,=20 addressing and layering, and bring up proposals to our list so we are=20 all aware and can agree on them. I encourage my co-authors to do the=20 same and revisit those threads if necessary. Incorporating those=20 proposals into the relevant sections of the draft could be the editor's=20 task. Or do we want to proceed differently ? Regards, -Robert _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 13 10:41:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03826 for ; Wed, 13 Oct 2004 10:41:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHkUj-0006Vp-5B for forces-protocol-web-archive@ietf.org; Wed, 13 Oct 2004 10:52:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHkD2-0006zG-JD; Wed, 13 Oct 2004 10:34:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHk5O-0003sP-Ju for forces-protocol@megatron.ietf.org; Wed, 13 Oct 2004 10:26:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01314 for ; Wed, 13 Oct 2004 10:26:31 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHkGE-0006BG-Sm for forces-protocol@ietf.org; Wed, 13 Oct 2004 10:37:51 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9DEPQjc024815; Wed, 13 Oct 2004 14:25:26 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9DETCKW000360; Wed, 13 Oct 2004 14:29:27 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101307255812606 ; Wed, 13 Oct 2004 07:25:58 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 07:25: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 Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc on protocol Date: Wed, 13 Oct 2004 07:25:32 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791CB@orsmsx408> Thread-Topic: [Forces-protocol] effect of new BNF, changes etc etc on protocol Thread-Index: AcSwcMcAAAPDJePlR/Wh8rzEOXnbywAvwWCQ From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 13 Oct 2004 14:25:58.0574 (UTC) FILETIME=[8ECFB4E0:01C4B130] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Jamal, Thanks for posting this, I am most fine with what you propose. Pls see my comments below... -----Original Message----- From: forces-protocol-bounces@ietf.org [mailto:forces-protocol-bounces@ietf.org] On Behalf Of Jamal Hadi Salim 1) BNF changes. Major issue being the query and query response appear to be gone. Instead we now have a CONFIG/GET and CONFIG-resp/GET [HK] We could still keep the Query and Config separate, I don't think we have to remove Config...it would actually be cleaner that way. But I am fine if most of you would like to remove it. Unfortunately unless the data-path is well defined this is going to be tricky to move forward on. So i will put some effort in getting the path-data definition going. Please chip in the discussion with the other folks from the model team. 2) The fact that its now a world of "everything is an LFB" and introduction of FE protocol and FEObject LFBs implies that same messages may have to go. Specifically, it seem state maintanance and event messages would need redefining. [HK] Yes we need to decide about State Maintenance msgs, I am fine either ways. I don't think Event msgs are affected by this. It is my belief that draft 1 needs to address these issues to look progressive. It shouldnt matter if we publish it in time or not. [HK] I think this is important in order to make a presentation and show progress. Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 13 12:02:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10769 for ; Wed, 13 Oct 2004 12:02:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHlld-00080l-37 for forces-protocol-web-archive@ietf.org; Wed, 13 Oct 2004 12:14:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHlUo-0001re-4s; Wed, 13 Oct 2004 11:56:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHlR9-00013N-3H for forces-protocol@megatron.ietf.org; Wed, 13 Oct 2004 11:53:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09838 for ; Wed, 13 Oct 2004 11:53:10 -0400 (EDT) From: ram.gopal@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHlc7-0007qa-Qv for forces-protocol@ietf.org; Wed, 13 Oct 2004 12:04:32 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9DFqxC16284; Wed, 13 Oct 2004 18:53:00 +0300 (EET DST) X-Scanned: Wed, 13 Oct 2004 18:51:19 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9DFpJ7B015415; Wed, 13 Oct 2004 18:51:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 008oFLat; Wed, 13 Oct 2004 18:51:17 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9DFp3a09383; Wed, 13 Oct 2004 18:51:04 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 13 Oct 2004 10:50:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc on protocol Date: Wed, 13 Oct 2004 11:50:25 -0400 Message-ID: Thread-Topic: [Forces-protocol] effect of new BNF, changes etc etc on protocol thread-index: AcSxCLNY+LCT87reQEG9Vu/R7ZcWBwAJXJtwAAN70oA= To: , , X-OriginalArrivalTime: 13 Oct 2004 15:50:27.0547 (UTC) FILETIME=[5C279AB0:01C4B13C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Hello hormuzd, During that same email thread there were some comments raised regarding = the initial configuration procedure. We may need to address that also, looks like that section is not = assigned to anyone. May be each of us can provide input=20 to that section what are the minimal configurable parameters required. Regards Ramg -----Original Message----- From: forces-protocol-bounces@ietf.org [mailto:forces-protocol-bounces@ietf.org]On Behalf Of ext Khosravi, Hormuzd M Sent: Wednesday, October 13, 2004 10:16 AM To: Robert Haas; hadi@znyx.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc on protocol Good point Robert. I was planning to incorporate Furquan's comments on HA to that section and then send it out to the team for review. In general the idea is that each of the previous section owners go through all the comments they have received on the list and propose appropriate changes/text. We can then discuss them and ask our co-editor to incorporate the changes in the draft. I had mentioned this in my previous email to the list last week, not sure if you read it? regards Hormuzd -----Original Message----- From: forces-protocol-bounces@ietf.org [mailto:forces-protocol-bounces@ietf.org] On Behalf Of Robert Haas Sent: Wednesday, October 13, 2004 2:25 AM To: hadi@znyx.com Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] effect of new BNF, changes etc etc on protocol To add to Jamal's list of open issues, I wanted to remind my co-authors=20 of the following: Some time back, there has been a long thread initiated by comments from=20 Furquan (heartbeats, channels, TMLs vs PL responsibilities, missing FSMs to describe CE and FE behavior in cases such as failover), and a very=20 short thread with valuable comments from Zsolt (TML layering, FE ID=20 allocation by CE, query-response correlation and use of sequence numbers). Did we capture the issues raised in those threads into an open-issue=20 list ? I think we did not agree yet how to answer all of their comments, yet they are essential for a sound base of the ForCES protocol, I think. So I will focus now on some of the issues related to heartbeat,=20 addressing and layering, and bring up proposals to our list so we are=20 all aware and can agree on them. I encourage my co-authors to do the=20 same and revisit those threads if necessary. Incorporating those=20 proposals into the relevant sections of the draft could be the editor's=20 task. Or do we want to proceed differently ? Regards, -Robert _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 13 12:23:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12671 for ; Wed, 13 Oct 2004 12:23:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHm5s-0008Pj-MT for forces-protocol-web-archive@ietf.org; Wed, 13 Oct 2004 12:35:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHlso-0000by-QZ; Wed, 13 Oct 2004 12:21:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHlb7-0003Hx-Ok for forces-protocol@megatron.ietf.org; Wed, 13 Oct 2004 12:03:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10798 for ; Wed, 13 Oct 2004 12:03:29 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHlm6-00080g-Jc for forces-protocol@ietf.org; Wed, 13 Oct 2004 12:14:51 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9DG6ZUM027089; Wed, 13 Oct 2004 16:06:35 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9DG4IKo010152; Wed, 13 Oct 2004 16:06:21 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101309024921427 ; Wed, 13 Oct 2004 09:02:50 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 09:02:41 -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 Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc on protocol Date: Wed, 13 Oct 2004 09:02:29 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791CE@orsmsx408> Thread-Topic: [Forces-protocol] effect of new BNF, changes etc etc on protocol Thread-Index: AcSxCLNY+LCT87reQEG9Vu/R7ZcWBwAJXJtwAAN70oAAAHnlYA== From: "Khosravi, Hormuzd M" To: , , X-OriginalArrivalTime: 13 Oct 2004 16:02:41.0122 (UTC) FILETIME=[11664420:01C4B13E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Sounds good. Glad to see everyone back in action, Hormuzd :) -----Original Message----- From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]=20 Sent: Wednesday, October 13, 2004 8:50 AM To: Khosravi, Hormuzd M; rha@zurich.ibm.com; hadi@znyx.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc on protocol Hello hormuzd, During that same email thread there were some comments raised regarding the initial configuration procedure. We may need to address that also, looks like that section is not assigned to anyone. May be each of us can provide input=20 to that section what are the minimal configurable parameters required. Regards Ramg -----Original Message----- From: forces-protocol-bounces@ietf.org [mailto:forces-protocol-bounces@ietf.org]On Behalf Of ext Khosravi, Hormuzd M Sent: Wednesday, October 13, 2004 10:16 AM To: Robert Haas; hadi@znyx.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc on protocol Good point Robert. I was planning to incorporate Furquan's comments on HA to that section and then send it out to the team for review. In general the idea is that each of the previous section owners go through all the comments they have received on the list and propose appropriate changes/text. We can then discuss them and ask our co-editor to incorporate the changes in the draft. I had mentioned this in my previous email to the list last week, not sure if you read it? regards Hormuzd -----Original Message----- From: forces-protocol-bounces@ietf.org [mailto:forces-protocol-bounces@ietf.org] On Behalf Of Robert Haas Sent: Wednesday, October 13, 2004 2:25 AM To: hadi@znyx.com Cc: forces-protocol@ietf.org Subject: Re: [Forces-protocol] effect of new BNF, changes etc etc on protocol To add to Jamal's list of open issues, I wanted to remind my co-authors=20 of the following: Some time back, there has been a long thread initiated by comments from=20 Furquan (heartbeats, channels, TMLs vs PL responsibilities, missing FSMs to describe CE and FE behavior in cases such as failover), and a very=20 short thread with valuable comments from Zsolt (TML layering, FE ID=20 allocation by CE, query-response correlation and use of sequence numbers). Did we capture the issues raised in those threads into an open-issue=20 list ? I think we did not agree yet how to answer all of their comments, yet they are essential for a sound base of the ForCES protocol, I think. So I will focus now on some of the issues related to heartbeat,=20 addressing and layering, and bring up proposals to our list so we are=20 all aware and can agree on them. I encourage my co-authors to do the=20 same and revisit those threads if necessary. Incorporating those=20 proposals into the relevant sections of the draft could be the editor's=20 task. Or do we want to proceed differently ? Regards, -Robert _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 13 15:49:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29232 for ; Wed, 13 Oct 2004 15:49:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpJ9-0004jK-Tu for forces-protocol-web-archive@ietf.org; Wed, 13 Oct 2004 16:01:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHoxb-0007UT-SF; Wed, 13 Oct 2004 15:38:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHonn-00064a-Ra for forces-protocol@megatron.ietf.org; Wed, 13 Oct 2004 15:28:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27489 for ; Wed, 13 Oct 2004 15:28:47 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHovh-0003p7-Q4 for forces-protocol@ietf.org; Wed, 13 Oct 2004 15:37:00 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9DJP3fQ130840; Wed, 13 Oct 2004 19:25:03 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9DJP2HJ215460; Wed, 13 Oct 2004 21:25:02 +0200 Received: from zurich.ibm.com (sig-9-145-130-4.de.ibm.com [9.145.130.4]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id VAA37248; Wed, 13 Oct 2004 21:25:01 +0200 Message-ID: <416D80FF.6000505@zurich.ibm.com> Date: Wed, 13 Oct 2004 21:24:47 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" Subject: Re: [Forces-protocol] effect of new BNF, changes etc etc on protocol References: <468F3FDA28AA87429AD807992E22D07E025791C9@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E025791C9@orsmsx408> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.de.ibm.com id i9DJP3fQ130840 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Khosravi, Hormuzd M wrote: >Good point Robert. I was planning to incorporate Furquan's comments on >HA to that section and then send it out to the team for review.=20 > Good. >In >general the idea is that each of the previous section owners go through >all the comments they have received on the list and propose appropriate >changes/text.=20 > Did someone maintain an open issues list ? That could be helpful now. >We can then discuss them and ask our co-editor to >incorporate the changes in the draft. > I hadn't seen this co-editor word until now. I thought Avri was the=20 editor and we are supposed to be the co-authors. Anyway, I assume you=20 meant Avri. > I had mentioned this in my >previous email to the list last week, not sure if you read it? > =20 > Yes, I just wanted to make sure that whatever change we make in the=20 draft is coordinated over the protocol list. Regards, -Robert >regards >Hormuzd > >-----Original Message----- >From: forces-protocol-bounces@ietf.org >[mailto:forces-protocol-bounces@ietf.org] On Behalf Of Robert Haas >Sent: Wednesday, October 13, 2004 2:25 AM >To: hadi@znyx.com >Cc: forces-protocol@ietf.org >Subject: Re: [Forces-protocol] effect of new BNF, changes etc etc on >protocol > >To add to Jamal's list of open issues, I wanted to remind my co-authors=20 >of the following: > >Some time back, there has been a long thread initiated by comments from=20 >Furquan (heartbeats, channels, TMLs vs PL responsibilities, missing FSMs > >to describe CE and FE behavior in cases such as failover), and a very=20 >short thread with valuable comments from Zsolt (TML layering, FE ID=20 >allocation by CE, query-response correlation and use of sequence >numbers). > >Did we capture the issues raised in those threads into an open-issue=20 >list ? I think we did not agree yet how to answer all of their comments, > >yet they are essential for a sound base of the ForCES protocol, I think. > >So I will focus now on some of the issues related to heartbeat,=20 >addressing and layering, and bring up proposals to our list so we are=20 >all aware and can agree on them. I encourage my co-authors to do the=20 >same and revisit those threads if necessary. Incorporating those=20 >proposals into the relevant sections of the draft could be the editor's=20 >task. Or do we want to proceed differently ? > >Regards, >-Robert > > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 13 15:53:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00026 for ; Wed, 13 Oct 2004 15:53:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHpN4-0004sf-3u for forces-protocol-web-archive@ietf.org; Wed, 13 Oct 2004 16:05:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHoxt-0007zP-CW; Wed, 13 Oct 2004 15:39:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHorh-0004KO-EE for forces-protocol@megatron.ietf.org; Wed, 13 Oct 2004 15:32:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28099 for ; Wed, 13 Oct 2004 15:32:49 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHp2h-0004Hl-8W for forces-protocol@ietf.org; Wed, 13 Oct 2004 15:44:12 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9DJZsUM021052; Wed, 13 Oct 2004 19:35:54 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9DJZaKO001412; Wed, 13 Oct 2004 19:35:40 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101312320712485 ; Wed, 13 Oct 2004 12:32:07 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 13 Oct 2004 12:32:06 -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 Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc on protocol Date: Wed, 13 Oct 2004 12:32:05 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02DEBD58@orsmsx408> Thread-Topic: [Forces-protocol] effect of new BNF, changes etc etc on protocol Thread-Index: AcSxWnQ/onw96bymRHuaFM7ERqWLgQAAD8jQ From: "Khosravi, Hormuzd M" To: "Robert Haas" X-OriginalArrivalTime: 13 Oct 2004 19:32:06.0577 (UTC) FILETIME=[52FE8A10:01C4B15B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Robert,=20 -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 >We can then discuss them and ask our co-editor to >incorporate the changes in the draft. > I hadn't seen this co-editor word until now. I thought Avri was the=20 editor and we are supposed to be the co-authors. Anyway, I assume you=20 meant Avri. [HK] Yes I meant Avri, I saw this word in the draft actually...Avri's name is listed on the front page as co-editor :) This terminology came from her directly...I thought the front page would say FP Team, but I am fine with this as well. BTW, can we use first names in emails, instead of co-authors, etc ;)) regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 14 14:04:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12116 for ; Thu, 14 Oct 2004 14:04:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIA8f-00086C-2F for forces-protocol-web-archive@ietf.org; Thu, 14 Oct 2004 14:15:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI9wS-0004DU-T6; Thu, 14 Oct 2004 14:03:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI9vT-0003xA-3t for forces-protocol@megatron.ietf.org; Thu, 14 Oct 2004 14:02:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12005 for ; Thu, 14 Oct 2004 14:02:05 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIA6f-000838-I0 for forces-protocol@ietf.org; Thu, 14 Oct 2004 14:13:42 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101411043734:25632 ; Thu, 14 Oct 2004 11:04:37 -0700 From: Jamal Hadi Salim To: "Joel M. Halpern" In-Reply-To: <1097593071.1029.23.camel@jzny.localdomain> References: <5.1.0.14.0.20041012071000.02398e08@mail.megisto.com> <5.1.0.14.0.20041012092532.024079c8@mail.megisto.com> <1097593071.1029.23.camel@jzny.localdomain> Organization: Znyx Networks Message-Id: <1097776916.1041.55.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Oct 2004 14:01:57 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/14/2004 11:04:37 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/14/2004 11:04:43 AM, Serialize complete at 10/14/2004 11:04:43 AM Content-Type: multipart/mixed; boundary="=-SR3luM+Thp8GruplR6R3" X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: ram.gopal@nokia.com, Steve Blake , avri@psg.com, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , "Wang, Weiming" , Robert Haas Subject: [Forces-protocol] PATH layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 --=-SR3luM+Thp8GruplR6R3 Content-Type: text/plain Content-Transfer-Encoding: 7bit In order to speed up the discussion so both sides can make sense of what is being said on the path selection, Ive put some thoughts in a little document and will continue updating so as to capture the discussion. Its easier to capture the discussion in this one centralized note. Please respond. cheers, jamal --=-SR3luM+Thp8GruplR6R3 Content-Disposition: attachment; filename=path-data-oper.txt Content-Type: text/plain; name=path-data-oper.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This doc builds up on what was posted by Steve/Zsolt[1] to try to map to protocol. It by no means imposes a decision i.e tghis is merely here as a discussion place holder with the a desire to speed things up. NOTE: ----- A small reminder on layout: main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = 0x45 | | | | | +-- LFBInstance = 0x1234 | | | +-- T = ADD | | | | | +-- // one or more path targets | | // with their data here to be added | | // This is the discussion point | | | +-- T = DEL | . | | . +-- // one or more path targets to be deleted | . // This is the discussion point | 1) There could be multiple operations on any instance 2) path-data comes after the operation. 3) there could be multiple path-data entities targeted by the same operation (eg a CREATE, GET etc). A possible path-data layout. ---------------------------- PATH-DATA := [DATA] PATH := [BLOCK_OR_KEY_NOTATION] ID_TLV := flags BLOCK_OR_KEY_NOTATION := different BLOCK or KEY extension defined in section 4.2 and 4.3 of [1] DATA : = Optional variable sized data dependent on PATH and applied operations (eg GET will not have DATA). IDs := a series of 32bit IDs (whose size is given by IDcount) defining the path. * flags are used to further refine the operation to be applied on the ID_TLV. Some larification in relation to [1]: ------------------------------------- [1] represents a requirement gathering/place holder. This document is into details closer to implementation. ID_TLV: ----- The V of the ID_TLV contains a 16 bit flags field and a series of 32 bit IDs. The flags further refine the semantics of the target attribute or set of attributes for the given operation. The L provides the variable length. ID_TLV flags; ------------ Derived from netlink and BSD route sockets to meet requirements defined in [1]: --> F_EXCL: The exclusive flag. Donot replace the config attribute(s) if already exists - Report back error instead. A CREATE operation with this flag is equivalent to INS_IDX if index is passed and equivalent to INS if index is not passed in the IDs. A DEL with this flag is equivalent to DEL! in [1]. Without this flag the equivalency is to DEL. --> F_REPLACE: Replace existing matching config attribute(s) with passed data. An index must be passed. In the case of key operations, a KEY must be passed. A CREATE operation with this flag is equivalent to a SET or a INS_IDX!. Steve/Zsolt please double check that this is matching to your doc. A CREATE operation with F_EXCL|F_REPLACE is equivalent to SET! Additional flags: ---------------- These flags reside within the same ID_TLV. --> F_APPEND: Add to the end of the object list even if matching entry exists. Not defined in [1] ** Other flags used for block operations mentioned in the BLOCK section. BLOCK and KEY path selection ----------------------------- The block operations in [1] include a start index followed by a range operator of some form. The variant described in [1] is not needed. To get access to all of table contents, the IDs merely need to point to the table. * Recommendation is to make the BLOCK operations part of the ID_TLV. - Steal the 16 bits unused before to indicate the ID count so as to have a clear marker where the IDs end in the encoding. - Additional flags needed: 1)F_BLOCK_ON, to indicate block selector embeded 2)F_KEY_ON, to indicate a key selector embeded #1 and #2 qare mutually exclusive. 3) F_REV_TRAVERSE, to indicate reverse progress in the access. 4) F_KEY_MODE (2 bits or more) to select the KEY mode in case #2 is on. +++ In the case of block operations, The second last ID in the IDs is a start index ("a" from [1]). The last ID will depending on the flag be a counter ("N" or "-N" from [1]) or upper range index ("b" from [1]). +++ In the case of the associative paths, the flags will indicate that we are using associative approach as well as the mode. In such a case, the optional KEY and KEY-DATA is attached at the end depending on mode selected. If we consider the above, then the BNF becomes: PATH-DATA := [DATA] PATH := ID_TLV := flags IDcount [KEY][KEY-DATA] DATA: ----- Not discussing the optional data right now; a lot of details above need ironing out first. DATA is complex twist when it comes with variable sized data. $Log: path-data-oper.txt,v $ Revision 1.1 2004/10/14 13:12:32 hadi Initial revision --=-SR3luM+Thp8GruplR6R3 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=-SR3luM+Thp8GruplR6R3-- From forces-protocol-bounces@ietf.org Thu Oct 14 14:24:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13237 for ; Thu, 14 Oct 2004 14:24:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIARw-0008SI-Af for forces-protocol-web-archive@ietf.org; Thu, 14 Oct 2004 14:35:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIADY-000877-5f; Thu, 14 Oct 2004 14:20:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIAC0-0007ux-Vg for forces-protocol@megatron.ietf.org; Thu, 14 Oct 2004 14:19:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13048 for ; Thu, 14 Oct 2004 14:19:11 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIAN2-0008N5-Q8 for forces-protocol@ietf.org; Thu, 14 Oct 2004 14:30:48 -0400 Received: from JLaptop.megisto.com ([192.168.20.163]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Oct 2004 14:18:41 -0400 Message-Id: <5.1.0.14.0.20041014140927.038ed048@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Oct 2004 14:18:05 -0400 To: hadi@znyx.com From: "Joel M. Halpern" In-Reply-To: <1097776916.1041.55.camel@jzny.localdomain> References: <1097593071.1029.23.camel@jzny.localdomain> <5.1.0.14.0.20041012071000.02398e08@mail.megisto.com> <5.1.0.14.0.20041012092532.024079c8@mail.megisto.com> <1097593071.1029.23.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Oct 2004 18:18:41.0382 (UTC) FILETIME=[3BB4E060:01C4B21A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ram.gopal@nokia.com, Steve Blake , avri@psg.com, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , "Wang, Weiming" , Robert Haas Subject: [Forces-protocol] Re: PATH layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 A couple of comments, some relating to this, and some relating to the underlying operation description. Firstly, I am somewhat uncomfortable with the block operations. I have trouble actually seeing cases where one will need to GET (or even more rarely) SET a specific block in a table, but not the whole table. Secondly, I wonder if it is worth the extra wrappers just to allow multiple path-data sets in the same operation TLV. If we restrict things to one path-data per operation TLV, things get simpler. Related to the above, I think that the flags are in the ID_TLV because each target may have different flag settings. But these flags really modify the operation, not the target. (Thus, semantically I would like the flags on the operation. Which is fine if there is one target per operation.) Having a TLV to hold the ID_TLV and having an ID_COUNT is redundant. (At which point I get repetitive., sorry.) If we have one target per operation, then we just put the ID_COUNT, id-sequence in the header of the operation. There is no need for an extra TLV to hold it. I am not sure where / how to put in the date for associative keying. Also, I would like to require that associative keys always be unique, so the F_APPEND should not be needed or permitted. Yours, Joel At 02:01 PM 10/14/2004 -0400, Jamal Hadi Salim wrote: >In order to speed up the discussion so both sides can make sense >of what is being said on the path selection, Ive put some thoughts >in a little document and will continue updating so as to capture >the discussion. Its easier to capture the discussion in this one >centralized note. > >Please respond. > >cheers, >jamal > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 14 15:02:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15842 for ; Thu, 14 Oct 2004 15:02:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIB2k-0000ij-F1 for forces-protocol-web-archive@ietf.org; Thu, 14 Oct 2004 15:13:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIAqm-0000q1-8l; Thu, 14 Oct 2004 15:01:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIAlc-0006DP-5o for forces-protocol@megatron.ietf.org; Thu, 14 Oct 2004 14:56:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15633 for ; Thu, 14 Oct 2004 14:55:58 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIAwo-0000dq-Iu for forces-protocol@ietf.org; Thu, 14 Oct 2004 15:07:35 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101411583501:25809 ; Thu, 14 Oct 2004 11:58:35 -0700 Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc on protocol From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E025791CB@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E025791CB@orsmsx408> Organization: Znyx Networks Message-Id: <1097780156.1037.110.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Oct 2004 14:55:56 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/14/2004 11:58:35 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/14/2004 11:58:36 AM, Serialize complete at 10/14/2004 11:58:36 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Hormuzd, I will put a little note together and post in the next 30 minutes or so. In regards to your draft target, I agree we should shoot to beat the 25th deadline (will depend on how we move forward on basics first). So lets shoot for next Friday to be done with basics? cheers, jamal On Wed, 2004-10-13 at 10:25, Khosravi, Hormuzd M wrote: > Jamal, > > Thanks for posting this, I am most fine with what you propose. > Pls see my comments below... > > -----Original Message----- > From: forces-protocol-bounces@ietf.org > [mailto:forces-protocol-bounces@ietf.org] On Behalf Of Jamal Hadi Salim > > 1) BNF changes. > Major issue being the query and query response appear to be gone. > Instead we now have a CONFIG/GET and CONFIG-resp/GET > [HK] We could still keep the Query and Config separate, I don't think we > have to remove Config...it would actually be cleaner that way. But I am > fine if most of you would like to remove it. > > > Unfortunately unless the data-path is well defined this is going to be > tricky to move forward on. So i will put some effort in getting the > path-data definition going. Please chip in the discussion with the other > folks from the model team. > > 2) The fact that its now a world of "everything is an LFB" and > introduction of FE protocol and FEObject LFBs implies that same messages > may have to go. Specifically, it seem state maintanance and event > messages would need redefining. > [HK] Yes we need to decide about State Maintenance msgs, I am fine > either ways. I don't think Event msgs are affected by this. > > It is my belief that draft 1 needs to address these issues to look > progressive. It shouldnt matter if we publish it in time or not. > [HK] I think this is important in order to make a presentation and show > progress. > > Regards > Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 14 15:18:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17773 for ; Thu, 14 Oct 2004 15:18:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIBID-000133-Hs for forces-protocol-web-archive@ietf.org; Thu, 14 Oct 2004 15:29:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIB3C-0001Kr-GV; Thu, 14 Oct 2004 15:14:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIB1Z-0000rT-5o for forces-protocol@megatron.ietf.org; Thu, 14 Oct 2004 15:12:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17156 for ; Thu, 14 Oct 2004 15:12:27 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIBCl-0000wh-Fj for forces-protocol@ietf.org; Thu, 14 Oct 2004 15:24:05 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101412145944:25856 ; Thu, 14 Oct 2004 12:14:59 -0700 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <1097780156.1037.110.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E025791CB@orsmsx408> <1097780156.1037.110.camel@jzny.localdomain> Organization: Znyx Networks Message-Id: <1097781140.1037.130.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Oct 2004 15:12:20 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/14/2004 12:14:59 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/14/2004 12:15:05 PM, Serialize complete at 10/14/2004 12:15:05 PM Content-Type: multipart/mixed; boundary="=-y9DxshMzxoLtVr245hye" X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: forces-protocol@ietf.org Subject: [Forces-protocol] sync with BNF as discussed with model folks X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 --=-y9DxshMzxoLtVr245hye Content-Type: text/plain Content-Transfer-Encoding: 7bit In my usual style (which i find effective - nothing is forgotten) is to capture things contionously. I have cross referenced the messages and what i think should change. Not cast in stone, but we have to start somewhere. I think its imperative we clear the air, otherwise its a waste of time updating the draft. cheers, jamal --=-y9DxshMzxoLtVr245hye Content-Disposition: attachment; filename=potential-protocol-changes.txt Content-Type: text/plain; name=potential-protocol-changes.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Assumptions: ------------ a) Start by assuming BNF as discussed with model team (posted earlier). b) When no value is added by BNF discussed restore old scheme and fix associated BNF piece. c) Everything is a LFB. We now have two LFBs as discussed in 3.3.2 Main header ----------- No changes imposed by BNF 6.1 Association Messages ------------------------ 6.1.1 Association setup Message ------------------------------- Stays same, exception: No need for HB registration. That is now targeted to the FE protocol LFB. A suggestion is that perhaps a name TLV may need to be passed. Same level as LFB Select example main hdr (eg type = Association setup) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = FENAME | +-- "myname" 6.1.2 Association setup Response -------------------------------- Use a result TLV since as is now main hdr (eg type = Association setup response) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = FEResult | +-- resultvalue 6.1.3 Association Teardown message ----------------------------------- main hdr (eg type = Association tear) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = FEReason | +-- "myreason" 6.2 Query Messages ------------------- Gone. Replacement is: 6.2.1 Query message ------------------- main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance | | | | | +-- T = GET | | | | | +-- // one or more path targets | | // under discussion | | The LFB is targeted. So if you need to find a route from an LPM you target that LFB. If you need to find neighbors of an FE you target the FE object LFB. The response is exactly the same as above. 6.3 Configuration Message -------------------------- 6.3.1 Config request ---------------------- main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance | | | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | In other words: Very similar to the way we have it already except the naming has changed and we can target multiple opertaions and multiple paths in an LFB instance 6.3.2 Config Response --------------------- IMO the same as above except direction is from FE->CE except type is config-response. Or maybe we introduce a new TLV called result. Sender will need to request a summary or message in totality echoed back. 6.4 Events ---------- I thought we said we will have a Event subscription message, I dont see it anywhere. 1 )Given the concept of "everything is an LFB" it is my opinion that subscriptions should happen at per LFB level. i.e the model (xml file) will have to define what events a LFB class throws. 2) Given you can amp _any_ attribute to a path ID, then I see the event notifications and responses message layout being very much like the config messages excpet the type will be one of those two (notify and notify-response) 6.5 Packet redirect ------------------- One suggestion: main hdr (eg type = Packet Redirect) | | +--- T = LFBselect | | | +-- LFBCLASSID = target class | | | | | +-- LFBInstance = target instance | | | +-- T = PACKET_REDIR_OPER | | | | | +-- // one or more packets 6.6 State Maintanance --------------------- Gone. This should target the FE protocol object LFB . $Log: potential-protocol-changes.txt,v $ Revision 1.1 2004/10/14 18:53:40 hadi Initial revision --=-y9DxshMzxoLtVr245hye Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=-y9DxshMzxoLtVr245hye-- From forces-protocol-bounces@ietf.org Thu Oct 14 15:19:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17944 for ; Thu, 14 Oct 2004 15:19:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIBJd-000156-LD for forces-protocol-web-archive@ietf.org; Thu, 14 Oct 2004 15:31:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIB7V-0003J6-5w; Thu, 14 Oct 2004 15:18:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIB3W-0001Ov-Uh for forces-protocol@megatron.ietf.org; Thu, 14 Oct 2004 15:14:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17354 for ; Thu, 14 Oct 2004 15:14:28 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIBEj-0000zV-0x for forces-protocol@ietf.org; Thu, 14 Oct 2004 15:26:06 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101412170463:25862 ; Thu, 14 Oct 2004 12:17:04 -0700 From: Jamal Hadi Salim To: "Joel M. Halpern" In-Reply-To: <5.1.0.14.0.20041014140927.038ed048@mail.megisto.com> References: <1097593071.1029.23.camel@jzny.localdomain> <5.1.0.14.0.20041012071000.02398e08@mail.megisto.com> <5.1.0.14.0.20041012092532.024079c8@mail.megisto.com> <1097593071.1029.23.camel@jzny.localdomain> <5.1.0.14.0.20041014140927.038ed048@mail.megisto.com> Organization: Znyx Networks Message-Id: <1097781264.1039.134.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Oct 2004 15:14:24 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/14/2004 12:17:04 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/14/2004 12:17:06 PM, Serialize complete at 10/14/2004 12:17:06 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Steve Blake , avri@psg.com, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , "Wang, Weiming" , Robert Haas Subject: [Forces-protocol] Re: PATH layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Thanks for responding Joel. On Thu, 2004-10-14 at 14:18, Joel M. Halpern wrote: > A couple of comments, some relating to this, and some relating to the > underlying operation description. > > Firstly, I am somewhat uncomfortable with the block operations. I have > trouble actually seeing cases where one will need to GET (or even more > rarely) SET a specific block in a table, but not the whole table. One example i can think of is say you want to update all NH entries in an LPM instance X previously pointing to NH table instance Y index 10 to now point to NH Table instance Y index 20. You could send multiple batched messages or one with block/ranges. > Secondly, I wonder if it is worth the extra wrappers just to allow multiple > path-data sets in the same operation TLV. If we restrict things to one > path-data per operation TLV, things get simpler. > I am indifferent. One wastes 32 more bits than the other. I would vouch for simplicty at the cost of 32 more bits. > Related to the above, I think that the flags are in the ID_TLV because each > target may have different flag settings. But these flags really modify the > operation, not the target. (Thus, semantically I would like the flags on > the operation. Which is fine if there is one target per operation.) > fine with me. Other people please comment on this. > Having a TLV to hold the ID_TLV and having an ID_COUNT is redundant. (At > which point I get repetitive., sorry.) If we have one target per > operation, then we just put the ID_COUNT, id-sequence in the header of the > operation. There is no need for an extra TLV to hold it. I am not sure > where / how to put in the date for associative keying. > But how do you know where the ID ends? Are you suggesting to move IDs and flags into the operation TLV? > Also, I would like to require that associative keys always be unique, so > the F_APPEND should not be needed or permitted. > Just threw it in there because it exists in BSD and Linux and has some uses there. Fine with getting rid of it. Other people please speak up. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 14 15:21:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18222 for ; Thu, 14 Oct 2004 15:21:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIBL7-000173-Km for forces-protocol-web-archive@ietf.org; Thu, 14 Oct 2004 15:32:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIB8x-0004Nh-2x; Thu, 14 Oct 2004 15:20:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIB81-0003gD-Cz for forces-protocol@megatron.ietf.org; Thu, 14 Oct 2004 15:19:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17885 for ; Thu, 14 Oct 2004 15:19:07 -0400 (EDT) Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIBJD-00013c-N8 for forces-protocol@ietf.org; Thu, 14 Oct 2004 15:30:45 -0400 Received: from [204.85.2.252] (helo=[192.168.168.45]) by server26.totalchoicehosting.com with esmtp (Exim 4.43) id 1CIB74-0005Vc-G9; Thu, 14 Oct 2004 15:18:10 -0400 From: Zsolt Haraszti To: "Joel M. Halpern" In-Reply-To: <5.1.0.14.0.20041014140927.038ed048@mail.megisto.com> References: <1097593071.1029.23.camel@jzny.localdomain> <5.1.0.14.0.20041012071000.02398e08@mail.megisto.com> <5.1.0.14.0.20041012092532.024079c8@mail.megisto.com> <1097593071.1029.23.camel@jzny.localdomain> <5.1.0.14.0.20041014140927.038ed048@mail.megisto.com> Content-Type: text/plain Message-Id: <1097781293.2893.27.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 14 Oct 2004 15:14:54 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , avri@psg.com, donglg@mail.hzic.edu.cn, "Khosravi, Hormuzd M" , "Yang, Lily L" , forces-protocol@ietf.org, Jamal Hadi Salim , Alan DeKok , Ellen M Deleganes , "Wang, Weiming" , Robert Haas Subject: [Forces-protocol] Re: PATH layout X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zsolt@nc.rr.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit On Thu, 2004-10-14 at 14:18, Joel M. Halpern wrote: > A couple of comments, some relating to this, and some relating to the > underlying operation description. > > Firstly, I am somewhat uncomfortable with the block operations. I have > trouble actually seeing cases where one will need to GET (or even more > rarely) SET a specific block in a table, but not the whole table. > Here is an example: At the CE's layer a diffserv policy on an interface will contain a number of policy class definitions, each based on an ACL. When this is translated into entries in a classifier LFB table in the FE, you will have a block of consecutive entries corresponding to each policy class (the number of entries will correlate with the complexity of the ACL). When I add a new policy class to the configuration at the CLI, this will require to add a bunch of entries to the classifier table (also touching other LFBs, but I focus on the classifier in this example). In this scenario I certainly do not need to change the whole table, but I need to add a bunch of entries. Similarly, if one or more policy classes are deleted, a large number of entries (but not the whole table) needs to be deleted from the LFB's table. If a classifier table in the Classifier holds the filters for more than one interface, block ADD/DEL operations will be required when Diffserv is enabled/disabled on one or a subset of the interfaces. Regarding GET operations: the same granularity must be provided when grabbing the counter content. The CLI may issue a request for the diffserv counters associated with just one interface, or just one policy. The most skepticism regarding ForCES is coming from the efficiency angle. I think it is imperative that we enable efficient encoding of block operations. > Secondly, I wonder if it is worth the extra wrappers just to allow multiple > path-data sets in the same operation TLV. If we restrict things to one > path-data per operation TLV, things get simpler. > I agree with this one. > Related to the above, I think that the flags are in the ID_TLV because each > target may have different flag settings. But these flags really modify the > operation, not the target. (Thus, semantically I would like the flags on > the operation. Which is fine if there is one target per operation.) Agree. This is all before actually reading Jamal's recent posting... /zsolt > Having a TLV to hold the ID_TLV and having an ID_COUNT is redundant. (At > which point I get repetitive., sorry.) If we have one target per > operation, then we just put the ID_COUNT, id-sequence in the header of the > operation. There is no need for an extra TLV to hold it. I am not sure > where / how to put in the date for associative keying. > > Also, I would like to require that associative keys always be unique, so > the F_APPEND should not be needed or permitted. > > Yours, > Joel > > At 02:01 PM 10/14/2004 -0400, Jamal Hadi Salim wrote: > > >In order to speed up the discussion so both sides can make sense > >of what is being said on the path selection, Ive put some thoughts > >in a little document and will continue updating so as to capture > >the discussion. Its easier to capture the discussion in this one > >centralized note. > > > >Please respond. > > > >cheers, > >jamal > > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 14 15:39:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20140 for ; Thu, 14 Oct 2004 15:39:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIBcd-0001WP-Dj for forces-protocol-web-archive@ietf.org; Thu, 14 Oct 2004 15:50:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIBPO-0004zP-8q; Thu, 14 Oct 2004 15:37:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIBLG-0002u5-C9 for forces-protocol@megatron.ietf.org; Thu, 14 Oct 2004 15:32:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19067 for ; Thu, 14 Oct 2004 15:32:48 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIBWR-0001Hn-HO for forces-protocol@ietf.org; Thu, 14 Oct 2004 15:44:26 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9EJVev4010215; Thu, 14 Oct 2004 19:31:40 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9EJMxqc001233; Thu, 14 Oct 2004 19:23:04 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101412321105447 ; Thu, 14 Oct 2004 12:32:11 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 14 Oct 2004 12:32:11 -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 Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc onprotocol Date: Thu, 14 Oct 2004 12:32:10 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02E27CB8@orsmsx408> Thread-Topic: [Forces-protocol] effect of new BNF, changes etc etc onprotocol Thread-Index: AcSyH3bzs56tugi6QFir4/M6lAH8nwABH8dA From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 14 Oct 2004 19:32:11.0267 (UTC) FILETIME=[8033ED30:01C4B224] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Jamal, Not sure what you mean by the basics, but we need to move faster...next Friday is 22nd. I hope we start updating sections sooner than that, hopefully we would be done with discussions in a few days...I know it will be difficult, I am keeping my fingers crossed :) Regards Hormuzd=20 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Thursday, October 14, 2004 11:56 AM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc onprotocol Hormuzd, I will put a little note together and post in the next 30 minutes or so. In regards to your draft target, I agree we should shoot to beat the 25th deadline (will depend on how we move forward on basics first). So lets shoot for next Friday to be done with basics? cheers, jamal On Wed, 2004-10-13 at 10:25, Khosravi, Hormuzd M wrote: > Jamal, >=20 > Thanks for posting this, I am most fine with what you propose. > Pls see my comments below... >=20 > -----Original Message----- > From: forces-protocol-bounces@ietf.org > [mailto:forces-protocol-bounces@ietf.org] On Behalf Of Jamal Hadi Salim >=20 > 1) BNF changes. > Major issue being the query and query response appear to be gone. > Instead we now have a CONFIG/GET and CONFIG-resp/GET > [HK] We could still keep the Query and Config separate, I don't think we > have to remove Config...it would actually be cleaner that way. But I am > fine if most of you would like to remove it. >=20 > > Unfortunately unless the data-path is well defined this is going to be > tricky to move forward on. So i will put some effort in getting the > path-data definition going. Please chip in the discussion with the other > folks from the model team. >=20 > 2) The fact that its now a world of "everything is an LFB" and > introduction of FE protocol and FEObject LFBs implies that same messages > may have to go. Specifically, it seem state maintanance and event > messages would need redefining. > [HK] Yes we need to decide about State Maintenance msgs, I am fine > either ways. I don't think Event msgs are affected by this. >=20 > It is my belief that draft 1 needs to address these issues to look > progressive. It shouldnt matter if we publish it in time or not. > [HK] I think this is important in order to make a presentation and show > progress. >=20 > Regards > Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 14 16:18:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25338 for ; Thu, 14 Oct 2004 16:18:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CICEI-0002cD-N0 for forces-protocol-web-archive@ietf.org; Thu, 14 Oct 2004 16:29:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIBxa-00041D-7R; Thu, 14 Oct 2004 16:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIBvL-0002Bn-1O for forces-protocol@megatron.ietf.org; Thu, 14 Oct 2004 16:10:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24359 for ; Thu, 14 Oct 2004 16:10:04 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIC6Y-0002Pz-UH for forces-protocol@ietf.org; Thu, 14 Oct 2004 16:21:43 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101413124255:25929 ; Thu, 14 Oct 2004 13:12:42 -0700 Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc onprotocol From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02E27CB8@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02E27CB8@orsmsx408> Organization: Znyx Networks Message-Id: <1097784603.1041.140.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Oct 2004 16:10:04 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/14/2004 01:12:42 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/14/2004 01:12:44 PM, Serialize complete at 10/14/2004 01:12:44 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Hormuzd, On Thu, 2004-10-14 at 15:32, Khosravi, Hormuzd M wrote: > Jamal, > > Not sure what you mean by the basics, but we need to move faster...next > Friday is 22nd. By basics i mean we agree on the basic things. I posted some doc about 30 minutes ago of how i saw the messages changing. I think thats part of basics. I also would say we should not have any challenges in ensuring the text is consistent with concept of FE object and protocol LFBs. > I hope we start updating sections sooner than that, hopefully we would > be done with discussions in a few days...I know it will be difficult, I > am keeping my fingers crossed :) > I am hoping we should be done or very close done with the sections then. Look at the doc i posted and lests start running then ;-> cheers, jamal > Regards > Hormuzd > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: Thursday, October 14, 2004 11:56 AM > To: Khosravi, Hormuzd M > Cc: forces-protocol@ietf.org > Subject: RE: [Forces-protocol] effect of new BNF, changes etc etc > onprotocol > > Hormuzd, > > I will put a little note together and post in the next 30 minutes or so. > In regards to your draft target, I agree we should shoot to beat the > 25th deadline (will depend on how we move forward on basics first). > So lets shoot for next Friday to be done with basics? > > > cheers, > jamal > > On Wed, 2004-10-13 at 10:25, Khosravi, Hormuzd M wrote: > > Jamal, > > > > Thanks for posting this, I am most fine with what you propose. > > Pls see my comments below... > > > > -----Original Message----- > > From: forces-protocol-bounces@ietf.org > > [mailto:forces-protocol-bounces@ietf.org] On Behalf Of Jamal Hadi > Salim > > > > 1) BNF changes. > > Major issue being the query and query response appear to be gone. > > Instead we now have a CONFIG/GET and CONFIG-resp/GET > > [HK] We could still keep the Query and Config separate, I don't think > we > > have to remove Config...it would actually be cleaner that way. But I > am > > fine if most of you would like to remove it. > > > > > > Unfortunately unless the data-path is well defined this is going to be > > tricky to move forward on. So i will put some effort in getting the > > path-data definition going. Please chip in the discussion with the > other > > folks from the model team. > > > > 2) The fact that its now a world of "everything is an LFB" and > > introduction of FE protocol and FEObject LFBs implies that same > messages > > may have to go. Specifically, it seem state maintanance and event > > messages would need redefining. > > [HK] Yes we need to decide about State Maintenance msgs, I am fine > > either ways. I don't think Event msgs are affected by this. > > > > It is my belief that draft 1 needs to address these issues to look > > progressive. It shouldnt matter if we publish it in time or not. > > [HK] I think this is important in order to make a presentation and > show > > progress. > > > > Regards > > Hormuzd > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 14 17:55:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10896 for ; Thu, 14 Oct 2004 17:55:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDkG-00076r-RK for forces-protocol-web-archive@ietf.org; Thu, 14 Oct 2004 18:06:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDVz-0005cu-PT; Thu, 14 Oct 2004 17:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIDSp-0004r3-3C for forces-protocol@megatron.ietf.org; Thu, 14 Oct 2004 17:48:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10318 for ; Thu, 14 Oct 2004 17:48:44 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIDe2-0006uI-NT for forces-protocol@ietf.org; Thu, 14 Oct 2004 18:00:24 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9ELmhGQ018912; Thu, 14 Oct 2004 21:48:43 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9ELcuqm020745; Thu, 14 Oct 2004 21:39:06 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101414481331601 ; Thu, 14 Oct 2004 14:48:13 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 14 Oct 2004 14:48:13 -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 Date: Thu, 14 Oct 2004 14:48:12 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02E28004@orsmsx408> Thread-Topic: sync with BNF as discussed with model folks Thread-Index: AcSyIcUibDWTWlsbSkuVjHUM9dEsGQACnHxw From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 14 Oct 2004 21:48:13.0210 (UTC) FILETIME=[811997A0:01C4B237] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: sync with BNF as discussed with model folks X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Jamal, Thanks for doing this, if this is the basics...I think it looks pretty good! We should be able to start updating the sections pretty soon :) I had a few comments... 6.1 -> looks good...could change some names for the Ts, but that's fine 6.2 -> I don't think this Has_to_be removed. We can still use the format similar to what you have suggested with the Query message...Unless we think that operations such as GET/SET need to be bundled in a single message (which has not been my experience), we can leave the Query msgs in with new format. 6.3 -> looks good...we might still need the Flags, also the Event Type is needed since Event Subscribe, UnSubscribe are currently part of this message. 6.4 -> answer to your question is above-subscription is part of Config msg currently. I think Event notification is quite different from Config and makes sense to have this separate. For most cases, these are asynchronous and do not need a response back either.(The format is similar to Config) 6.5 -> looks good. 6.6 -> Fine...I am assuming the States will be exchanged in Event msgs ? 6.7 -> remains the same (I assume) Let me know how you would like to proceed once we finalize this. I will be happy to update my sub-sections, but if you are eager to help out with writing the sub-sections as well, I am fine with that. regards Hormuzd=20 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 In my usual style (which i find effective - nothing is forgotten) is to capture things contionously. I have cross referenced the messages and what i think should change. Not cast in stone, but we have to start somewhere. I think its imperative we clear the air, otherwise its a waste of time updating the draft. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 14 22:46:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01782 for ; Thu, 14 Oct 2004 22:46:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIIIj-0003g7-U5 for forces-protocol-web-archive@ietf.org; Thu, 14 Oct 2004 22:58:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CII0o-00071k-U0; Thu, 14 Oct 2004 22:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIHxl-0006gc-2q for forces-protocol@megatron.ietf.org; Thu, 14 Oct 2004 22:37:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01488 for ; Thu, 14 Oct 2004 22:36:58 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CII91-0003Yh-6O for forces-protocol@ietf.org; Thu, 14 Oct 2004 22:48:40 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101419393215:26614 ; Thu, 14 Oct 2004 19:39:32 -0700 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02E28004@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02E28004@orsmsx408> Organization: ZNYX Networks Message-Id: <1097807813.1041.18.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 14 Oct 2004 22:36:53 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/14/2004 07:39:32 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/14/2004 07:39:36 PM, Serialize complete at 10/14/2004 07:39:36 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: sync with BNF as discussed with model folks X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Hormuzd, Great - Now we can make progress! On Thu, 2004-10-14 at 17:48, Khosravi, Hormuzd M wrote: > Jamal, > > Thanks for doing this, if this is the basics...I think it looks pretty > good! > We should be able to start updating the sections pretty soon :) > > I had a few comments... > 6.1 -> looks good...could change some names for the Ts, but that's fine Names are resolvable little detail we can worry about later. > 6.2 -> I don't think this Has_to_be removed. We can still use the format > similar to what you have suggested with the Query message...Unless we > think that operations such as GET/SET need to be bundled in a single > message (which has not been my experience), we can leave the Query msgs > in with new format. Theory is they can be bundled. Is there a reason you want to keep that type=query? > 6.3 -> looks good...we might still need the Flags, also the Event Type > is needed since Event Subscribe, UnSubscribe are currently part of this > message. Probably makes sense to keep event subscription under config. Sorry I missed that in my quick scan and thought it belonged to type=event in 6.4. Do we then need operation = Event_un/subscribe I suspect that events will end up being defined in the LFB XML definition and therefore will have a path to them (eg link event in port LFB being path 1.2.3 etc). In which case, the value of the Event_un/subscribe will be to the event. Thoughts? > 6.4 -> answer to your question is above-subscription is part of Config > msg currently. I think Event notification is quite different from Config > and makes sense to have this separate. For most cases, these are > asynchronous and do not need a response back either.(The format is > similar to Config) Agreed on the config. The notifications sound good for a start; we could refine later. > 6.5 -> looks good. Ok > 6.6 -> Fine...I am assuming the States will be exchanged in Event msgs ? Since everything is an LFB, then its per LFB event - in this case i would guess the states will belong to the FE Object LFB? > 6.7 -> remains the same (I assume) I missed that one, sorry. Again my take is this is gone. I would think this would per FE heartebats belong to the FE Protocol LFB. I think that the two FE LFBs deserve speacial attention now. We need to describe what they are expected to do in more detail. We also need to sync on them with the model people. > > Let me know how you would like to proceed once we finalize this. > I will be happy to update my sub-sections, but if you are eager to help > out with writing the sub-sections as well, I am fine with that. > My take on it is we can make progress sooner than i thought. I think what would be really valuable is to other people respond. If it was up to you and me, with concerted effort we can get it done by monday ;-> So I am optimistic we can get it done by Friday or sooner. Lets hear from the other people; Quiet a few sections need cleaning up to sync with the new approach ("everything is an LFB"); so more people we have, the better. It wont harm to start cleaning up the sections as per your earlier posting. cheers, jamal > regards > Hormuzd > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > In my usual style (which i find effective - nothing is forgotten) is to > capture things contionously. > I have cross referenced the messages and what i think should change. > Not cast in stone, but we have to start somewhere. > > I think its imperative we clear the air, otherwise its a waste of time > updating the draft. > > > cheers, > jamal > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 01:36:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10484 for ; Fri, 15 Oct 2004 01:36:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIKwM-0006Fc-2Q for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 01:47:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIKk4-0004qn-F1; Fri, 15 Oct 2004 01:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIKjd-0004iD-Fb for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 01:34:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10390 for ; Fri, 15 Oct 2004 01:34:36 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIKuw-0006Dt-5k for forces-protocol@ietf.org; Fri, 15 Oct 2004 01:46:18 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9F5XYSU003636; Fri, 15 Oct 2004 05:33:34 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9F5Or5P004421; Fri, 15 Oct 2004 05:24:56 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101422340429697 ; Thu, 14 Oct 2004 22:34:04 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 14 Oct 2004 22:34:04 -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 Date: Thu, 14 Oct 2004 22:33:52 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791DB@orsmsx408> Thread-Topic: sync with BNF as discussed with model folks Thread-Index: AcSyX9f5m9LyGtdlS1GQF35araHUIgAFxBKw From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 15 Oct 2004 05:34:04.0425 (UTC) FILETIME=[95528790:01C4B278] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: sync with BNF as discussed with model folks X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Thanks Jamal, my responses below. I think we are mostly insync, -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > 6.2 -> I don't think this Has_to_be removed. We can still use the format > similar to what you have suggested with the Query message...Unless we > think that operations such as GET/SET need to be bundled in a single > message (which has not been my experience), we can leave the Query msgs > in with new format. Theory is they can be bundled. Is there a reason you want to keep that type=3Dquery? [HK] The responses will be more involved for query, also the request might be more involved. The other reason is that I have never seen query bundled with SET/DEL in practice...Is this a requirement from Joel or the Model team ? I didn't get that impression, but I might have missed it. > 6.3 -> looks good...we might still need the Flags, also the Event Type > is needed since Event Subscribe, UnSubscribe are currently part of this > message. Probably makes sense to keep event subscription under config. Sorry I missed that in my quick scan and thought it belonged to type=3Devent = in 6.4. Do we then need operation =3D Event_un/subscribe [HK] Yes I suspect that events will end up being defined in the LFB XML definition and therefore will have a path to them (eg link event in port LFB being path 1.2.3 etc). In which case, the value of the Event_un/subscribe will be to the event. Thoughts? [HK] We could simplify this for generic events, but what you're suggesting seems reasonable. =20 > 6.4 -> answer to your question is above-subscription is part of Config > msg currently. I think Event notification is quite different from Config > and makes sense to have this separate. For most cases, these are > asynchronous and do not need a response back either.(The format is > similar to Config) Agreed on the config. The notifications sound good for a start; we could refine later.=20 [HK] Yep, our current format for these is similar to what you proposed > 6.6 -> Fine...I am assuming the States will be exchanged in Event msgs ? Since everything is an LFB, then its per LFB event - in this case i would guess the states will belong to the FE Object LFB?=20 [HK] Yes they would, I have no objection to FE Object or everything being a LFB. The FE States would be part of the FE object sent in Event msgs. > 6.7 -> remains the same (I assume) I missed that one, sorry. Again my take is this is gone. I would think this would per FE heartebats belong to the FE Protocol LFB. [HK] No, this doesn't need to go, its just a header anyways, it doesn't have any TLVs...its a very light weight msg, remember? I think you are confusing this with the FE Protocol Object, that doesn't have any effect on this msg. I think that the two FE LFBs deserve speacial attention now. We need to describe what they are expected to do in more detail. We also need to sync on them with the model people. [HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead on defining this Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 14:52:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28742 for ; Fri, 15 Oct 2004 14:52:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIXN1-0006nA-2L for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 15:04:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIX7j-0003o9-Ci; Fri, 15 Oct 2004 14:48:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIX5Z-0003Vg-OB for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 14:46:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28449 for ; Fri, 15 Oct 2004 14:46:04 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIXGz-0006gI-6A for forces-protocol@ietf.org; Fri, 15 Oct 2004 14:57:54 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101511483609:29239 ; Fri, 15 Oct 2004 11:48:36 -0700 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E025791DB@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E025791DB@orsmsx408> Organization: Znyx Networks Message-Id: <1097865957.1036.235.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Oct 2004 14:45:58 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/15/2004 11:48:36 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/15/2004 11:48:41 AM, Serialize complete at 10/15/2004 11:48:41 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: sync with BNF as discussed with model folks X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote: > Is there a reason you want to keep that type=query? > [HK] The responses will be more involved for query, > also the request might be more involved. This is true. But i dont know how you escape it with any scheme. If you ask to get, you must specify a path whether you use query or config. I would think the response will also have a path and the requested data for that path. > The other reason is that > I have never seen query bundled with SET/DEL in practice... I dont either; dont wanna rule it - but the more i think about it the more i am concluding its just about sending bundled commands. I think you can not possibly make it any simpler by introducing type=query. > Is this a requirement from > Joel or the Model team ? I didn't get that impression, but I might have > missed it. > I cant remember where it came or where the discussion took place. However, it does make logical sense given now that "everything is an LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to the same way: FE->LFBclass->LFBinstance->path Other than the operator, the operand to a GET is _exactly_ the same as a DEL. ADD has one extra operand. So its not really an issue of requirements; but one of a natural fit (as in the case of SNMP for example) If you can show that you can get an object easier with type=query i think that would help. Otherwise we would have an additional unneeded message. > > 6.3 -> looks good...we might still need the Flags, also the Event Type > > is needed since Event Subscribe, UnSubscribe are currently part of > this > > message. > > Probably makes sense to keep event subscription under config. Sorry > I missed that in my quick scan and thought it belonged to type=event in > 6.4. > Do we then need operation = Event_un/subscribe [HK] Yes > I suspect that events will end up being defined in the LFB XML > definition and therefore will have a path to them (eg link event in port > LFB being path 1.2.3 etc). > In which case, the value of the Event_un/subscribe will be to the > event. > Thoughts? [HK] We could simplify this for generic events, but what > you're suggesting seems reasonable. I think its safer to have the XML define what those events are. I sent a query to Joel who will forward it to the model team. He seems to be in agreement. Note this will be equivalent to SNMP traps (which is defined in the mib together with other attributes). As far as i can see, the event is another attribute. So it would look like: Operation = subscribe; operand = eventpath In our case we should go ahead and choose events that are necessary for the protocol to function and put them in eitehr the FE object or FE protocol LFB. The model team can them adapt from them > > 6.6 -> Fine...I am assuming the States will be exchanged in Event msgs > ? > > Since everything is an LFB, then its per LFB event - in this case i > would guess the states will belong to the FE Object LFB? > > [HK] Yes they would, I have no objection to FE Object or everything > being a LFB. The FE States would be part of the FE object sent in Event > msgs. > Sounds reasonable. > > 6.7 -> remains the same (I assume) > > I missed that one, sorry. > Again my take is this is gone. I would think this would per FE > heartebats belong to the FE Protocol LFB. > [HK] No, this doesn't need to go, its just a header anyways, it doesn't > have any TLVs...its a very light weight msg, remember? I think you are > confusing this with the FE Protocol Object, that doesn't have any effect > on this msg. But who is the target for this message now? Remember, there MUST be an LFB as the end target. > I think that the two FE LFBs deserve speacial attention now. > We need to describe what they are expected to do in more detail. We also > need to sync on them with the model people. > [HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead > on defining this > We may all have to be involved in these two. I think they are very important that we all need to be involved. BTW, Heres a suggestions: If we dont hear from anybody by Tuesday(I know Weiming mentioned something about being back Monday), lets start assuming noone will and move towards updating the draft to beat the deadline. I dont think people will mind if they are busy. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 17:41:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25369 for ; Fri, 15 Oct 2004 17:41:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIa0O-0006G0-8B for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 17:52:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIZcI-0004SO-G8; Fri, 15 Oct 2004 17:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIZAj-0005ba-8i for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 16:59:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17991 for ; Fri, 15 Oct 2004 16:59:30 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIZMA-00042X-AD for forces-protocol@ietf.org; Fri, 15 Oct 2004 17:11:22 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9FL2e6E010291; Fri, 15 Oct 2004 21:02:40 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9FKxGY4015194; Fri, 15 Oct 2004 21:02:28 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101513585624671 ; Fri, 15 Oct 2004 13:58:56 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 13:58:56 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 15 Oct 2004 13:58:54 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02E60996@orsmsx408> Thread-Topic: sync with BNF as discussed with model folks Thread-Index: AcSy5zh8WTvMXASATQGGF4MrmCIc7wAEfCHg From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 15 Oct 2004 20:58:56.0290 (UTC) FILETIME=[C90D2820:01C4B2F9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: sync with BNF as discussed with model folks X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable Jamal,=20 I think we are mostly insyc, the only issue seems to be whether to combine GET/SET in a single message. I will post an email to the model team and try to get their explicit opinion on this. Regarding HB msgs, these have been discussed a lot last time. I don't think these are affect by FE Object, etc...but this is a minor one, I think. Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Friday, October 15, 2004 11:46 AM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: RE: sync with BNF as discussed with model folks On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote: > Is there a reason you want to keep that type=3Dquery? > [HK] The responses will be more involved for query,=20 > also the request might be more involved.=20 This is true. But i dont know how you escape it with any scheme. If you ask to get, you must specify a path whether you use query or=20 config. I would think the response will also have a path and the requested data for that path. > The other reason is that=20 > I have never seen query bundled with SET/DEL in practice... I dont either; dont wanna rule it - but the more i think about it the more i am concluding its just about sending bundled commands. I think you can not possibly make it any simpler by introducing type=3Dquery. > Is this a requirement from > Joel or the Model team ? I didn't get that impression, but I might have > missed it. >=20 I cant remember where it came or where the discussion took place. However, it does make logical sense given now that "everything is an LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to the same way: FE->LFBclass->LFBinstance->path Other than the operator, the operand to a GET is _exactly_ the same as a DEL. ADD has one extra operand. So its not really an issue of requirements; but one of a natural fit (as in the case of SNMP for example) If you can show that you can get an object easier with type=3Dquery i think that would help. Otherwise we would have an additional unneeded message. > > 6.3 -> looks good...we might still need the Flags, also the Event Type > > is needed since Event Subscribe, UnSubscribe are currently part of > this > > message. >=20 > Probably makes sense to keep event subscription under config. Sorry > I missed that in my quick scan and thought it belonged to type=3Devent in > 6.4. > Do we then need operation =3D Event_un/subscribe [HK] Yes > I suspect that events will end up being defined in the LFB XML > definition and therefore will have a path to them (eg link event in port > LFB being path 1.2.3 etc). > In which case, the value of the Event_un/subscribe will be to the > event. > Thoughts? [HK] We could simplify this for generic events, but what > you're suggesting seems reasonable. I think its safer to have the XML define what those events are. I sent a query to Joel who will forward it to the model team. He seems to be in agreement. Note this will be equivalent to SNMP traps (which is defined in the mib together with other attributes). As far as i can see, the event is another attribute. So it would look like: Operation =3D subscribe; operand =3D eventpath In our case we should go ahead and choose events that are necessary for the protocol to function and put them in eitehr the FE object or FE protocol LFB. The model team can them adapt from them =20 > > 6.6 -> Fine...I am assuming the States will be exchanged in Event msgs > ? >=20 > Since everything is an LFB, then its per LFB event - in this case i > would guess the states will belong to the FE Object LFB?=20 >=20 > [HK] Yes they would, I have no objection to FE Object or everything > being a LFB. The FE States would be part of the FE object sent in Event > msgs. >=20 Sounds reasonable. > > 6.7 -> remains the same (I assume) >=20 > I missed that one, sorry. > Again my take is this is gone. I would think this would per FE > heartebats belong to the FE Protocol LFB. > [HK] No, this doesn't need to go, its just a header anyways, it doesn't > have any TLVs...its a very light weight msg, remember? I think you are > confusing this with the FE Protocol Object, that doesn't have any effect > on this msg. But who is the target for this message now? Remember, there MUST be an LFB as the end target. > I think that the two FE LFBs deserve speacial attention now. > We need to describe what they are expected to do in more detail. We also > need to sync on them with the model people. > [HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead > on defining this >=20 We may all have to be involved in these two. I think they are very important that we all need to be involved. BTW, Heres a suggestions: If we dont hear from anybody by Tuesday(I know Weiming mentioned something about being back Monday), lets start assuming noone will and move towards updating the draft to beat the deadline. I dont think people will mind if they are busy. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 17:41:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25408 for ; Fri, 15 Oct 2004 17:41:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIa1F-0006GZ-Pd for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 17:53:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIZcn-00056L-Fc; Fri, 15 Oct 2004 17:28:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIZFE-00087Q-Nb for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 17:04:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19236 for ; Fri, 15 Oct 2004 17:04:10 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIZQg-0004PW-2J for forces-protocol@ietf.org; Fri, 15 Oct 2004 17:16:02 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9FL7J6E013032; Fri, 15 Oct 2004 21:07:19 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9FL6JWY019181; Fri, 15 Oct 2004 21:07:06 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101514033325409 ; Fri, 15 Oct 2004 14:03:33 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 14:03:34 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 15 Oct 2004 14:03:32 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02E609BC@orsmsx408> Thread-Topic: GET/SET in one msg ? Thread-Index: AcSwX/tJ1YR4E8A4SFiND3Xz2pGrGwCmdcig From: "Khosravi, Hormuzd M" To: "Joel M. Halpern" , , "Steven Blake" , "Yang, Lily L" , "Alan DeKok" , "Deleganes, Ellen M" , X-OriginalArrivalTime: 15 Oct 2004 21:03:34.0388 (UTC) FILETIME=[6ECF8B40:01C4B2FA] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org Subject: [Forces-protocol] GET/SET in one msg ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Hi Folks, We (protocol team) are finalizing some of the msgs and one of the issues which is being discussed is whether GET/SET operation need to be combined in a single msg...(currently we have them as separate msgs). I have never seen this being done in practice i.e. command bundling of GET/SET, but if you guys have some experience/opinions on this, pls do let us know. Thanks a lot, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 17:43:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25562 for ; Fri, 15 Oct 2004 17:43:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIa2A-0006Ib-Co for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 17:54:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIZdI-0005qK-55; Fri, 15 Oct 2004 17:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIZMk-0003jX-S9 for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 17:11:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21247 for ; Fri, 15 Oct 2004 17:11:55 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIZYC-0004vn-4z for forces-protocol@ietf.org; Fri, 15 Oct 2004 17:23:48 -0400 Received: from JLaptop.megisto.com ([192.168.20.163]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Oct 2004 17:11:57 -0400 Message-Id: <5.1.0.14.0.20041015170907.024ca0c0@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Oct 2004 17:11:20 -0400 To: "Khosravi, Hormuzd M" , , "Steven Blake" , "Yang, Lily L" , "Alan DeKok" , "Deleganes, Ellen M" , From: "Joel M. Halpern" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02E609BC@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 15 Oct 2004 21:11:57.0214 (UTC) FILETIME=[9A84B3E0:01C4B2FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: forces-protocol@ietf.org Subject: [Forces-protocol] Re: GET/SET in one msg ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 I have two reactions: 1) Actually combining the two in the same request introduces all sorts of messy questions. 2) Most of the protocol design ought to be agnostic as to whether this is permitted or not. I would probably tend to structure a protocol mechanism so that it was possible to do such a thing, and then add a behavior description that says that the results of such an operation are unpredictable. Yours, Joel At 02:03 PM 10/15/2004 -0700, Khosravi, Hormuzd M wrote: >Hi Folks, > >We (protocol team) are finalizing some of the msgs and one of the issues >which is being discussed is whether GET/SET operation need to be >combined in a single msg...(currently we have them as separate msgs). I >have never seen this being done in practice i.e. command bundling of >GET/SET, but if you guys have some experience/opinions on this, pls do >let us know. > > >Thanks a lot, >Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 18:56:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01819 for ; Fri, 15 Oct 2004 18:56:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIbBB-0007zg-4p for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 19:08:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIayF-0007hp-7g; Fri, 15 Oct 2004 18:54:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIaw0-00074Q-76 for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 18:52:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01643 for ; Fri, 15 Oct 2004 18:52:24 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIb7R-0007uY-DY for forces-protocol@ietf.org; Fri, 15 Oct 2004 19:04:18 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9FMqHOH018996; Fri, 15 Oct 2004 22:52:17 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9FMtBWG013858; Fri, 15 Oct 2004 22:55:17 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101515514307707 ; Fri, 15 Oct 2004 15:51:43 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 15:51:42 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 15 Oct 2004 15:51:42 -0700 Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE018370B4@orsmsx408> Thread-Topic: GET/SET in one msg ? Thread-Index: AcSwX/tJ1YR4E8A4SFiND3Xz2pGrGwCmdcigAAPoovA= From: "Yang, Lily L" To: "Khosravi, Hormuzd M" , "Joel M. Halpern" , , "Steven Blake" , "Alan DeKok" , "Deleganes, Ellen M" , X-OriginalArrivalTime: 15 Oct 2004 22:51:42.0942 (UTC) FILETIME=[8A4A4FE0:01C4B309] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: GET/SET in one msg ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable I don't understand why you would want to do such a thing. Do you have any example in mind?=20 > -----Original Message----- > From: Khosravi, Hormuzd M=20 > Sent: Friday, October 15, 2004 2:04 PM > To: Joel M. Halpern; zsolt@petri-meat.com; Steven Blake;=20 > Yang, Lily L; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com > Cc: forces-protocol@ietf.org > Subject: GET/SET in one msg ? >=20 > Hi Folks, >=20 > We (protocol team) are finalizing some of the msgs and one of=20 > the issues which is being discussed is whether GET/SET=20 > operation need to be combined in a single msg...(currently we=20 > have them as separate msgs). I have never seen this being=20 > done in practice i.e. command bundling of GET/SET, but if you=20 > guys have some experience/opinions on this, pls do let us know. >=20 >=20 > Thanks a lot, > Hormuzd >=20 >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 18:58:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01960 for ; Fri, 15 Oct 2004 18:58:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIbDm-00082M-D8 for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 19:10:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIb0d-0000TI-7j; Fri, 15 Oct 2004 18:57:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIazk-0008Mj-V1 for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 18:56:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01837 for ; Fri, 15 Oct 2004 18:56:17 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIbBC-0007z3-6r for forces-protocol@ietf.org; Fri, 15 Oct 2004 19:08:11 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9FMtDSU002211; Fri, 15 Oct 2004 22:55:13 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9FMwwWO015729; Fri, 15 Oct 2004 22:59:14 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101515554308192 ; Fri, 15 Oct 2004 15:55:43 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 15:55:43 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 15 Oct 2004 15:55:41 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02E60C6D@orsmsx408> Thread-Topic: GET/SET in one msg ? Thread-Index: AcSwX/tJ1YR4E8A4SFiND3Xz2pGrGwCmdcigAAPoovAAAApaMA== From: "Khosravi, Hormuzd M" To: "Yang, Lily L" , "Joel M. Halpern" , , "Steven Blake" , "Alan DeKok" , "Deleganes, Ellen M" , X-OriginalArrivalTime: 15 Oct 2004 22:55:43.0107 (UTC) FILETIME=[19709530:01C4B30A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: GET/SET in one msg ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable No, I don't that's why I asked...since this was coming from Joel's proposal. I didn't get a good reason from his email either, but it seems like he would like to have it supported by the protocol anyway. Joel, do you have any examples for us ? Thanks Hormuzd=20 -----Original Message----- From: Yang, Lily L=20 Sent: Friday, October 15, 2004 3:52 PM To: Khosravi, Hormuzd M; 'Joel M. Halpern'; 'zsolt@petri-meat.com'; 'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M; 'ram.gopal@nokia.com' Cc: 'forces-protocol@ietf.org' Subject: RE: GET/SET in one msg ? I don't understand why you would want to do such a thing. Do you have any example in mind?=20 > -----Original Message----- > From: Khosravi, Hormuzd M=20 > Sent: Friday, October 15, 2004 2:04 PM > To: Joel M. Halpern; zsolt@petri-meat.com; Steven Blake;=20 > Yang, Lily L; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com > Cc: forces-protocol@ietf.org > Subject: GET/SET in one msg ? >=20 > Hi Folks, >=20 > We (protocol team) are finalizing some of the msgs and one of=20 > the issues which is being discussed is whether GET/SET=20 > operation need to be combined in a single msg...(currently we=20 > have them as separate msgs). I have never seen this being=20 > done in practice i.e. command bundling of GET/SET, but if you=20 > guys have some experience/opinions on this, pls do let us know. >=20 >=20 > Thanks a lot, > Hormuzd >=20 >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 20:23:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08641 for ; Fri, 15 Oct 2004 20:23:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcXZ-0001V8-PJ for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 20:35:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcAL-0004ug-Gc; Fri, 15 Oct 2004 20:11:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIc8T-0004Jl-HU for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 20:09:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07829 for ; Fri, 15 Oct 2004 20:09:23 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcJt-0001Fj-FO for forces-protocol@ietf.org; Fri, 15 Oct 2004 20:21:16 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101517115662:29762 ; Fri, 15 Oct 2004 17:11:56 -0700 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02E60C6D@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02E60C6D@orsmsx408> Organization: ZNYX Networks Message-Id: <1097885352.1049.8.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Oct 2004 20:09:12 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/15/2004 05:11:57 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/15/2004 05:11:58 PM, Serialize complete at 10/15/2004 05:11:58 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, zsolt@petri-meat.com, "Yang, Lily L" , Steve Blake , forces-protocol@ietf.org, "Joel M. Halpern" , Alan DeKok , Ellen M Deleganes X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit The question is not well worded. The real question should be whether the SET and or a GET should be using the same construct. As a reminder, we have the follwoing construct: Type{=config}->FE->LFBClass->LFBinstance->operation= {SET}-->data here 1) What we have in the currently discussed BNF is GET resides in the spot where SET is. 2) What we had before is a special type called query just for getting things. ** A side effect of batching multiple operations is ability to do a GET and a SET (or an add and a delete etc). The comparison is between #1 and #2 above. Should we keep the GET as in #1 or keep the query type in #2? cheers, jamal On Fri, 2004-10-15 at 18:55, Khosravi, Hormuzd M wrote: > No, I don't that's why I asked...since this was coming from Joel's > proposal. > I didn't get a good reason from his email either, but it seems like he > would like to have it supported by the protocol anyway. > > Joel, do you have any examples for us ? > > > Thanks > Hormuzd > > -----Original Message----- > From: Yang, Lily L > Sent: Friday, October 15, 2004 3:52 PM > To: Khosravi, Hormuzd M; 'Joel M. Halpern'; 'zsolt@petri-meat.com'; > 'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M; 'ram.gopal@nokia.com' > Cc: 'forces-protocol@ietf.org' > Subject: RE: GET/SET in one msg ? > > I don't understand why you would want to do such a thing. Do you have > any example in mind? > > > -----Original Message----- > > From: Khosravi, Hormuzd M > > Sent: Friday, October 15, 2004 2:04 PM > > To: Joel M. Halpern; zsolt@petri-meat.com; Steven Blake; > > Yang, Lily L; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com > > Cc: forces-protocol@ietf.org > > Subject: GET/SET in one msg ? > > > > Hi Folks, > > > > We (protocol team) are finalizing some of the msgs and one of > > the issues which is being discussed is whether GET/SET > > operation need to be combined in a single msg...(currently we > > have them as separate msgs). I have never seen this being > > done in practice i.e. command bundling of GET/SET, but if you > > guys have some experience/opinions on this, pls do let us know. > > > > > > Thanks a lot, > > Hormuzd > > > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 20:25:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08819 for ; Fri, 15 Oct 2004 20:25:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcZI-0001XY-0g for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 20:37:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcMB-0007zK-KC; Fri, 15 Oct 2004 20:23:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcBg-00059i-FU for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 20:12:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07986 for ; Fri, 15 Oct 2004 20:12:42 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcMy-0001Ja-9o for forces-protocol@ietf.org; Fri, 15 Oct 2004 20:24:35 -0400 Received: from JLaptop.megisto.com ([192.168.20.227]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Oct 2004 20:12:13 -0400 Message-Id: <5.1.0.14.0.20041015200825.02301940@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Oct 2004 20:11:36 -0400 To: "Khosravi, Hormuzd M" , "Yang, Lily L" , , "Steven Blake" , "Alan DeKok" , "Deleganes, Ellen M" , From: "Joel M. Halpern" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02E60C6D@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 16 Oct 2004 00:12:13.0778 (UTC) FILETIME=[C9B16320:01C4B314] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: GET/SET in one msg ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 If we are sure that the only two operations we will ever need are GET and SET, then we could probably simply declare that a message was either a GET message or a SET message. However, we have had suggestions of INSERT operations, and I would hate to design the protocol so that we could not add other operations later. And some combinations of operations may make sense together (insert item A. Add reference to A in item B. Delete obsoleted item C.) Thus, I tend to think that it makes sense to structure the protocol so that a single emssage can carry multiple operations. At the same time, as I said earlier, I would either prohibit or warn against combining update and read operations in the same request. Requests to read, for example to confirm the results of an update, ought to be sent separately so that the FE does not need to worry about the order of application. Yours, Joel At 03:55 PM 10/15/2004 -0700, Khosravi, Hormuzd M wrote: >No, I don't that's why I asked...since this was coming from Joel's >proposal. >I didn't get a good reason from his email either, but it seems like he >would like to have it supported by the protocol anyway. > >Joel, do you have any examples for us ? > > >Thanks >Hormuzd > >-----Original Message----- >From: Yang, Lily L >Sent: Friday, October 15, 2004 3:52 PM >To: Khosravi, Hormuzd M; 'Joel M. Halpern'; 'zsolt@petri-meat.com'; >'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M; 'ram.gopal@nokia.com' >Cc: 'forces-protocol@ietf.org' >Subject: RE: GET/SET in one msg ? > >I don't understand why you would want to do such a thing. Do you have >any example in mind? > > > -----Original Message----- > > From: Khosravi, Hormuzd M > > Sent: Friday, October 15, 2004 2:04 PM > > To: Joel M. Halpern; zsolt@petri-meat.com; Steven Blake; > > Yang, Lily L; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com > > Cc: forces-protocol@ietf.org > > Subject: GET/SET in one msg ? > > > > Hi Folks, > > > > We (protocol team) are finalizing some of the msgs and one of > > the issues which is being discussed is whether GET/SET > > operation need to be combined in a single msg...(currently we > > have them as separate msgs). I have never seen this being > > done in practice i.e. command bundling of GET/SET, but if you > > guys have some experience/opinions on this, pls do let us know. > > > > > > Thanks a lot, > > Hormuzd > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 20:25:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08848 for ; Fri, 15 Oct 2004 20:25:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcZQ-0001Xp-KQ for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 20:37:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcMB-0007zZ-Pu; Fri, 15 Oct 2004 20:23:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcBw-0005Bp-5g for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 20:13:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08036 for ; Fri, 15 Oct 2004 20:12:58 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcNO-0001KO-AJ for forces-protocol@ietf.org; Fri, 15 Oct 2004 20:24:51 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101517153393:29764 ; Fri, 15 Oct 2004 17:15:33 -0700 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02E60996@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02E60996@orsmsx408> Organization: ZNYX Networks Message-Id: <1097885570.1049.12.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Oct 2004 20:12:50 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/15/2004 05:15:34 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/15/2004 05:15:35 PM, Serialize complete at 10/15/2004 05:15:35 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: sync with BNF as discussed with model folks X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit On Fri, 2004-10-15 at 16:58, Khosravi, Hormuzd M wrote: > Jamal, > > I think we are mostly insyc, the only issue seems to be whether to > combine GET/SET in a single message. I will post an email to the model > team and try to get their explicit opinion on this. > I just clarified the real contention in this is whether we should keep query message or the GET. > Regarding HB msgs, these have been discussed a lot last time. I don't > think these are affect by FE Object, etc...but this is a minor one, I > think. I think its minor for deadline purpsoses. However, as is noted everything MUST target an LFB. This message also applies. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 20:25:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08883 for ; Fri, 15 Oct 2004 20:25:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcZW-0001Xv-DF for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 20:37:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcMC-0007zt-1d; Fri, 15 Oct 2004 20:23:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcCY-0005Nj-N9 for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 20:13:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08060 for ; Fri, 15 Oct 2004 20:13:37 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcNy-0001L4-Rh for forces-protocol@ietf.org; Fri, 15 Oct 2004 20:25:30 -0400 Received: from JLaptop.megisto.com ([192.168.20.227]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Oct 2004 20:13:34 -0400 Message-Id: <5.1.0.14.0.20041015201212.02416bf0@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Oct 2004 20:12:58 -0400 To: hadi@znyx.com, "Khosravi, Hormuzd M" From: "Joel M. Halpern" Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? In-Reply-To: <1097885352.1049.8.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02E60C6D@orsmsx408> <468F3FDA28AA87429AD807992E22D07E02E60C6D@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 16 Oct 2004 00:13:34.0887 (UTC) FILETIME=[FA09A370:01C4B314] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: zsolt@petri-meat.com, ram.gopal@nokia.com, Steve Blake , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 I personally prefer that the message type be independent of the operation type. Thus if we create conditional gets, or test and set, or any other interesting operations we don't have to discuss whether ti goes in the GET message or the SET message. Yours, Joel At 08:09 PM 10/15/2004 -0400, Jamal Hadi Salim wrote: >The question is not well worded. > >The real question should be whether the SET and or a GET should be >using the same construct. >As a reminder, we have the follwoing construct: > >Type{=config}->FE->LFBClass->LFBinstance->operation= {SET}-->data here > >1) What we have in the currently discussed BNF is GET resides in the >spot where SET is. > >2) What we had before is a special type called query just for getting >things. > >** A side effect of batching multiple operations is ability to do a GET >and a SET (or an add and a delete etc). > >The comparison is between #1 and #2 above. > >Should we keep the GET as in #1 or keep the query type in #2? > >cheers, >jamal >On Fri, 2004-10-15 at 18:55, Khosravi, Hormuzd M wrote: > > No, I don't that's why I asked...since this was coming from Joel's > > proposal. > > I didn't get a good reason from his email either, but it seems like he > > would like to have it supported by the protocol anyway. > > > > Joel, do you have any examples for us ? > > > > > > Thanks > > Hormuzd > > > > -----Original Message----- > > From: Yang, Lily L > > Sent: Friday, October 15, 2004 3:52 PM > > To: Khosravi, Hormuzd M; 'Joel M. Halpern'; 'zsolt@petri-meat.com'; > > 'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M; 'ram.gopal@nokia.com' > > Cc: 'forces-protocol@ietf.org' > > Subject: RE: GET/SET in one msg ? > > > > I don't understand why you would want to do such a thing. Do you have > > any example in mind? > > > > > -----Original Message----- > > > From: Khosravi, Hormuzd M > > > Sent: Friday, October 15, 2004 2:04 PM > > > To: Joel M. Halpern; zsolt@petri-meat.com; Steven Blake; > > > Yang, Lily L; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com > > > Cc: forces-protocol@ietf.org > > > Subject: GET/SET in one msg ? > > > > > > Hi Folks, > > > > > > We (protocol team) are finalizing some of the msgs and one of > > > the issues which is being discussed is whether GET/SET > > > operation need to be combined in a single msg...(currently we > > > have them as separate msgs). I have never seen this being > > > done in practice i.e. command bundling of GET/SET, but if you > > > guys have some experience/opinions on this, pls do let us know. > > > > > > > > > Thanks a lot, > > > Hormuzd > > > > > > > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 20:25:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08904 for ; Fri, 15 Oct 2004 20:25:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcZZ-0001Y6-Hl for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 20:37:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcME-00081W-Be; Fri, 15 Oct 2004 20:23:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcIq-0006fB-5a for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 20:20:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08337 for ; Fri, 15 Oct 2004 20:20:06 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcUF-0001QX-WF for forces-protocol@ietf.org; Fri, 15 Oct 2004 20:31:59 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9G0NA6E032105; Sat, 16 Oct 2004 00:23:10 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9G0MwWE029172; Sat, 16 Oct 2004 00:22:58 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101517192719533 ; Fri, 15 Oct 2004 17:19:27 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 17:19:11 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 15 Oct 2004 17:19:09 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02E98513@orsmsx408> Thread-Topic: GET/SET in one msg ? Thread-Index: AcSzFNZJFeq04pwhQve9pRzkcCikbQAAHUaA From: "Khosravi, Hormuzd M" To: "Joel M. Halpern" , "Yang, Lily L" , , "Steven Blake" , "Alan DeKok" , "Deleganes, Ellen M" , X-OriginalArrivalTime: 16 Oct 2004 00:19:11.0018 (UTC) FILETIME=[C26328A0:01C4B315] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: GET/SET in one msg ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable It makes sense to combine ADD, DEL, UPDATE, etc...we already have this in our Config msg. The question is whether you would need a GET operation as part of this message as well, or it would work better as a separate message...for e.g., Query msg as we have in the protocol. Jamal provided a good clarification on this. Thanks Hormuzd -----Original Message----- From: Joel M. Halpern [mailto:jhalpern@MEGISTO.com]=20 Sent: Friday, October 15, 2004 5:12 PM To: Khosravi, Hormuzd M; Yang, Lily L; zsolt@petri-meat.com; Steven Blake; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com Cc: forces-protocol@ietf.org Subject: RE: GET/SET in one msg ? If we are sure that the only two operations we will ever need are GET and=20 SET, then we could probably simply declare that a message was either a GET=20 message or a SET message. However, we have had suggestions of INSERT operations, and I would hate to=20 design the protocol so that we could not add other operations later. And=20 some combinations of operations may make sense together (insert item=20 A. Add reference to A in item B. Delete obsoleted item C.) Thus, I tend to think that it makes sense to structure the protocol so that=20 a single emssage can carry multiple operations. At the same time, as I said earlier, I would either prohibit or warn=20 against combining update and read operations in the same request. Requests=20 to read, for example to confirm the results of an update, ought to be sent=20 separately so that the FE does not need to worry about the order of=20 application. Yours, Joel At 03:55 PM 10/15/2004 -0700, Khosravi, Hormuzd M wrote: >No, I don't that's why I asked...since this was coming from Joel's >proposal. >I didn't get a good reason from his email either, but it seems like he >would like to have it supported by the protocol anyway. > >Joel, do you have any examples for us ? > > >Thanks >Hormuzd > >-----Original Message----- >From: Yang, Lily L >Sent: Friday, October 15, 2004 3:52 PM >To: Khosravi, Hormuzd M; 'Joel M. Halpern'; 'zsolt@petri-meat.com'; >'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M; 'ram.gopal@nokia.com' >Cc: 'forces-protocol@ietf.org' >Subject: RE: GET/SET in one msg ? > >I don't understand why you would want to do such a thing. Do you have >any example in mind? > > > -----Original Message----- > > From: Khosravi, Hormuzd M > > Sent: Friday, October 15, 2004 2:04 PM > > To: Joel M. Halpern; zsolt@petri-meat.com; Steven Blake; > > Yang, Lily L; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com > > Cc: forces-protocol@ietf.org > > Subject: GET/SET in one msg ? > > > > Hi Folks, > > > > We (protocol team) are finalizing some of the msgs and one of > > the issues which is being discussed is whether GET/SET > > operation need to be combined in a single msg...(currently we > > have them as separate msgs). I have never seen this being > > done in practice i.e. command bundling of GET/SET, but if you > > guys have some experience/opinions on this, pls do let us know. > > > > > > Thanks a lot, > > Hormuzd > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 20:25:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08936 for ; Fri, 15 Oct 2004 20:25:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcZe-0001YJ-14 for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 20:37:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcMG-00082r-MC; Fri, 15 Oct 2004 20:23:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcK1-0006pN-E2 for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 20:21:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08489 for ; Fri, 15 Oct 2004 20:21:19 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcVU-0001SM-MU for forces-protocol@ietf.org; Fri, 15 Oct 2004 20:33:12 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101517235624:29772 ; Fri, 15 Oct 2004 17:23:56 -0700 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: "Joel M. Halpern" In-Reply-To: <5.1.0.14.0.20041015201212.02416bf0@mail.megisto.com> References: <468F3FDA28AA87429AD807992E22D07E02E60C6D@orsmsx408> <468F3FDA28AA87429AD807992E22D07E02E60C6D@orsmsx408> <5.1.0.14.0.20041015201212.02416bf0@mail.megisto.com> Organization: ZNYX Networks Message-Id: <1097886077.1043.15.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Oct 2004 20:21:17 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/15/2004 05:23:56 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/15/2004 05:23:57 PM, Serialize complete at 10/15/2004 05:23:57 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , Steve Blake , ram.gopal@nokia.com, forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit On Fri, 2004-10-15 at 20:12, Joel M. Halpern wrote: > I personally prefer that the message type be independent of the operation > type. Thus if we create conditional gets, or test and set, or any other > interesting operations we don't have to discuss whether ti goes in the GET > message or the SET message. Can you be more specific in the case of the config/set vs query examples? Thats whats on our immediate plate cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 20:26:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09036 for ; Fri, 15 Oct 2004 20:26:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcaW-0001Zt-Ol for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 20:38:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcOQ-0000fO-4R; Fri, 15 Oct 2004 20:25:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcN1-0008Q0-B7 for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 20:24:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08760 for ; Fri, 15 Oct 2004 20:24:25 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcYT-0001VS-Ea for forces-protocol@ietf.org; Fri, 15 Oct 2004 20:36:18 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9G0Ra6E001132; Sat, 16 Oct 2004 00:27:36 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9G0RHWM031162; Sat, 16 Oct 2004 00:27:26 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101517235420032 ; Fri, 15 Oct 2004 17:23:54 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 17:23:54 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 15 Oct 2004 17:23:53 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02E98520@orsmsx408> Thread-Topic: sync with BNF as discussed with model folks Thread-Index: AcSzFOUJA6Wrw30uSRe44Hy3on88zQAAQpGQ From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 16 Oct 2004 00:23:54.0514 (UTC) FILETIME=[6B5D3720:01C4B316] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: sync with BNF as discussed with model folks X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Jamal,=20 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > Regarding HB msgs, these have been discussed a lot last time. I don't > think these are affect by FE Object, etc...but this is a minor one, I > think. I think its minor for deadline purpsoses. However, as is noted everything MUST target an LFB. This message also applies. [HK] I am not sure I understand exactly what you mean by everything MUST target an LFB. All the messages are addressed to Ces and Fes...we decided to use the FE Object/LFB for representing FE info, and thus most of the content of messages can be represented as LFBs. What does targeting a LFB mean ?? We cant have HBs between Ces and Fes ? Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 20:37:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09876 for ; Fri, 15 Oct 2004 20:37:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcl7-0001os-A3 for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 20:49:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcYX-0003Xy-EA; Fri, 15 Oct 2004 20:36:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcUV-0002L2-2C for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 20:32:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09503 for ; Fri, 15 Oct 2004 20:32:09 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcfy-0001iJ-CV for forces-protocol@ietf.org; Fri, 15 Oct 2004 20:44:02 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101517344546:29786 ; Fri, 15 Oct 2004 17:34:45 -0700 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02E98520@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02E98520@orsmsx408> Organization: ZNYX Networks Message-Id: <1097886727.1049.20.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Oct 2004 20:32:07 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/15/2004 05:34:45 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/15/2004 05:34:47 PM, Serialize complete at 10/15/2004 05:34:47 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: sync with BNF as discussed with model folks X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit On Fri, 2004-10-15 at 20:23, Khosravi, Hormuzd M wrote: > Jamal, > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > Regarding HB msgs, these have been discussed a lot last time. I don't > > think these are affect by FE Object, etc...but this is a minor one, I > > think. > > I think its minor for deadline purpsoses. However, as is noted > everything MUST target an LFB. This message also applies. > > [HK] I am not sure I understand exactly what you mean by everything MUST > target an LFB. All the messages are addressed to Ces and Fes...we > decided to use the FE Object/LFB for representing FE info, and thus most > of the content of messages can be represented as LFBs. What does > targeting a LFB mean ?? We cant have HBs between Ces and Fes ? What i mean is some LFB needs to process that message. And i thought the FE object was a good target. In other words you cant just send a message to an entity called "FE" anymore. Does this make sense? cheers, jamal The message is now mainhdr LFBclass > Hormuzd > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 20:46:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10546 for ; Fri, 15 Oct 2004 20:46:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcts-00022K-Mr for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 20:58:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIch2-0005pu-Me; Fri, 15 Oct 2004 20:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIcd0-0004bf-3W for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 20:40:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10127 for ; Fri, 15 Oct 2004 20:40:56 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIcoR-0001tQ-Vf for forces-protocol@ietf.org; Fri, 15 Oct 2004 20:52:49 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101517433116:29794 ; Fri, 15 Oct 2004 17:43:31 -0700 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: "Joel M. Halpern" In-Reply-To: <5.1.0.14.0.20041015200825.02301940@mail.megisto.com> References: <5.1.0.14.0.20041015200825.02301940@mail.megisto.com> Organization: ZNYX Networks Message-Id: <1097887251.1042.28.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Oct 2004 20:40:52 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/15/2004 05:43:31 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/15/2004 05:43:32 PM, Serialize complete at 10/15/2004 05:43:32 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , Steve Blake , ram.gopal@nokia.com, forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Joel, We are sort of in a rush here to beat a deadline ;-> Give it to us in boolean logic please ;-> Did i read correctly that since we may have multiple operations (we have been discussing event un/subscribe as something that would appear as an operation for example) then the way to go forward is have GET as an operation? cheers, jamal On Fri, 2004-10-15 at 20:11, Joel M. Halpern wrote: > If we are sure that the only two operations we will ever need are GET and > SET, then we could probably simply declare that a message was either a GET > message or a SET message. > However, we have had suggestions of INSERT operations, and I would hate to > design the protocol so that we could not add other operations later. And > some combinations of operations may make sense together (insert item > A. Add reference to A in item B. Delete obsoleted item C.) > Thus, I tend to think that it makes sense to structure the protocol so that > a single emssage can carry multiple operations. > At the same time, as I said earlier, I would either prohibit or warn > against combining update and read operations in the same request. Requests > to read, for example to confirm the results of an update, ought to be sent > separately so that the FE does not need to worry about the order of > application. > > Yours, > Joel > > At 03:55 PM 10/15/2004 -0700, Khosravi, Hormuzd M wrote: > >No, I don't that's why I asked...since this was coming from Joel's > >proposal. > >I didn't get a good reason from his email either, but it seems like he > >would like to have it supported by the protocol anyway. > > > >Joel, do you have any examples for us ? > > > > > >Thanks > >Hormuzd > > > >-----Original Message----- > >From: Yang, Lily L > >Sent: Friday, October 15, 2004 3:52 PM > >To: Khosravi, Hormuzd M; 'Joel M. Halpern'; 'zsolt@petri-meat.com'; > >'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M; 'ram.gopal@nokia.com' > >Cc: 'forces-protocol@ietf.org' > >Subject: RE: GET/SET in one msg ? > > > >I don't understand why you would want to do such a thing. Do you have > >any example in mind? > > > > > -----Original Message----- > > > From: Khosravi, Hormuzd M > > > Sent: Friday, October 15, 2004 2:04 PM > > > To: Joel M. Halpern; zsolt@petri-meat.com; Steven Blake; > > > Yang, Lily L; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com > > > Cc: forces-protocol@ietf.org > > > Subject: GET/SET in one msg ? > > > > > > Hi Folks, > > > > > > We (protocol team) are finalizing some of the msgs and one of > > > the issues which is being discussed is whether GET/SET > > > operation need to be combined in a single msg...(currently we > > > have them as separate msgs). I have never seen this being > > > done in practice i.e. command bundling of GET/SET, but if you > > > guys have some experience/opinions on this, pls do let us know. > > > > > > > > > Thanks a lot, > > > Hormuzd > > > > > > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 21:36:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13813 for ; Fri, 15 Oct 2004 21:36:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIdfr-0002vi-A9 for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 21:47:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIdQF-0001Ea-5Y; Fri, 15 Oct 2004 21:31:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIdG1-0007Uj-IR for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 21:21:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12856 for ; Fri, 15 Oct 2004 21:21:15 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIdRI-0002fh-3p for forces-protocol@ietf.org; Fri, 15 Oct 2004 21:33:09 -0400 Received: from JLaptop.megisto.com ([192.168.20.227]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Oct 2004 21:20:44 -0400 Message-Id: <5.1.0.14.0.20041015211901.02301680@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Oct 2004 21:20:07 -0400 To: hadi@znyx.com From: "Joel M. Halpern" Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? In-Reply-To: <1097887251.1042.28.camel@jzny.localdomain> References: <5.1.0.14.0.20041015200825.02301940@mail.megisto.com> <5.1.0.14.0.20041015200825.02301940@mail.megisto.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 16 Oct 2004 01:20:44.0851 (UTC) FILETIME=[5C155830:01C4B31E] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , Steve Blake , ram.gopal@nokia.com, forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e That would be my suggestion. To be specific, I would not have a Query and a Modify message, but rather would have an Operation message which can carry whatever operations we decide we need. We may make specific rules that say "for sanity, never combine X and Y". I believe this will keep the protocol simpler. Yours, Joel At 08:40 PM 10/15/2004 -0400, Jamal Hadi Salim wrote: >Joel, >We are sort of in a rush here to beat a deadline ;-> Give it to us in >boolean logic please ;-> > >Did i read correctly that since we may have multiple operations (we have >been discussing event un/subscribe as something that would appear as an >operation for example) then the way to go forward is have GET as an >operation? > >cheers, >jamal > >On Fri, 2004-10-15 at 20:11, Joel M. Halpern wrote: > > If we are sure that the only two operations we will ever need are GET and > > SET, then we could probably simply declare that a message was either a GET > > message or a SET message. > > However, we have had suggestions of INSERT operations, and I would hate to > > design the protocol so that we could not add other operations later. And > > some combinations of operations may make sense together (insert item > > A. Add reference to A in item B. Delete obsoleted item C.) > > Thus, I tend to think that it makes sense to structure the protocol so > that > > a single emssage can carry multiple operations. > > At the same time, as I said earlier, I would either prohibit or warn > > against combining update and read operations in the same > request. Requests > > to read, for example to confirm the results of an update, ought to be sent > > separately so that the FE does not need to worry about the order of > > application. > > > > Yours, > > Joel > > > > At 03:55 PM 10/15/2004 -0700, Khosravi, Hormuzd M wrote: > > >No, I don't that's why I asked...since this was coming from Joel's > > >proposal. > > >I didn't get a good reason from his email either, but it seems like he > > >would like to have it supported by the protocol anyway. > > > > > >Joel, do you have any examples for us ? > > > > > > > > >Thanks > > >Hormuzd > > > > > >-----Original Message----- > > >From: Yang, Lily L > > >Sent: Friday, October 15, 2004 3:52 PM > > >To: Khosravi, Hormuzd M; 'Joel M. Halpern'; 'zsolt@petri-meat.com'; > > >'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M; 'ram.gopal@nokia.com' > > >Cc: 'forces-protocol@ietf.org' > > >Subject: RE: GET/SET in one msg ? > > > > > >I don't understand why you would want to do such a thing. Do you have > > >any example in mind? > > > > > > > -----Original Message----- > > > > From: Khosravi, Hormuzd M > > > > Sent: Friday, October 15, 2004 2:04 PM > > > > To: Joel M. Halpern; zsolt@petri-meat.com; Steven Blake; > > > > Yang, Lily L; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com > > > > Cc: forces-protocol@ietf.org > > > > Subject: GET/SET in one msg ? > > > > > > > > Hi Folks, > > > > > > > > We (protocol team) are finalizing some of the msgs and one of > > > > the issues which is being discussed is whether GET/SET > > > > operation need to be combined in a single msg...(currently we > > > > have them as separate msgs). I have never seen this being > > > > done in practice i.e. command bundling of GET/SET, but if you > > > > guys have some experience/opinions on this, pls do let us know. > > > > > > > > > > > > Thanks a lot, > > > > Hormuzd > > > > > > > > > > > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 21:36:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13893 for ; Fri, 15 Oct 2004 21:36:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIdg7-0002w8-99 for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 21:48:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIdQH-0001GC-Tw; Fri, 15 Oct 2004 21:31:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIdMD-0008HV-Og for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 21:27:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13467 for ; Fri, 15 Oct 2004 21:27:39 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIdXh-0002nD-3N for forces-protocol@ietf.org; Fri, 15 Oct 2004 21:39:33 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9G1QWSU022112; Sat, 16 Oct 2004 01:26:33 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9G1UOWI022504; Sat, 16 Oct 2004 01:30:29 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101518265808190 ; Fri, 15 Oct 2004 18:26:58 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 18:26:57 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? Date: Fri, 15 Oct 2004 18:26:56 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> Thread-Topic: [Forces-protocol] RE: GET/SET in one msg ? Thread-Index: AcSzHmb7y9mQPMUgQ4O42+ItHguTJwAACqDQ From: "Khosravi, Hormuzd M" To: "Joel M. Halpern" , X-OriginalArrivalTime: 16 Oct 2004 01:26:57.0970 (UTC) FILETIME=[3A7AC920:01C4B31F] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: zsolt@petri-meat.com, ram.gopal@nokia.com, Steve Blake , forces-protocol@ietf.org, Alan DeKok , "Deleganes, Ellen M" , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable Does anyone else have an opinion on this, especially if it is different from what Joel suggested ? Pls do let us know asap.=20 I am fine with this, just want to make sure there are no contradicting opinions in the Model team. Thanks Hormuzd=20 P.s. BTW, I don't think I still got a real example on how this would be useful. -----Original Message----- From: Joel M. Halpern [mailto:jhalpern@MEGISTO.com]=20 Sent: Friday, October 15, 2004 6:20 PM To: hadi@znyx.com Cc: Khosravi, Hormuzd M; Yang, Lily L; zsolt@petri-meat.com; Steve Blake; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com; forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? That would be my suggestion. To be specific, I would not have a Query and a Modify message, but rather=20 would have an Operation message which can carry whatever operations we=20 decide we need. We may make specific rules that say "for sanity, never=20 combine X and Y". I believe this will keep the protocol simpler. Yours, Joel At 08:40 PM 10/15/2004 -0400, Jamal Hadi Salim wrote: >Joel, >We are sort of in a rush here to beat a deadline ;-> Give it to us in >boolean logic please ;-> > >Did i read correctly that since we may have multiple operations (we have >been discussing event un/subscribe as something that would appear as an >operation for example) then the way to go forward is have GET as an >operation? > >cheers, >jamal > >On Fri, 2004-10-15 at 20:11, Joel M. Halpern wrote: > > If we are sure that the only two operations we will ever need are GET and > > SET, then we could probably simply declare that a message was either a GET > > message or a SET message. > > However, we have had suggestions of INSERT operations, and I would hate to > > design the protocol so that we could not add other operations later. And > > some combinations of operations may make sense together (insert item > > A. Add reference to A in item B. Delete obsoleted item C.) > > Thus, I tend to think that it makes sense to structure the protocol so=20 > that > > a single emssage can carry multiple operations. > > At the same time, as I said earlier, I would either prohibit or warn > > against combining update and read operations in the same=20 > request. Requests > > to read, for example to confirm the results of an update, ought to be sent > > separately so that the FE does not need to worry about the order of > > application. > > > > Yours, > > Joel > > > > At 03:55 PM 10/15/2004 -0700, Khosravi, Hormuzd M wrote: > > >No, I don't that's why I asked...since this was coming from Joel's > > >proposal. > > >I didn't get a good reason from his email either, but it seems like he > > >would like to have it supported by the protocol anyway. > > > > > >Joel, do you have any examples for us ? > > > > > > > > >Thanks > > >Hormuzd > > > > > >-----Original Message----- > > >From: Yang, Lily L > > >Sent: Friday, October 15, 2004 3:52 PM > > >To: Khosravi, Hormuzd M; 'Joel M. Halpern'; 'zsolt@petri-meat.com'; > > >'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M; 'ram.gopal@nokia.com' > > >Cc: 'forces-protocol@ietf.org' > > >Subject: RE: GET/SET in one msg ? > > > > > >I don't understand why you would want to do such a thing. Do you have > > >any example in mind? > > > > > > > -----Original Message----- > > > > From: Khosravi, Hormuzd M > > > > Sent: Friday, October 15, 2004 2:04 PM > > > > To: Joel M. Halpern; zsolt@petri-meat.com; Steven Blake; > > > > Yang, Lily L; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com > > > > Cc: forces-protocol@ietf.org > > > > Subject: GET/SET in one msg ? > > > > > > > > Hi Folks, > > > > > > > > We (protocol team) are finalizing some of the msgs and one of > > > > the issues which is being discussed is whether GET/SET > > > > operation need to be combined in a single msg...(currently we > > > > have them as separate msgs). I have never seen this being > > > > done in practice i.e. command bundling of GET/SET, but if you > > > > guys have some experience/opinions on this, pls do let us know. > > > > > > > > > > > > Thanks a lot, > > > > Hormuzd > > > > > > > > > > > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 15 23:45:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03946 for ; Fri, 15 Oct 2004 23:45:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIfgz-0005CP-E6 for forces-protocol-web-archive@ietf.org; Fri, 15 Oct 2004 23:57:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIfUY-0004Fq-P6; Fri, 15 Oct 2004 23:44:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIfPm-0002wl-6k for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 23:39:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03508 for ; Fri, 15 Oct 2004 23:39:26 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIfbF-00056P-Tx for forces-protocol@ietf.org; Fri, 15 Oct 2004 23:51:22 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9G3dJOH017849; Sat, 16 Oct 2004 03:39:19 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9G3g7WI014016; Sat, 16 Oct 2004 03:42:18 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101520384619823 ; Fri, 15 Oct 2004 20:38:46 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 20:38:46 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? Date: Fri, 15 Oct 2004 20:39:35 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02E985D8@orsmsx408> Thread-Topic: [Forces-protocol] RE: GET/SET in one msg ? Thread-Index: AcSzHmb7y9mQPMUgQ4O42+ItHguTJwAACqDQAASWI0A= From: "Deleganes, Ellen M" To: "Khosravi, Hormuzd M" , "Joel M. Halpern" , X-OriginalArrivalTime: 16 Oct 2004 03:38:46.0871 (UTC) FILETIME=[A48D4E70:01C4B331] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Cc: zsolt@petri-meat.com, ram.gopal@nokia.com, forces-protocol@ietf.org, Steve Blake , Alan DeKok , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable The thing that is appealing about the proposal is not so much being able to combine operations as the notion of being able to define new ones without having to define new messages. I presume that the "rules" (e.g. never combine operations X and Y) are not something the protocol is expected to enforce. Otherwise, I think it would add unnecessary complication to the protocol processing.=20 It also sounded like Joel was suggesting that if operations happened to be combined in a single message, the order shown in the protocol does not imply the order in which the implementation has to execute them. Is that right? Regards, Ellen -----Original Message----- From: Khosravi, Hormuzd M=20 Sent: Friday, October 15, 2004 6:27 PM To: Joel M. Halpern; hadi@znyx.com Cc: Yang, Lily L; zsolt@petri-meat.com; Steve Blake; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com; forces-protocol@ietf.org Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? Does anyone else have an opinion on this, especially if it is different from what Joel suggested ? Pls do let us know asap.=20 I am fine with this, just want to make sure there are no contradicting opinions in the Model team. Thanks Hormuzd=20 P.s. BTW, I don't think I still got a real example on how this would be useful. -----Original Message----- From: Joel M. Halpern [mailto:jhalpern@MEGISTO.com]=20 Sent: Friday, October 15, 2004 6:20 PM To: hadi@znyx.com Cc: Khosravi, Hormuzd M; Yang, Lily L; zsolt@petri-meat.com; Steve Blake; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com; forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? That would be my suggestion. To be specific, I would not have a Query and a Modify message, but rather=20 would have an Operation message which can carry whatever operations we=20 decide we need. We may make specific rules that say "for sanity, never=20 combine X and Y". I believe this will keep the protocol simpler. Yours, Joel At 08:40 PM 10/15/2004 -0400, Jamal Hadi Salim wrote: >Joel, >We are sort of in a rush here to beat a deadline ;-> Give it to us in >boolean logic please ;-> > >Did i read correctly that since we may have multiple operations (we have >been discussing event un/subscribe as something that would appear as an >operation for example) then the way to go forward is have GET as an >operation? > >cheers, >jamal > >On Fri, 2004-10-15 at 20:11, Joel M. Halpern wrote: > > If we are sure that the only two operations we will ever need are GET and > > SET, then we could probably simply declare that a message was either a GET > > message or a SET message. > > However, we have had suggestions of INSERT operations, and I would hate to > > design the protocol so that we could not add other operations later. And > > some combinations of operations may make sense together (insert item > > A. Add reference to A in item B. Delete obsoleted item C.) > > Thus, I tend to think that it makes sense to structure the protocol so=20 > that > > a single emssage can carry multiple operations. > > At the same time, as I said earlier, I would either prohibit or warn > > against combining update and read operations in the same=20 > request. Requests > > to read, for example to confirm the results of an update, ought to be sent > > separately so that the FE does not need to worry about the order of > > application. > > > > Yours, > > Joel > > > > At 03:55 PM 10/15/2004 -0700, Khosravi, Hormuzd M wrote: > > >No, I don't that's why I asked...since this was coming from Joel's > > >proposal. > > >I didn't get a good reason from his email either, but it seems like he > > >would like to have it supported by the protocol anyway. > > > > > >Joel, do you have any examples for us ? > > > > > > > > >Thanks > > >Hormuzd > > > > > >-----Original Message----- > > >From: Yang, Lily L > > >Sent: Friday, October 15, 2004 3:52 PM > > >To: Khosravi, Hormuzd M; 'Joel M. Halpern'; 'zsolt@petri-meat.com'; > > >'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M; 'ram.gopal@nokia.com' > > >Cc: 'forces-protocol@ietf.org' > > >Subject: RE: GET/SET in one msg ? > > > > > >I don't understand why you would want to do such a thing. Do you have > > >any example in mind? > > > > > > > -----Original Message----- > > > > From: Khosravi, Hormuzd M > > > > Sent: Friday, October 15, 2004 2:04 PM > > > > To: Joel M. Halpern; zsolt@petri-meat.com; Steven Blake; > > > > Yang, Lily L; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com > > > > Cc: forces-protocol@ietf.org > > > > Subject: GET/SET in one msg ? > > > > > > > > Hi Folks, > > > > > > > > We (protocol team) are finalizing some of the msgs and one of > > > > the issues which is being discussed is whether GET/SET > > > > operation need to be combined in a single msg...(currently we > > > > have them as separate msgs). I have never seen this being > > > > done in practice i.e. command bundling of GET/SET, but if you > > > > guys have some experience/opinions on this, pls do let us know. > > > > > > > > > > > > Thanks a lot, > > > > Hormuzd > > > > > > > > > > > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 16 00:08:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04978 for ; Sat, 16 Oct 2004 00:08:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIg3L-0005dI-FS for forces-protocol-web-archive@ietf.org; Sat, 16 Oct 2004 00:20:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIfjs-0000Am-KN; Sat, 16 Oct 2004 00:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIfhK-0007bF-Eg for forces-protocol@megatron.ietf.org; Fri, 15 Oct 2004 23:57:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04439 for ; Fri, 15 Oct 2004 23:57:34 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIfse-0005UI-Bs for forces-protocol@ietf.org; Sat, 16 Oct 2004 00:09:30 -0400 Received: from JLaptop.megisto.com ([192.168.20.227]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 15 Oct 2004 23:57:08 -0400 Message-Id: <5.1.0.14.0.20041015235333.023f5850@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 15 Oct 2004 23:56:30 -0400 To: "Deleganes, Ellen M" , "Khosravi, Hormuzd M" , From: "Joel M. Halpern" Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02E985D8@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 16 Oct 2004 03:57:08.0637 (UTC) FILETIME=[354174D0:01C4B334] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: zsolt@petri-meat.com, ram.gopal@nokia.com, forces-protocol@ietf.org, Steve Blake , Alan DeKok , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 I agree that rules about protocol combination are NOT for the protocol to enforce. We would write them as ~the sender should not do X and Y, and receiver behavior if it receives such is indeterminant~. I would agree that there should be no requirement on the order of application of operations in a message, although there probably is an atomicity requirement of the form ~either all of them will be done, or none of them will be done~. Another way of putting this is that the protocol structures themselves should not mandate the presence of an order requirement, even if we as a working group were to decide that we wanted such ordering to be enforced. Yours, Joel At 08:39 PM 10/15/2004 -0700, Deleganes, Ellen M wrote: >The thing that is appealing about the proposal is not so much being able >to combine operations as the notion of being able to define new ones >without having to define new messages. > >I presume that the "rules" (e.g. never combine operations X and Y) are >not something the protocol is expected to enforce. Otherwise, I think it >would add unnecessary complication to the protocol processing. > >It also sounded like Joel was suggesting that if operations happened to >be combined in a single message, the order shown in the protocol does >not imply the order in which the implementation has to execute them. Is >that right? > >Regards, >Ellen > > >-----Original Message----- >From: Khosravi, Hormuzd M >Sent: Friday, October 15, 2004 6:27 PM >To: Joel M. Halpern; hadi@znyx.com >Cc: Yang, Lily L; zsolt@petri-meat.com; Steve Blake; Alan DeKok; >Deleganes, Ellen M; ram.gopal@nokia.com; forces-protocol@ietf.org >Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? > > >Does anyone else have an opinion on this, especially if it is different >from what Joel suggested ? >Pls do let us know asap. > >I am fine with this, just want to make sure there are no contradicting >opinions in the Model team. > > >Thanks >Hormuzd >P.s. BTW, I don't think I still got a real example on how this would be >useful. > > >-----Original Message----- >From: Joel M. Halpern [mailto:jhalpern@MEGISTO.com] >Sent: Friday, October 15, 2004 6:20 PM >To: hadi@znyx.com >Cc: Khosravi, Hormuzd M; Yang, Lily L; zsolt@petri-meat.com; Steve >Blake; Alan DeKok; Deleganes, Ellen M; ram.gopal@nokia.com; >forces-protocol@ietf.org >Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? > >That would be my suggestion. > >To be specific, I would not have a Query and a Modify message, but >rather >would have an Operation message which can carry whatever operations we >decide we need. We may make specific rules that say "for sanity, never >combine X and Y". > >I believe this will keep the protocol simpler. > >Yours, >Joel > >At 08:40 PM 10/15/2004 -0400, Jamal Hadi Salim wrote: > >Joel, > >We are sort of in a rush here to beat a deadline ;-> Give it to us in > >boolean logic please ;-> > > > >Did i read correctly that since we may have multiple operations (we >have > >been discussing event un/subscribe as something that would appear as an > >operation for example) then the way to go forward is have GET as an > >operation? > > > >cheers, > >jamal > > > >On Fri, 2004-10-15 at 20:11, Joel M. Halpern wrote: > > > If we are sure that the only two operations we will ever need are >GET and > > > SET, then we could probably simply declare that a message was either >a GET > > > message or a SET message. > > > However, we have had suggestions of INSERT operations, and I would >hate to > > > design the protocol so that we could not add other operations later. >And > > > some combinations of operations may make sense together (insert item > > > A. Add reference to A in item B. Delete obsoleted item C.) > > > Thus, I tend to think that it makes sense to structure the protocol >so > > that > > > a single emssage can carry multiple operations. > > > At the same time, as I said earlier, I would either prohibit or warn > > > against combining update and read operations in the same > > request. Requests > > > to read, for example to confirm the results of an update, ought to >be sent > > > separately so that the FE does not need to worry about the order of > > > application. > > > > > > Yours, > > > Joel > > > > > > At 03:55 PM 10/15/2004 -0700, Khosravi, Hormuzd M wrote: > > > >No, I don't that's why I asked...since this was coming from Joel's > > > >proposal. > > > >I didn't get a good reason from his email either, but it seems like >he > > > >would like to have it supported by the protocol anyway. > > > > > > > >Joel, do you have any examples for us ? > > > > > > > > > > > >Thanks > > > >Hormuzd > > > > > > > >-----Original Message----- > > > >From: Yang, Lily L > > > >Sent: Friday, October 15, 2004 3:52 PM > > > >To: Khosravi, Hormuzd M; 'Joel M. Halpern'; 'zsolt@petri-meat.com'; > > > >'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M; >'ram.gopal@nokia.com' > > > >Cc: 'forces-protocol@ietf.org' > > > >Subject: RE: GET/SET in one msg ? > > > > > > > >I don't understand why you would want to do such a thing. Do you >have > > > >any example in mind? > > > > > > > > > -----Original Message----- > > > > > From: Khosravi, Hormuzd M > > > > > Sent: Friday, October 15, 2004 2:04 PM > > > > > To: Joel M. Halpern; zsolt@petri-meat.com; Steven Blake; > > > > > Yang, Lily L; Alan DeKok; Deleganes, Ellen M; >ram.gopal@nokia.com > > > > > Cc: forces-protocol@ietf.org > > > > > Subject: GET/SET in one msg ? > > > > > > > > > > Hi Folks, > > > > > > > > > > We (protocol team) are finalizing some of the msgs and one of > > > > > the issues which is being discussed is whether GET/SET > > > > > operation need to be combined in a single msg...(currently we > > > > > have them as separate msgs). I have never seen this being > > > > > done in practice i.e. command bundling of GET/SET, but if you > > > > > guys have some experience/opinions on this, pls do let us know. > > > > > > > > > > > > > > > Thanks a lot, > > > > > Hormuzd > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Forces-protocol mailing list > > > Forces-protocol@ietf.org > > > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 16 00:30:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06479 for ; Sat, 16 Oct 2004 00:30:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIgOp-00064G-FX for forces-protocol-web-archive@ietf.org; Sat, 16 Oct 2004 00:42:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIg99-0000AS-UN; Sat, 16 Oct 2004 00:26:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIg7f-0007sq-2B for forces-protocol@megatron.ietf.org; Sat, 16 Oct 2004 00:24:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06133 for ; Sat, 16 Oct 2004 00:24:47 -0400 (EDT) Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIgJ9-0005x2-8K for forces-protocol@ietf.org; Sat, 16 Oct 2004 00:36:44 -0400 Received: from cpe-024-211-225-015.nc.rr.com ([24.211.225.15]) by server26.totalchoicehosting.com with esmtp (Exim 4.43) id 1CIg6y-0004KC-7l; Sat, 16 Oct 2004 00:24:08 -0400 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? From: Steven Blake To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> Content-Type: text/plain Message-Id: <1097900642.19064.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Sat, 16 Oct 2004 00:24:03 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, zsolt@petri-meat.com, "Yang, Lily L" , "Joel M. Halpern" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit On Fri, 2004-10-15 at 21:26, Khosravi, Hormuzd M wrote: > Does anyone else have an opinion on this, especially if it is different > from what Joel suggested ? > Pls do let us know asap. > > I am fine with this, just want to make sure there are no contradicting > opinions in the Model team. My problem about allowing a config command in the same PL-message as a query command (and I think Zsolt agrees with me), is that it complicates handling of any responses. I believe that, for any PL message with config commands, all of the possible exception responses can fit into a single PL message, and therefore we can correlate at the PL layer. However, it could be typical that a small query command message could result in several PL messages being returned (e.g., GET an entire table). For simplicity, I would like to see PL messages typed as either CONFIG-REQUEST, CONFIG-RESPONSE, QUERY-REQUEST, QUERY-RESPONSE, ASYNC-EVENT, ... Regards, // Steve http://www.petri-meat.com/slblake/ _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 16 03:37:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29600 for ; Sat, 16 Oct 2004 03:37:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIjJO-0000NM-L3 for forces-protocol-web-archive@ietf.org; Sat, 16 Oct 2004 03:49:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIj74-0006x0-Qs; Sat, 16 Oct 2004 03:36:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIj5k-0006YQ-T5 for forces-protocol@megatron.ietf.org; Sat, 16 Oct 2004 03:35:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29507 for ; Sat, 16 Oct 2004 03:35:01 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIjHF-0000KS-SX for forces-protocol@ietf.org; Sat, 16 Oct 2004 03:46:59 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9G7YwJB029938; Sat, 16 Oct 2004 07:34:58 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9G7b1qw012192; Sat, 16 Oct 2004 07:37:58 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101600342609281 ; Sat, 16 Oct 2004 00:34:26 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 16 Oct 2004 00:34:26 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? Date: Sat, 16 Oct 2004 00:33:46 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791E2@orsmsx408> Thread-Topic: [Forces-protocol] RE: GET/SET in one msg ? Thread-Index: AcSzHmb7y9mQPMUgQ4O42+ItHguTJwAACqDQAASWI0AACAk3IA== From: "Khosravi, Hormuzd M" To: "Deleganes, Ellen M" , "Joel M. Halpern" , X-OriginalArrivalTime: 16 Oct 2004 07:34:26.0490 (UTC) FILETIME=[906BF1A0:01C4B352] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: zsolt@petri-meat.com, ram.gopal@nokia.com, forces-protocol@ietf.org, Steve Blake , Alan DeKok , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Sure Ellen, i agree with that general notion as well...my question was more specific...to find out if there is a good rationale or example to combine SET like operations (SET, DEL, etc) with GET operation. I have implemented this both ways only to find that even when I could combine Set/Get in a single message, we always used them in separate msgs. So having them as separate msgs just seems more practical and a side benefit of that is it makes the parsing a little bit faster...not a whole lot I admit. My 2 cents, Hormuzd =20 -----Original Message----- From: Deleganes, Ellen M=20 The thing that is appealing about the proposal is not so much being able to combine operations as the notion of being able to define new ones without having to define new messages. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 16 07:58:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15352 for ; Sat, 16 Oct 2004 07:58:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CInNw-00058G-NW for forces-protocol-web-archive@ietf.org; Sat, 16 Oct 2004 08:10:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CInBM-0004wd-Be; Sat, 16 Oct 2004 07:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CInAW-0004lQ-P0 for forces-protocol@megatron.ietf.org; Sat, 16 Oct 2004 07:56:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15298 for ; Sat, 16 Oct 2004 07:56:15 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CInM6-000569-44 for forces-protocol@ietf.org; Sat, 16 Oct 2004 08:08:14 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101604584988:30167 ; Sat, 16 Oct 2004 04:58:49 -0700 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: Steve Blake In-Reply-To: <1097900642.19064.13.camel@localhost.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> <1097900642.19064.13.camel@localhost.localdomain> Organization: ZNYX Networks Message-Id: <1097927770.1043.35.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Oct 2004 07:56:10 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/16/2004 04:58:50 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/16/2004 04:58:52 AM, Serialize complete at 10/16/2004 04:58:52 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , zsolt@petri-meat.com, "Yang, Lily L" , "Joel M. Halpern" , ram.gopal@nokia.com, forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Sat, 2004-10-16 at 00:24, Steven Blake wrote: > My problem about allowing a config command in the same PL-message as a > query command (and I think Zsolt agrees with me), is that it complicates > handling of any responses. I believe that, for any PL message with > config commands, all of the possible exception responses can fit into > a single PL message, and therefore we can correlate at the PL layer. > However, it could be typical that a small query command message could > result in several PL messages being returned (e.g., GET an entire > table). > Sounds like consensus is to put a note in the draft that such a case may be hazardous and to be avoided. > For simplicity, I would like to see PL messages typed as either > CONFIG-REQUEST, CONFIG-RESPONSE, QUERY-REQUEST, QUERY-RESPONSE, > ASYNC-EVENT, ... > Ok, you still have a QUERY-REQUEST, QUERY-RESPONSE there - which is core to this discussion; an alternative to that is a CONFIG-REQUEST with operation = GET as well as CONFIG-RESPONSE with operation = GET. So far theres a leaning towards CONFIG-*; if you disagree please explain. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 16 11:02:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25910 for ; Sat, 16 Oct 2004 11:02:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIqFz-000844-Rd for forces-protocol-web-archive@ietf.org; Sat, 16 Oct 2004 11:14:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIq3b-0005Py-QP; Sat, 16 Oct 2004 11:01:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIq2g-0005F4-Uo for forces-protocol@megatron.ietf.org; Sat, 16 Oct 2004 11:00:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25777 for ; Sat, 16 Oct 2004 11:00:20 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIqEH-00082R-Qb for forces-protocol@ietf.org; Sat, 16 Oct 2004 11:12:22 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101608025258:30323 ; Sat, 16 Oct 2004 08:02:52 -0700 Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model folks From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <1097886727.1049.20.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02E98520@orsmsx408> <1097886727.1049.20.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1097938814.1042.45.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Oct 2004 11:00:15 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/16/2004 08:02:53 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/16/2004 08:02:58 AM, Serialize complete at 10/16/2004 08:02:58 AM Content-Type: multipart/mixed; boundary="=-u6s5FRJaAabSMUy+OP+L" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c --=-u6s5FRJaAabSMUy+OP+L Content-Type: text/plain Content-Transfer-Encoding: 7bit The question below is still outstanding. I have updated discussion so far with minor changes. Attached. cheers, jamal On Fri, 2004-10-15 at 20:32, Jamal Hadi Salim wrote: > On Fri, 2004-10-15 at 20:23, Khosravi, Hormuzd M wrote: > > Jamal, > > > > -----Original Message----- > > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > > > Regarding HB msgs, these have been discussed a lot last time. I don't > > > think these are affect by FE Object, etc...but this is a minor one, I > > > think. > > > > I think its minor for deadline purpsoses. However, as is noted > > everything MUST target an LFB. This message also applies. > > > > [HK] I am not sure I understand exactly what you mean by everything MUST > > target an LFB. All the messages are addressed to Ces and Fes...we > > decided to use the FE Object/LFB for representing FE info, and thus most > > of the content of messages can be represented as LFBs. What does > > targeting a LFB mean ?? We cant have HBs between Ces and Fes ? > > What i mean is some LFB needs to process that message. And i thought the > FE object was a good target. > In other words you cant just send a message to an entity called "FE" > anymore. > Does this make sense? > > cheers, > jamal > > The message is now > mainhdr LFBclass > > Hormuzd > > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol --=-u6s5FRJaAabSMUy+OP+L Content-Disposition: attachment; filename=potential-protocol-changes.txt Content-Type: text/plain; name=potential-protocol-changes.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Assumptions: ------------ a) Start by assuming BNF as discussed with model team (posted earlier). b) When no value is added by BNF discussed restore old scheme and fix associated BNF piece. c) Everything is a LFB. In other words you cant send a message to an entity "FE" or "CE" - you have to target an LFB class and instance. Main header ----------- No changes imposed by BNF 6.1 Association Messages ------------------------ 6.1.1 Association setup Message ------------------------------- Stays same, exception: No need for HB registration. That is now targeted to the FE protocol LFB. A suggestion is that perhaps a name TLV may need to be passed. Same level as LFB Select example main hdr (eg type = Association setup) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = FENAME | +-- "myname" 6.1.2 Association setup Response -------------------------------- Use a result TLV since as is now main hdr (eg type = Association setup response) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = FEResult | +-- resultvalue 6.1.3 Association Teardown message ----------------------------------- main hdr (eg type = Association tear) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = FEReason | +-- "myreason" 6.2 Query Messages ------------------- Gone. Replacement is: 6.2.1 Query message ------------------- main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance | | | | | +-- T = GET | | | | | +-- // one or more path targets | | // under discussion | | The LFB is targeted. So if you need to find a route from an LPM you target that LFB. If you need to find neighbors of an FE you target the FE object LFB. The response is exactly the same as above. 6.3 Configuration Message -------------------------- 6.3.1 Config request ---------------------- main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance | | | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | In other words: Very similar to the way we have it already except the naming has changed and we can target multiple operations and multiple paths in an LFB instance Event-subscribe and unsubscribe are also seen as possible operations. 6.3.2 Config Response --------------------- IMO the same as above except direction is from FE->CE except type is config-response. We need to introduce a new TLV called result. Sender will need to request a summary or message in totality echoed back. 6.4 Events ---------- I thought we said we will have a Event subscription message, I dont see it anywhere. NOTE: Added to config-request config-response 1) Given the concept of "everything is an LFB" it is my opinion that subscriptions should happen at per LFB level. i.e the model (xml file) will have to define what events a LFB class throws. Added some new text on subscription as being part of config-response/request above 2) Given you can map _any_ attribute to a path ID, then I see the event notifications and responses message layout being very much like the config messages excpet the type will be one of those two (notify and notify-response) 6.5 Packet redirect ------------------- One suggestion: main hdr (eg type = Packet Redirect) | | +--- T = LFBselect | | | +-- LFBCLASSID = target class | | | | | +-- LFBInstance = target instance | | | +-- T = PACKET_REDIR_OPER | | | | | +-- // one or more packets 6.6 State Maintanance --------------------- Gone. This should target the FE protocol object LFB . 6.7 Heartbeats -------------- My opinion is that this is gone or needs to target some LFB. Hormuzd so far is of mindest to maintain old approach. $Log: potential-protocol-changes.txt,v $ Revision 1.2 2004/10/16 14:58:04 hadi some minor changes based on input from Hormuzd one outstanding issue seems to be the query Revision 1.1 2004/10/14 18:53:40 hadi Initial revision --=-u6s5FRJaAabSMUy+OP+L Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=-u6s5FRJaAabSMUy+OP+L-- From forces-protocol-bounces@ietf.org Sat Oct 16 11:34:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27357 for ; Sat, 16 Oct 2004 11:34:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIql5-00005L-G0 for forces-protocol-web-archive@ietf.org; Sat, 16 Oct 2004 11:46:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIqVU-0002aO-6i; Sat, 16 Oct 2004 11:30:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIqUZ-0002Od-K0 for forces-protocol@megatron.ietf.org; Sat, 16 Oct 2004 11:29:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27184 for ; Sat, 16 Oct 2004 11:29:08 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIqgA-0008Sk-PZ for forces-protocol@ietf.org; Sat, 16 Oct 2004 11:41:11 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101608314054:30339 ; Sat, 16 Oct 2004 08:31:40 -0700 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: Steve Blake In-Reply-To: <1097927770.1043.35.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> <1097900642.19064.13.camel@localhost.localdomain> <1097927770.1043.35.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1097940541.1043.51.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Oct 2004 11:29:01 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/16/2004 08:31:41 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/16/2004 08:31:47 AM, Serialize complete at 10/16/2004 08:31:47 AM Content-Type: multipart/mixed; boundary="=-4QVhPckWpvYPdRuAYysL" X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: "Khosravi, Hormuzd M" , zsolt@petri-meat.com, ram.gopal@nokia.com, forces-protocol@ietf.org, "Joel M. Halpern" , Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 --=-4QVhPckWpvYPdRuAYysL Content-Type: text/plain Content-Transfer-Encoding: 7bit folks, I have updated the notes i put up earlier based on last discussions. Outstanding: 1) Steve/Zsolt please look at a note for you in the text 2) KEY and BLOCK mode to get consensus 3) DATA representation. This is a tough nut to crack. I dont think we (protocol side) need to totaly flush this out, but heavy discussion needed for it with everybody involved. cheers, jamal --=-4QVhPckWpvYPdRuAYysL Content-Disposition: attachment; filename=path-data-oper.txt Content-Type: text/plain; name=path-data-oper.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This doc builds up on what was posted by Steve/Zsolt[1] to try to map to protocol. It by no means imposes a decision i.e tghis is merely here as a discussion place holder with the a desire to speed things up. NOTE: ----- A small reminder on layout: main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = 0x45 | | | | | +-- LFBInstance = 0x1234 | | | +-- T = ADD //operation | | | | | +-- // path target X | | // with data to be added | | // This is the discussion point | | | +-- T = ADD //operation | | | | | +-- // path target Y | | // with data to be added | | // This is the discussion point | | | | | +-- T = DEL //operation | . | | . +-- // path target Z | . // This is the discussion point | 1) There could be multiple operations on any instance 2) path-data comes after the operation. 3) there is only one path-data per operation. A possible path-data layout. ---------------------------- OPER_TLV : = PATH-DATA := flags IDcount [BLOCK_OR_KEY_NOTATION] [DATA] The operational TLV contains an opcode in the T part. Its V contains the PATH-DATA. Opcodes discussed so far: * SET (create, modify or both depending on PATH-DATA flags} * DEL (remove an existing entity specified by PATH-DATA } * GET (Access a entity specified in PATH-DATA } * EV_S (subscribe to an event defined in PATH-DATA } * EV_U (unsubscribe to an event defined in PATH-DATA } -> IDs := a series of 32bit IDs (whose size is given by IDcount) defining the path. -> flags are used to further refine the operation to be applied on the ID_TLV. -> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension defined in section 4.2 and 4.3 of [1] -> DATA : = Optional variable sized data dependent on PATH and applied operations (eg GET will not have DATA). Some Clarification in relation to [1]: ------------------------------------- [1] represents a requirement gathering/place holder. This document is into details closer to implementation. flags ----- Derived from netlink and BSD route sockets to meet requirements defined in [1]: --> F_EXCL: The exclusive flag. Donot replace the config attribute(s) if already exists - Report back error instead. A CREATE operation with this flag is equivalent to INS_IDX if index is passed and equivalent to INS if index is not passed in the IDs. A DEL with this flag is equivalent to DEL! in [1]. Without this flag the equivalency is to DEL. --> F_REPLACE: Replace existing matching config attribute(s) with passed data. An index must be passed. In the case of key operations, a KEY must be passed. A CREATE operation with this flag is equivalent to a SET or a INS_IDX!. Steve/Zsolt please double check that this is matching to your doc. A CREATE operation with F_EXCL|F_REPLACE is equivalent to SET! ** Other flags used for block operations mentioned in the BLOCK section. BLOCK and KEY path selection ----------------------------- The variant described in [1] is not needed. To get access to all of table contents, the IDs merely need to point to the table. Therefore to access a range, the IDs field will contain the ID leading to a table and an optional TLV will include the range information. - Additional flags needed: 1)F_BLOCK_ON, to indicate block selector embeded 2)F_KEY_ON, to indicate a key selector embeded #1 and #2 are mutually exclusive. 3) F_REV_TRAVERSE, to indicate reverse progress in the access. 4) F_KEY_MODE (2 bits or more) to select the KEY mode in case #2 is on. 5) F_BLOCK_MODE (1 bit); indicates count or range for second parameter of BLOCK Notation. In the case of block operations: Two modes exist. [a,b] or [a,N] We introduce a block TLV T = BLOCK_TLV start // "a" end // "b" or "N" The flag F_BLOCK_ON will indicate the presence of this TLV. F_BLOCK_MODE will indicate that "end" is an "a" or "N" F_REV_TRAVERSE will indicate whether reverse or forward progress In the case of the associative paths: the flag F_KEY_ON will indicate that we are using associative approach F_KEY_MODE will define the mode . We introduce a KEY_INFO TLV. T = BLOCK_TLV KEY KEY_DATA The length of the TLV will help deducing the size of the KEY_DATA. DATA: ----- Not discussing the optional data right now; a lot of details above need ironing out first. DATA is complex twist when it comes with variable sized data. $Log: path-data-oper.txt,v $ Revision 1.2 2004/10/16 14:03:25 hadi incoporating feedback from Joel et al Revision 1.1 2004/10/14 13:12:32 hadi Initial revision --=-4QVhPckWpvYPdRuAYysL Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=-4QVhPckWpvYPdRuAYysL-- From forces-protocol-bounces@ietf.org Sat Oct 16 20:46:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24154 for ; Sat, 16 Oct 2004 20:46:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIzNJ-0008Hl-LL for forces-protocol-web-archive@ietf.org; Sat, 16 Oct 2004 20:58:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIzAc-0006aE-2M; Sat, 16 Oct 2004 20:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CIz9p-0006QS-8e for forces-protocol@megatron.ietf.org; Sat, 16 Oct 2004 20:44:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24045 for ; Sat, 16 Oct 2004 20:44:18 -0400 (EDT) Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CIzLV-0008FJ-9b for forces-protocol@ietf.org; Sat, 16 Oct 2004 20:56:25 -0400 Received: from rdu74-167-053.nc.rr.com ([24.74.167.53] helo=[192.168.2.3]) by server26.totalchoicehosting.com with esmtp (Exim 4.43) id 1CIz9F-0002Fn-Dg; Sat, 16 Oct 2004 20:43:46 -0400 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? From: Zsolt Haraszti To: Jamal Hadi Salim In-Reply-To: <1097927770.1043.35.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> <1097900642.19064.13.camel@localhost.localdomain> <1097927770.1043.35.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1097973624.2681.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 16 Oct 2004 20:40:24 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , "Yang, Lily L" , "Joel M. Halpern" , forces-protocol@ietf.org, ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , Alan DeKok , Ellen M Deleganes X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zsolt@nc.rr.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit On Sat, 2004-10-16 at 07:56, Jamal Hadi Salim wrote: > On Sat, 2004-10-16 at 00:24, Steven Blake wrote: > > > My problem about allowing a config command in the same PL-message as a > > query command (and I think Zsolt agrees with me), is that it complicates > > handling of any responses. I believe that, for any PL message with > > config commands, all of the possible exception responses can fit into > > a single PL message, and therefore we can correlate at the PL layer. > > However, it could be typical that a small query command message could > > result in several PL messages being returned (e.g., GET an entire > > table). > > > > Sounds like consensus is to put a note in the draft that such a case may > be hazardous and to be avoided. > > > For simplicity, I would like to see PL messages typed as either > > CONFIG-REQUEST, CONFIG-RESPONSE, QUERY-REQUEST, QUERY-RESPONSE, > > ASYNC-EVENT, ... > > Yes, I find this solution very clean. > > Ok, you still have a QUERY-REQUEST, QUERY-RESPONSE there - which is core > to this discussion; an alternative to that is a CONFIG-REQUEST with > operation = GET as well as CONFIG-RESPONSE with operation = GET. > So far theres a leaning towards CONFIG-*; if you disagree please > explain. > A query operation (GET) is not a config operation, so if you include GET as one of the many operations inside the CONFIG-REQUEST, then you should not call it CONFIG-REQUEST, but something else (e.g., OPERATION- REQUEST, which is ugly BTW). It seems we have consensus that we need an open-ended design that allows us to introduce new operations later. But merging all the operations under a single PL message type is not the only way to achieve this! GET is fundamentally different from the rest of the currently outlined operations (SET/ADD/DEL): - A QUERY always requires a response. For CONFIG operations you may elect to suppress response, or request for response only if error occurs, or select between detailedness of response based on success or failure. Nothing of which makes sense for QUERY operations. - For QUERY the response is typically as long as the request, more often much longer (e.g., GET content of a table). It is therefore expected that slightly different protocol behavior will be needed (e.g., multiple PL response to a single PL request). For CONFIG operations, the response is typically smaller (if any) then the request. Defining CONFIG-REQUEST/RESPONSE and QUERY-REQUEST/RESPONSE as two pairs of messages does not preclude later introduction of new operators. As a start we have GET as the allowed operator in QUERY-REQUEST:s, and SET/ADD/DEL as the allowed operators in CONFIG-REQUEST:s. Both sets can be extended later as needed. The internal structure of the two PL messages can be very similar if not identical: PL+>+> /zsolt > cheers, > jamal > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 16 23:51:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01559 for ; Sat, 16 Oct 2004 23:51:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJ2GJ-0002XQ-S5 for forces-protocol-web-archive@ietf.org; Sun, 17 Oct 2004 00:03:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJ23e-0005ia-O5; Sat, 16 Oct 2004 23:50:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJ233-0005Yc-3O for forces-protocol@megatron.ietf.org; Sat, 16 Oct 2004 23:49:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01490 for ; Sat, 16 Oct 2004 23:49:29 -0400 (EDT) Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJ2Ek-0002W8-Oj for forces-protocol@ietf.org; Sun, 17 Oct 2004 00:01:39 -0400 Received: from rdu74-167-053.nc.rr.com ([24.74.167.53] helo=[192.168.2.3]) by server26.totalchoicehosting.com with esmtp (Exim 4.43) id 1CJ22U-0001P7-MG; Sat, 16 Oct 2004 23:48:59 -0400 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? From: Zsolt Haraszti To: Jamal Hadi Salim In-Reply-To: <1097940541.1043.51.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> <1097900642.19064.13.camel@localhost.localdomain> <1097927770.1043.35.camel@jzny.localdomain> <1097940541.1043.51.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1097984736.2681.210.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 16 Oct 2004 23:45:36 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Joel M. Halpern" , Alan DeKok , forces-protocol@ietf.org, "Steven Blake \(petri-meat\)" , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zsolt@nc.rr.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 Content-Transfer-Encoding: 7bit Jamal, Good progress! See my comments embedded. On Sat, 2004-10-16 at 11:29, Jamal Hadi Salim wrote: > folks, > > I have updated the notes i put up earlier based on last discussions. > > Outstanding: > 1) Steve/Zsolt please look at a note for you in the text > 2) KEY and BLOCK mode to get consensus > 3) DATA representation. This is a tough nut to crack. I dont think > we (protocol side) need to totaly flush this out, but heavy discussion > needed for it with everybody involved. > Not that bad, I think. We have a working implementation for this at MN already, which is rather efficient and not terribly complex either. > cheers, > jamal > > This doc builds up on what was posted by Steve/Zsolt[1] to > try to map to protocol. > It by no means imposes a decision i.e tghis is merely here > as a discussion place holder with the a desire to speed things > up. > > NOTE: > ----- > > A small reminder on layout: > > main hdr (eg type = config) > | > | > +--- T = LFBselect > | | > | +-- LFBCLASSID = 0x45 > | | > | | > | +-- LFBInstance = 0x1234 > | | > | +-- T = ADD //operation > | | | > | | +-- // path target X > | | // with data to be added > | | // This is the discussion point > | | > | +-- T = ADD //operation > | | | > | | +-- // path target Y > | | // with data to be added > | | // This is the discussion point > | | > | | > | +-- T = DEL //operation > | . | > | . +-- // path target Z > | . // This is the discussion point > | > > 1) There could be multiple operations on any instance > 2) path-data comes after the operation. > 3) there is only one path-data per operation. Great so far. > > A possible path-data layout. > ---------------------------- > > OPER_TLV : = > PATH-DATA := flags IDcount [BLOCK_OR_KEY_NOTATION] [DATA] > > The operational TLV contains an opcode in the T part. Its V > contains the PATH-DATA. > Opcodes discussed so far: > * SET (create, modify or both depending on PATH-DATA flags} > * DEL (remove an existing entity specified by PATH-DATA } > * GET (Access a entity specified in PATH-DATA } > * EV_S (subscribe to an event defined in PATH-DATA } > * EV_U (unsubscribe to an event defined in PATH-DATA } An alternative to EV_S/U would be to model this via special LFB attributes, i.e., a ADD-ing/DEL-eting entries in a subscription table, modeled as an ARRAY attribute of the respective LFB. Then there is no need for a separate operations. > > -> IDs := a series of 32bit IDs (whose size is given by IDcount) > defining the path. > -> flags are used to further refine the operation to be applied > on the ID_TLV. Things that come to mind for SET/ADD/DEL: - PARTIAL_OK (1-bit): to select how partial success should be handled: "partial-ok" or "all-or-nothing". E.g., when the operation is to add a bunch of elements to a table, and only a portion succeeds, should the already added ones kept or should they be removed. Or for a more practical example: when a block delete is issued and only a subset of the specified indices are actually valid, delete the valid ones or not. Things that come to mind for GET: - EXISTENCE-ONLY (1-bit): if set, an existence flag should be returned instead of the full content of the selected data node. This is useful for the CE when exploring if a given path is valid. - INDICES-ONLY (1-bit): if refers to an ARRAY node and this bit is set, then the RESPONSE should contain only the list of currently valid indices instead of the full content of the ARRAY. This is useful for the CE when exploring what indices are valid in a given ARRAY. It can also be used to obtain the indices that correspond to a KEY, if KEY operations are supported. > -> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension > defined in section 4.2 and 4.3 of [1] > -> DATA : = Optional variable sized data dependent on PATH > and applied operations (eg GET will not have DATA). > > Some Clarification in relation to [1]: > ------------------------------------- > > [1] represents a requirement gathering/place holder. > This document is into details closer to implementation. > > flags > ----- > > Derived from netlink and BSD route sockets to meet requirements > defined in [1]: > > --> F_EXCL: > The exclusive flag. > Donot replace the config attribute(s) if already exists - > Report back error instead. > > A CREATE operation with this flag is equivalent to > INS_IDX if index is passed and equivalent to INS if index is > not passed in the IDs. > A DEL with this flag is equivalent to DEL! in [1]. Without > this flag the equivalency is to DEL. > > --> F_REPLACE: > Replace existing matching config attribute(s) with passed > data. An index must be passed. In the case of key operations, a > KEY must be passed. > A CREATE operation with this flag is equivalent to a SET > or a INS_IDX!. > > Steve/Zsolt please double check that this is matching to your > doc. Assuming the SET/ADD/DEL CONFIG-REQUEST operators (I use ADD here instead of INS, because I slightly prefer ADD over INS; but otherwise it has the same meaning as INS in all previous discussions), all we need for the above purpose is a single flag: F_PEDANTIC (or F_PICKY). (We can choose the inverse meaning, but I could not come up with a good word to describe that...) Before further discussing the meaning of this flag, a couple of notes: 1. For SET operations this flag plays a role only if path refers to an entry in an ARRAY data element, i.e., when path[:-1] refers to an ARRAY (in which case path[-1] is the index to be used inside the ARRAY). In all other cases the flag must be ignored. (Notation hint: path refers to the list of IDs, path[-1] refers to the last element of the list, and path[:-1] means the first part of the list without the last element.) So the meaning of the flag in this scope is as follows: if element[path] exists: element[path] = data report success/failure of assignment else: if OP_FLAGS & F_PEDANTIC: report error else: # attempt to add new element to array: add(element[path[:-1]], # ARRAY index=path[-1], # INDEX value=data) # initial value report success/failure of assignment In words, if F_PEDANTIC is cleared, create entry if it does not yet exist. If F_PEDANTIC is set, report error if entry does not yet exist. 2. For ADD/DEL operations: We will have actually two forms of ADD/DEL operations: a One where path specifies the entry in an ARRAY which is to be added/deleted, i.e., path[-1] is the entry index within the ARRAY, and path[:-1] is the reference to the ARRAY itself. b Another where path refers to the ARRAY itself and the index/indices of the entries to be added/removed are given as part of the [block] description. (For the ADD the indices may not be provided at all, in which case the FE can pick the indices; a.k.a. INS vs. INS_IDX.) Obviously this b) form is meant for block operations, though b. can do what a. can. I still would like to allow both forms because in single-entry operations the a. form is more staright-forward. BTW, we will have to signal in the OP TLV header which form we mean, because in the special case when both path[:-1] and path refer to an ARRAY (i.e., path[:-1] is an ARRAY of ARRAYs), the above two forms collide. This can be done via an F_BLOCK flag indicating b. when set, or separate SET/SET-BLOCK, ADD/ADD-BLOCK, and DEL/DEL-BLOCK operations (T's). Flags are OK. Now, the meaning of the F_PEDANTIC flag (assuming the above scope conditions are satisfied) is as follows: For ADD as in a.: if element[path] does not exists: add(element[path[:-1]], # ARRAY index=path[-1], # index valude=data) # initial value report success/failure of assignment else: if OP_FLAGS & F_PEDANTIC: report error else: element[path] = data # over-write element value report success/failure of assignment For ADD as in b.: for index in BLOCK: # Take each index specified in BLOCK # Do the same as above pseudo code, but replace # path with path+index, path[:-1] with path, # and path[-1] with index if element[path + index,] exists: add(element[path], index, data) report success/failure else: if OP_FLAGS & F_PEDANTIC: report error else: element[path + index,] = data report success/failure For DEL as in a.: if element[path] exists: del(element[path[:-1]], index=path[-1]) report error else: if OP_FLAGS & F_PEDANTIC: report error else: report success For DEL as in b.: for index in BLOCK: if element[path + index,] exists: del(element[path], index) else: if OP_FLAGS & F_PEDANTIC: report error else: report success By now you can infer the overall meaning of the F_PEDANTIC flag: If cleared, the FE should try to correct/ignore the element existence issue if there is one; if set, the FE must regard any entry existence issues as error and handle it accordingly. > > A CREATE operation with F_EXCL|F_REPLACE is equivalent to SET! > > ** Other flags used for block operations mentioned in the BLOCK section. > > BLOCK and KEY path selection > ----------------------------- > > The variant described in [1] is not needed. To get access > to all of table contents, the IDs merely need to point to the table. True. But with whatever notation you will come up to define the BLOCK, it will always allow for encoding the ALL case as an extreme case. And I don't think we should make that case illegal. > Therefore to access a range, the IDs field will contain the ID > leading to a table and an optional TLV will include the range > information. > > - Additional flags needed: > 1)F_BLOCK_ON, to indicate block selector embeded > 2)F_KEY_ON, to indicate a key selector embeded ACK > #1 and #2 are mutually exclusive. I agree provided that the KEY can include multiple keys of the same key type. > 3) F_REV_TRAVERSE, to indicate reverse progress in the access. I guess this would be meaningful only in QUERY (GET) operations, but I would NOT bother with this option. > 4) F_KEY_MODE (2 bits or more) to select the KEY mode in case #2 is > on. > 5) F_BLOCK_MODE (1 bit); indicates count or range for second > parameter of BLOCK Notation. > It may be cleaner to encode these modes inside the respective TLV, either as separate T values or as a special flag in the value part. > In the case of block operations: > > Two modes exist. [a,b] or [a,N] > We introduce a block TLV > > T = BLOCK_TLV > start // "a" > end // "b" or "N" > > The flag F_BLOCK_ON will indicate the presence of this TLV. > F_BLOCK_MODE will indicate that "end" is an "a" or "N" > F_REV_TRAVERSE will indicate whether reverse or forward progress > > In the case of the associative paths: > the flag F_KEY_ON will indicate that we are using associative approach > F_KEY_MODE will define the mode . > > We introduce a KEY_INFO TLV. > > T = BLOCK_TLV You meant KEY_INFO_TLV, I assume. > KEY > KEY_DATA > > The length of the TLV will help deducing the size of the KEY_DATA. I presume KEY specifies the key-type (in case more than one type of keys are allowed on the target). Remember: each key type is a collection of the struct fields that together can form a key. KEY_DATA is one **or more** data blocks satisfying the KEY definition. Each data block contains the necessary field values according to the KEY definition. > > DATA: > ----- > Not discussing the optional data right now; a lot of details > above need ironing out first. > DATA is complex twist when it comes with variable sized data. Steve and I will propose an encoding soon, to start that discussion. > > $Log: path-data-oper.txt,v $ > Revision 1.2 2004/10/16 14:03:25 hadi > incoporating feedback from Joel et al > > Revision 1.1 2004/10/14 13:12:32 hadi > Initial revision > /zsolt _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 17 00:46:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05683 for ; Sun, 17 Oct 2004 00:46:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJ37Z-0003Tk-2a for forces-protocol-web-archive@ietf.org; Sun, 17 Oct 2004 00:58:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJ2uv-0001CR-4t; Sun, 17 Oct 2004 00:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJ2tx-0000s3-Th for forces-protocol@megatron.ietf.org; Sun, 17 Oct 2004 00:44:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05516 for ; Sun, 17 Oct 2004 00:44:10 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJ35g-0003QX-6g for forces-protocol@ietf.org; Sun, 17 Oct 2004 00:56:20 -0400 Received: from JLaptop.megisto.com ([192.168.20.227]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 17 Oct 2004 00:42:54 -0400 Message-Id: <5.1.0.14.0.20041017003820.02343a88@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 17 Oct 2004 00:42:03 -0400 To: zsolt@nc.rr.com, Jamal Hadi Salim From: "Joel M. Halpern" Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? In-Reply-To: <1097973624.2681.25.camel@localhost.localdomain> References: <1097927770.1043.35.camel@jzny.localdomain> <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> <1097900642.19064.13.camel@localhost.localdomain> <1097927770.1043.35.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 17 Oct 2004 04:42:54.0402 (UTC) FILETIME=[C445B220:01C4B403] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 A minor comment. I think we should never have a request with ~respond only if an error occurs~. My reasoning is that if one has such a request, you never know how long to wait to allow for the error response. I am doubtful of the value of a set with no response. But if one wants a response, it should not be conditional. Yours, Joel PS: On the structuring of messages and operations, I can live with creating two kinds of operations, one type for query operations, used in query messages, and one type for manipulation operations, used in config messages. Clearly, we want the structures to be the same, even if we do use two message types. At 08:40 PM 10/16/2004 -0400, Zsolt Haraszti wrote: >or CONFIG operations you may > elect to suppress response, or request for response only if error > occurs, _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 17 10:24:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27021 for ; Sun, 17 Oct 2004 10:24:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJC8x-0000St-8N for forces-protocol-web-archive@ietf.org; Sun, 17 Oct 2004 10:36:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJBwD-0005BY-BH; Sun, 17 Oct 2004 10:23:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJBvb-00052n-Cv for forces-protocol@megatron.ietf.org; Sun, 17 Oct 2004 10:22:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26920 for ; Sun, 17 Oct 2004 10:22:29 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJC7O-0000Qu-Rm for forces-protocol@ietf.org; Sun, 17 Oct 2004 10:34:43 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101707250073:30996 ; Sun, 17 Oct 2004 07:25:00 -0700 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: zsolt@nc.rr.com In-Reply-To: <1097973624.2681.25.camel@localhost.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> <1097900642.19064.13.camel@localhost.localdomain> <1097927770.1043.35.camel@jzny.localdomain> <1097973624.2681.25.camel@localhost.localdomain> Organization: ZNYX Networks Message-Id: <1098022941.1049.58.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Oct 2004 10:22:22 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/17/2004 07:25:01 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/17/2004 07:25:06 AM, Serialize complete at 10/17/2004 07:25:06 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , "Yang, Lily L" , "Joel M. Halpern" , forces-protocol@ietf.org, ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , Alan DeKok , Ellen M Deleganes X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit On Sat, 2004-10-16 at 20:40, Zsolt Haraszti wrote: > A query operation (GET) is not a config operation, so if you include > GET as one of the many operations inside the CONFIG-REQUEST, then you > should not call it CONFIG-REQUEST, but something else (e.g., OPERATION- > REQUEST, which is ugly BTW). > Ok, this is a fair semantic view. I am gonna stay indifferent; if people wanna go this path i am fine with it. > It seems we have consensus that we need an open-ended design that > allows us to introduce new operations later. But merging all > the operations under a single PL message type is not the only > way to achieve this! > > GET is fundamentally different from the rest of the currently outlined > operations (SET/ADD/DEL): > - A QUERY always requires a response. For CONFIG operations you may > elect to suppress response, or request for response only if error > occurs, or select between detailedness of response based on success > or failure. Nothing of which makes sense for QUERY operations. > - For QUERY the response is typically as long as the request, more > often much longer (e.g., GET content of a table). It is therefore > expected that slightly different protocol behavior will be needed > (e.g., multiple PL response to a single PL request). > For CONFIG operations, the response is typically smaller (if any) > then the request. > > Defining CONFIG-REQUEST/RESPONSE and QUERY-REQUEST/RESPONSE as > two pairs of messages does not preclude later introduction of new > operators. > > As a start we have GET as the allowed operator in QUERY-REQUEST:s, > and SET/ADD/DEL as the allowed operators in CONFIG-REQUEST:s. > Both sets can be extended later as needed. > > The internal structure of the two PL messages can be very similar > if not identical: PL+>+> > They would be identical. It would probably be a little uggly to have one type with differentiation happening at the operation level. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 17 10:53:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28754 for ; Sun, 17 Oct 2004 10:53:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJCb9-0000ub-Cm for forces-protocol-web-archive@ietf.org; Sun, 17 Oct 2004 11:05:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJCON-0000Td-DS; Sun, 17 Oct 2004 10:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJCMs-0000Dj-Mq for forces-protocol@megatron.ietf.org; Sun, 17 Oct 2004 10:50:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28590 for ; Sun, 17 Oct 2004 10:50:40 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJCYg-0000ry-4z for forces-protocol@ietf.org; Sun, 17 Oct 2004 11:02:54 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101707531501:31019 ; Sun, 17 Oct 2004 07:53:15 -0700 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: zsolt@nc.rr.com In-Reply-To: <1097984736.2681.210.camel@localhost.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> <1097900642.19064.13.camel@localhost.localdomain> <1097927770.1043.35.camel@jzny.localdomain> <1097940541.1043.51.camel@jzny.localdomain> <1097984736.2681.210.camel@localhost.localdomain> Organization: ZNYX Networks Message-Id: <1098024636.1049.87.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Oct 2004 10:50:37 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/17/2004 07:53:16 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/17/2004 07:53:17 AM, Serialize complete at 10/17/2004 07:53:17 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Joel M. Halpern" , Alan DeKok , forces-protocol@ietf.org, "Steven Blake \(petri-meat\)" , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit On Sat, 2004-10-16 at 23:45, Zsolt Haraszti wrote: > Jamal, > > Good progress! See my comments embedded. > > On Sat, 2004-10-16 at 11:29, Jamal Hadi Salim wrote: > > folks, > > > > I have updated the notes i put up earlier based on last discussions. > > > > Outstanding: > > 1) Steve/Zsolt please look at a note for you in the text > > 2) KEY and BLOCK mode to get consensus > > 3) DATA representation. This is a tough nut to crack. I dont think > > we (protocol side) need to totaly flush this out, but heavy discussion > > needed for it with everybody involved. > > > Not that bad, I think. We have a working implementation for this > at MN already, which is rather efficient and not terribly complex > either. We have one also but i would call it ugly ;-> Heres the litmus test Two data tables -Table1: has dummy struct with foo1 and foo2 being u32s -Table2: has dummy2 struct with a u32 foo3, varibale sized foo4, variable sized foo5 and u32 foo6. > > > > A possible path-data layout. > > ---------------------------- > > > > OPER_TLV : = > > PATH-DATA := flags IDcount [BLOCK_OR_KEY_NOTATION] [DATA] > > > > The operational TLV contains an opcode in the T part. Its V > > contains the PATH-DATA. > > Opcodes discussed so far: > > * SET (create, modify or both depending on PATH-DATA flags} > > * DEL (remove an existing entity specified by PATH-DATA } > > * GET (Access a entity specified in PATH-DATA } > > * EV_S (subscribe to an event defined in PATH-DATA } > > * EV_U (unsubscribe to an event defined in PATH-DATA } > > An alternative to EV_S/U would be to model this via special > LFB attributes, i.e., a ADD-ing/DEL-eting entries in a > subscription table, modeled as an ARRAY attribute of the > respective LFB. Then there is no need for a separate > operations. The assumption here is the model team will have events defined as attributes (on a per LFB basis). For the same semantical reasons as having a query being a separate type, I think that the events should be separate operation. This also helps so that if i am running a sniffer/debuger I could easily tell it is an event vs other attributes. > > > > -> IDs := a series of 32bit IDs (whose size is given by IDcount) > > defining the path. > > -> flags are used to further refine the operation to be applied > > on the ID_TLV. > > Things that come to mind for SET/ADD/DEL: > - PARTIAL_OK (1-bit): to select how partial success should be handled: > "partial-ok" or "all-or-nothing". E.g., when the operation > is to add a bunch of elements to a table, and only a portion > succeeds, should the already added ones kept or should > they be removed. Or for a more practical example: when a block > delete is issued and only a subset of the specified indices are > actually valid, delete the valid ones or not. > In the same vein: Do we need a commit flag as well as an atomic flag? > Things that come to mind for GET: > - EXISTENCE-ONLY (1-bit): if set, an existence flag should be > returned instead of the full content of the selected data node. > This is useful for the CE when exploring if a given path is > valid. Sounds valuable; How does F_PEEK sound? > - INDICES-ONLY (1-bit): if refers to an ARRAY node and > this bit is set, then the RESPONSE should contain only the > list of currently valid indices instead of the full content of > the ARRAY. This is useful for the CE when exploring what indices > are valid in a given ARRAY. It can also be used to obtain the > indices that correspond to a KEY, if KEY operations are supported. A List operation is what it sounds like. Why restrict it to indices only? Doesnt it fall under some generic operation which specifies what elements should be filtered in or out? > > -> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension > > defined in section 4.2 and 4.3 of [1] > > -> DATA : = Optional variable sized data dependent on PATH > > and applied operations (eg GET will not have DATA). > > > > Some Clarification in relation to [1]: > > ------------------------------------- > > > > [1] represents a requirement gathering/place holder. > > This document is into details closer to implementation. > > > > flags > > ----- > > > > Derived from netlink and BSD route sockets to meet requirements > > defined in [1]: > > > > --> F_EXCL: > > The exclusive flag. > > Donot replace the config attribute(s) if already exists - > > Report back error instead. > > > > A CREATE operation with this flag is equivalent to > > INS_IDX if index is passed and equivalent to INS if index is > > not passed in the IDs. > > A DEL with this flag is equivalent to DEL! in [1]. Without > > this flag the equivalency is to DEL. > > > > --> F_REPLACE: > > Replace existing matching config attribute(s) with passed > > data. An index must be passed. In the case of key operations, a > > KEY must be passed. > > A CREATE operation with this flag is equivalent to a SET > > or a INS_IDX!. > > > > Steve/Zsolt please double check that this is matching to your > > doc. > > Assuming the SET/ADD/DEL CONFIG-REQUEST operators (I use ADD > here instead of INS, because I slightly prefer ADD over INS; Sure. Ok, Before i address the rest of your email, let me cut to define the config operations. I think there are several operations and their legitimacy depends on whether a targeted path is a terminal (eg array 7 index 3, foo1 - where foo1 is not another table) or not (array 7). Operation beinfg ADD: a). CREATE - valid only when the path is non-terminal such as if the target path is an array. A terminal in the case of an array is an element within an array row. A created entry may be initialized to certain values. b). UPDATE - valid at both terminal or non-terminal. Assumes an existing entry. Of course #1 and #2 can be combined in one atomic operation. Operation DEL - valid only at a terminal location. The protocol implementation should be able to tell from the IDs if target is terminal or not. This is where the conditions of error checking apply: i.e does the element exist? is it a terminal? F_EXEC and F_REPLACE flags combination apply and this should also take care of whether an index was passed or not. Let me cut here since email is long. I will continue rest in another email. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 17 11:21:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00128 for ; Sun, 17 Oct 2004 11:21:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJD27-0001HX-5J for forces-protocol-web-archive@ietf.org; Sun, 17 Oct 2004 11:33:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJCoO-0003wK-OX; Sun, 17 Oct 2004 11:19:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJCnq-0003pg-Or for forces-protocol@megatron.ietf.org; Sun, 17 Oct 2004 11:18:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29983 for ; Sun, 17 Oct 2004 11:18:32 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJCze-0001Fj-KG for forces-protocol@ietf.org; Sun, 17 Oct 2004 11:30:47 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101708210696:31033 ; Sun, 17 Oct 2004 08:21:06 -0700 Subject: [2] RE: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: zsolt@nc.rr.com In-Reply-To: <1097984736.2681.210.camel@localhost.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> <1097900642.19064.13.camel@localhost.localdomain> <1097927770.1043.35.camel@jzny.localdomain> <1097940541.1043.51.camel@jzny.localdomain> <1097984736.2681.210.camel@localhost.localdomain> Organization: ZNYX Networks Message-Id: <1098026308.1043.115.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Oct 2004 11:18:29 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/17/2004 08:21:08 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/17/2004 08:21:09 AM, Serialize complete at 10/17/2004 08:21:09 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , "Joel M. Halpern" , ram.gopal@nokia.com, forces-protocol@ietf.org, "Steven Blake \(petri-meat\)" , Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Content-Transfer-Encoding: 7bit On Sat, 2004-10-16 at 23:45, Zsolt Haraszti wrote: > On Sat, 2004-10-16 at 11:29, Jamal Hadi Salim wrote: > Assuming the SET/ADD/DEL CONFIG-REQUEST operators (I use ADD > here instead of INS, because I slightly prefer ADD over INS; > but otherwise it has the same meaning as INS in all previous > discussions), all we need for the above purpose is a single flag: > F_PEDANTIC (or F_PICKY). (We can choose the inverse meaning, but > I could not come up with a good word to describe that...) If you assume BSDism (probably std database table manipulation) then a single flag is insufficient. You need the equivalent of EXCL and REPLACE. i.e an ADD with EXCL|REPLACE to a table implies create and update with passed values. This allows you to at times just create and have default values populated. You seem to be saying a ADD = CREATEing an element and a SET is an update to an existing entry? > Before further discussing the meaning of this flag, a couple of > notes: > > 1. For SET operations this flag plays a role only if path > refers to an entry in an ARRAY data element, i.e., when > path[:-1] refers to an ARRAY (in which case path[-1] is the > index to be used inside the ARRAY). In all other cases the flag > must be ignored. > We may be on the same page, you are refering to non-terminal in this case. > (Notation hint: path refers to the list of IDs, path[-1] refers > to the last element of the list, and path[:-1] means the > first part of the list without the last element.) > > So the meaning of the flag in this scope is as follows: > > if element[path] exists: > element[path] = data > report success/failure of assignment > else: > if OP_FLAGS & F_PEDANTIC: > report error > else: > # attempt to add new element to array: > add(element[path[:-1]], # ARRAY > index=path[-1], # INDEX > value=data) # initial value > report success/failure of assignment > > In words, if F_PEDANTIC is cleared, create entry if it > does not yet exist. If F_PEDANTIC is set, report error > if entry does not yet exist. > Ok, now i am sure we mean the same thing, except you have separated update from create. I think it is valuable to keep them together. > 2. For ADD/DEL operations: > We will have actually two forms of ADD/DEL operations: > a One where path specifies the entry in an ARRAY which is > to be added/deleted, i.e., path[-1] is the entry index > within the ARRAY, and path[:-1] is the reference to the > ARRAY itself. > b Another where path refers to the ARRAY itself and the > index/indices of the entries to be added/removed are given > as part of the [block] description. (For the ADD the > indices may not be provided at all, in which case the FE > can pick the indices; a.k.a. INS vs. INS_IDX.) > Obviously this b) form is meant for block operations, > though b. can do what a. can. I still would like to > allow both forms because in single-entry operations the > a. form is more staright-forward. > > BTW, we will have to signal in the OP TLV header > which form we mean, because in the special case when > both path[:-1] and path refer to an ARRAY (i.e., path[:-1] > is an ARRAY of ARRAYs), the above two forms collide. This > can be done via an F_BLOCK flag indicating b. when set, > or separate SET/SET-BLOCK, ADD/ADD-BLOCK, and DEL/DEL-BLOCK > operations (T's). Flags are OK. > > Now, the meaning of the F_PEDANTIC flag (assuming the above > scope conditions are satisfied) is as follows: > > For ADD as in a.: > > if element[path] does not exists: > add(element[path[:-1]], # ARRAY > index=path[-1], # index > valude=data) # initial value > report success/failure of assignment > else: > if OP_FLAGS & F_PEDANTIC: > report error > else: > element[path] = data # over-write element value > report success/failure of assignment > > For ADD as in b.: > > for index in BLOCK: # Take each index specified in BLOCK > # Do the same as above pseudo code, but replace > # path with path+index, path[:-1] with path, > # and path[-1] with index > if element[path + index,] exists: > add(element[path], index, data) > report success/failure > else: > if OP_FLAGS & F_PEDANTIC: > report error > else: > element[path + index,] = data > report success/failure > > For DEL as in a.: > > if element[path] exists: > del(element[path[:-1]], index=path[-1]) > report error > else: > if OP_FLAGS & F_PEDANTIC: > report error > else: > report success > > For DEL as in b.: > > for index in BLOCK: > if element[path + index,] exists: > del(element[path], index) > else: > if OP_FLAGS & F_PEDANTIC: > report error > else: > report success > > By now you can infer the overall meaning of the F_PEDANTIC flag: > If cleared, the FE should try to correct/ignore the element existence > issue if there is one; if set, the FE must regard any entry existence > issues as error and handle it accordingly. > Ok, so the conclusion i reach is you have separated CREATE from UPDATE, everything else seems to be the same (you didnt refer to terminals vs non-terminals). In what i described earlier both are under the same umbrella of ADD with differentiation being the flags. Is there any good reason you are deviating from the norm (or what i consider to be the norm). To compare against netlink and BSD route socket approach in operations to ADD: F_REPLACE: Replace existing matching config object with this request. F_EXCL: Do not replace the config object if it already exists. F_CREATE: Create config object if it does not already exist. BSD ADD operation equates to F_CREATE or-ed with F_EXCL BSD CHANGE operation equates F_REPLACE BSD Check operation equates F_EXCL BSD APPEND equivalent is actually mapped to F_CREATE The existence of a passed index is actually in addition to the above. > > > > A CREATE operation with F_EXCL|F_REPLACE is equivalent to SET! > > > > ** Other flags used for block operations mentioned in the BLOCK > section. > > > > BLOCK and KEY path selection > > ----------------------------- > > > > The variant described in [1] is not needed. To get access > > to all of table contents, the IDs merely need to point to the table. > > True. But with whatever notation you will come up to define the > BLOCK, it will always allow for encoding the ALL case as an extreme > case. And I don't think we should make that case illegal. > What i meant is if i wanted to get table 7 then my ID will be 7. The BLCOK will be a further filter. > > Therefore to access a range, the IDs field will contain the ID > > leading to a table and an optional TLV will include the range > > information. > > > > - Additional flags needed: > > 1)F_BLOCK_ON, to indicate block selector embeded > > 2)F_KEY_ON, to indicate a key selector embeded > > ACK > > > #1 and #2 are mutually exclusive. > > I agree provided that the KEY can include multiple keys of the > same key type. > Makes sense. > > 3) F_REV_TRAVERSE, to indicate reverse progress in the access. > > I guess this would be meaningful only in QUERY (GET) operations, > but I would NOT bother with this option. > It was mentioned in the doc you guys posted; will restrict it to being a flag. > > 4) F_KEY_MODE (2 bits or more) to select the KEY mode in case #2 is > > on. > > 5) F_BLOCK_MODE (1 bit); indicates count or range for second > > parameter of BLOCK Notation. > > > > It may be cleaner to encode these modes inside the respective TLV, > either as separate T values or as a special flag in the value part. The start/end values are a TLV as shown below. Did you mean something else? > > In the case of block operations: > > > > Two modes exist. [a,b] or [a,N] > > We introduce a block TLV > > > > T = BLOCK_TLV > > start // "a" > > end // "b" or "N" > > > > The flag F_BLOCK_ON will indicate the presence of this TLV. > > F_BLOCK_MODE will indicate that "end" is an "a" or "N" > > F_REV_TRAVERSE will indicate whether reverse or forward progress > > > > In the case of the associative paths: > > the flag F_KEY_ON will indicate that we are using associative approach > > F_KEY_MODE will define the mode . > > > > We introduce a KEY_INFO TLV. > > > > T = BLOCK_TLV > > You meant KEY_INFO_TLV, I assume. > Of course ;-> That was intentionaly entered bug to see if people read the doc ;-> Now i know you paid good attention ;-> > > KEY > > KEY_DATA > > > > The length of the TLV will help deducing the size of the KEY_DATA. > > I presume KEY specifies the key-type (in case more than one type > of keys are allowed on the target). Remember: each key type is a > collection of the struct fields that together can form a key. > > KEY_DATA is one **or more** data blocks satisfying the KEY definition. > Each data block contains the necessary field values according to > the KEY definition. > The content aspect of things i dont have good clarity on. so provide me with better definition on how things should be laid out and i will update the doc. > > > > DATA: > > ----- > > Not discussing the optional data right now; a lot of details > > above need ironing out first. > > DATA is complex twist when it comes with variable sized data. > > Steve and I will propose an encoding soon, to start that discussion. Factor in the litmus test i provided in earlier email. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 17 14:15:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12518 for ; Sun, 17 Oct 2004 14:15:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJFkZ-0004Eu-LI for forces-protocol-web-archive@ietf.org; Sun, 17 Oct 2004 14:27:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJFXj-0001FI-EF; Sun, 17 Oct 2004 14:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJFWy-00019V-IG for forces-protocol@megatron.ietf.org; Sun, 17 Oct 2004 14:13:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12465 for ; Sun, 17 Oct 2004 14:13:19 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJFio-0004DB-92 for forces-protocol@ietf.org; Sun, 17 Oct 2004 14:25:34 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101711155300:31100 ; Sun, 17 Oct 2004 11:15:53 -0700 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: Zsolt Haraszti In-Reply-To: <1098028107.2681.214.camel@localhost.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> <1097900642.19064.13.camel@localhost.localdomain> <1097927770.1043.35.camel@jzny.localdomain> <1097940541.1043.51.camel@jzny.localdomain> <1097984736.2681.210.camel@localhost.localdomain> <1098024636.1049.87.camel@jzny.localdomain> <1098028107.2681.214.camel@localhost.localdomain> Organization: ZNYX Networks Message-Id: <1098036789.1042.120.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Oct 2004 14:13:10 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/17/2004 11:15:53 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/17/2004 11:15:55 AM, Serialize complete at 10/17/2004 11:15:55 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Joel M. Halpern" , Alan DeKok , forces-protocol@ietf.org, "Steven Blake \(petri-meat\)" , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit On Sun, 2004-10-17 at 11:48, Zsolt Haraszti wrote: > On Sun, 2004-10-17 at 10:50, Jamal Hadi Salim wrote: > > > > > > * EV_S (subscribe to an event defined in PATH-DATA } > > > > * EV_U (unsubscribe to an event defined in PATH-DATA } > > > > > > An alternative to EV_S/U would be to model this via special > > > LFB attributes, i.e., a ADD-ing/DEL-eting entries in a > > > subscription table, modeled as an ARRAY attribute of the > > > respective LFB. Then there is no need for a separate > > > operations. > > > > The assumption here is the model team will have events defined as > > attributes (on a per LFB basis). > > For the same semantical reasons as having a query being a separate type, > > I think that the events should be separate operation. This also helps so > > that if i am running a sniffer/debuger I could easily tell it is an > > event vs other attributes. > > I was talking about the subscribe/un-subscribe messages. > I was as well, the difference being the operation; if i understood you correctly you implied: config/add/event_attribute for susbscription vs config/evs/event attribute i was implying or config/del/event_attribute vs config/evu/event_attribute I think its cleaner to have operation being event subscribe say vs add etc. > The actual asynchronous event notification should indeed be a > separate PL type, as Steve called it out by EVENT. > We have that already. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 00:21:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25639 for ; Mon, 18 Oct 2004 00:21:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJPDA-00072F-Ee for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 00:33:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJOye-0002cO-PT; Mon, 18 Oct 2004 00:18:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJOwk-00020c-5v for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 00:16:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24446 for ; Mon, 18 Oct 2004 00:16:31 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJP8f-0006pT-1I for forces-protocol@ietf.org; Mon, 18 Oct 2004 00:28:53 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9I4JemE018876; Mon, 18 Oct 2004 04:19:40 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9I49i74004787; Mon, 18 Oct 2004 04:09:44 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101721154413882 ; Sun, 17 Oct 2004 21:15:44 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 17 Oct 2004 21:15:44 -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 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? Date: Sun, 17 Oct 2004 21:15:29 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> Thread-Topic: [Forces-protocol] RE: GET/SET in one msg ? Thread-Index: AcS0A9SuIKE3+OnSSBaiP+GAz3jk1QAxDaQg From: "Khosravi, Hormuzd M" To: "Joel M. Halpern" , , "Jamal Hadi Salim" X-OriginalArrivalTime: 18 Oct 2004 04:15:44.0295 (UTC) FILETIME=[2310DB70:01C4B4C9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, forces-protocol@ietf.org, "Steven Blake \(petri-meat\)" , Alan DeKok , "Deleganes, Ellen M" , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Joel M. Halpern [mailto:jhalpern@MEGISTO.com]=20 PS: On the structuring of messages and operations, I can live with creating=20 two kinds of operations, one type for query operations, used in query=20 messages, and one type for manipulation operations, used in config=20 messages. Clearly, we want the structures to be the same, even if we do use two message types. [HK] Agreed, seems like we have a concensus on this issue now (CONFIG-REQUEST, CONFIG-RESPONSE, QUERY-REQUEST, QUERY-RESPONSE msgs). Jamal, can we close on this one now for the protocol? Think you said yes, but just want to confirm. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 08:16:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10350 for ; Mon, 18 Oct 2004 08:16:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJWct-00079m-UH for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 08:28:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWO6-0008Pf-BD; Mon, 18 Oct 2004 08:13:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWKm-0007jn-9n for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 08:09:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10020 for ; Mon, 18 Oct 2004 08:09:51 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJWTf-0006sl-DQ for forces-protocol@ietf.org; Mon, 18 Oct 2004 08:22:15 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Mon, 18 Oct 2004 20:22:40 +0800 (CST) Received: from wwm1 (unverified [219.82.176.110]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Mon, 18 Oct 2004 20:02:47 +0800 Message-ID: <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> From: "Weiming Wang" To: "Khosravi, Hormuzd M" , "Joel M. Halpern" , , "Jamal Hadi Salim" References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Mon, 18 Oct 2004 20:07:53 +0800 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, Alan DeKok , "Deleganes, Ellen M" , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 I'm glad to see this. Let's just move one issue forward. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" [HK] Agreed, seems like we have a concensus on this issue now (CONFIG-REQUEST, CONFIG-RESPONSE, QUERY-REQUEST, QUERY-RESPONSE msgs). Jamal, can we close on this one now for the protocol? Think you said yes, but just want to confirm. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 08:37:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11723 for ; Mon, 18 Oct 2004 08:37:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJWxZ-0007Yx-UC for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 08:49:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWgK-0001iI-CN; Mon, 18 Oct 2004 08:32:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWbR-00017e-Nw for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 08:27:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11112 for ; Mon, 18 Oct 2004 08:27:04 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJWmt-0007Jx-4N for forces-protocol@ietf.org; Mon, 18 Oct 2004 08:39:29 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Mon, 18 Oct 2004 20:22:40 +0800 (CST) Received: from wwm1 (unverified [219.82.176.110]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Mon, 18 Oct 2004 20:02:47 +0800 Message-ID: <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> From: "Weiming Wang" To: "Khosravi, Hormuzd M" , "Joel M. Halpern" , , "Jamal Hadi Salim" References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Mon, 18 Oct 2004 20:07:53 +0800 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, Alan DeKok , "Deleganes, Ellen M" , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 I'm glad to see this. Let's just move one issue forward. Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" [HK] Agreed, seems like we have a concensus on this issue now (CONFIG-REQUEST, CONFIG-RESPONSE, QUERY-REQUEST, QUERY-RESPONSE msgs). Jamal, can we close on this one now for the protocol? Think you said yes, but just want to confirm. Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 08:44:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12100 for ; Mon, 18 Oct 2004 08:44:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJX4N-0007gJ-SG for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 08:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWmC-0002MH-OT; Mon, 18 Oct 2004 08:38:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJWgj-0001ou-J5 for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 08:32:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11440 for ; Mon, 18 Oct 2004 08:32:32 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJWse-0007S4-5j for forces-protocol@ietf.org; Mon, 18 Oct 2004 08:44:57 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101805345249:31613 ; Mon, 18 Oct 2004 05:34:52 -0700 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: Weiming Wang In-Reply-To: <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> Organization: ZNYX Networks Message-Id: <1098102734.1042.134.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Oct 2004 08:32:14 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/18/2004 05:34:53 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/18/2004 05:35:03 AM, Serialize complete at 10/18/2004 05:35:03 AM Content-Type: multipart/mixed; boundary="=-zzdBNMkrwWat8jTPH6uT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , "Joel M. Halpern" , Alan DeKok , zsolt@nc.rr.com, forces-protocol@ietf.org, Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 --=-zzdBNMkrwWat8jTPH6uT Content-Type: text/plain Content-Transfer-Encoding: 7bit Welcome back Weiming. I have updated the text with the query/response. The only outstanding issue is 6.7. Please weigh in. I think we are ready top start making updates. cheers, jamal On Mon, 2004-10-18 at 08:07, Weiming Wang wrote: > I'm glad to see this. Let's just move one issue forward. > > Weiming > > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > > [HK] Agreed, seems like we have a concensus on this issue now > (CONFIG-REQUEST, CONFIG-RESPONSE, QUERY-REQUEST, QUERY-RESPONSE msgs). > > Jamal, can we close on this one now for the protocol? Think you said > yes, but just want to confirm. > > Thanks > Hormuzd > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > > --=-zzdBNMkrwWat8jTPH6uT Content-Disposition: attachment; filename=potential-protocol-changes.txt Content-Type: text/plain; name=potential-protocol-changes.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Assumptions: ------------ a) Start by assuming BNF as discussed with model team (posted earlier). b) When no value is added by BNF discussed restore old scheme and fix associated BNF piece. c) Everything is a LFB. In other words you cant send a message to an entity "FE" or "CE" - you have to target an LFB class and instance. Main header ----------- No changes imposed by BNF 6.1 Association Messages ------------------------ 6.1.1 Association setup Message ------------------------------- Stays same, exception: No need for HB registration. That is now targeted to the FE protocol LFB. A suggestion is that perhaps a name TLV may need to be passed. Same level as LFB Select example main hdr (eg type = Association setup) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = FENAME | +-- "myname" 6.1.2 Association setup Response -------------------------------- Use a result TLV since as is now main hdr (eg type = Association setup response) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = FEResult | +-- resultvalue 6.1.3 Association Teardown message ----------------------------------- main hdr (eg type = Association tear) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = FEReason | +-- "myreason" 6.2 Query Messages ------------------- 6.2.1 Query message ------------------- main hdr (eg type = Query) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance | | | | | +-- T = GET | | | | | +-- // one or more path targets | | // under discussion | | The LFB is targeted. So if you need to find a route from an LPM you target that LFB. If you need to find neighbors of an FE you target the FE object LFB. The response is exactly the same as above with type = Query-response. 6.3 Configuration Message -------------------------- 6.3.1 Config request ---------------------- main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance | | | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | In other words: Very similar to the way we have it already except the naming has changed and we can target multiple operations and multiple paths in an LFB instance Event-subscribe and unsubscribe are also seen as possible operations. 6.3.2 Config Response --------------------- IMO the same as above except direction is from FE->CE except type is config-response. We need to introduce a new TLV called result. Sender will need to request a summary or message in totality echoed back. 6.4 Events ---------- I thought we said we will have a Event subscription message, I dont see it anywhere. NOTE: Added to config-request config-response 1) Given the concept of "everything is an LFB" it is my opinion that subscriptions should happen at per LFB level. i.e the model (xml file) will have to define what events a LFB class throws. Added some new text on subscription as being part of config-response/request above to show this. 2) Given you can map _any_ attribute to a path ID, then I see the event notifications and responses message layout being very much like the config messages excpet the type will be one of those two (Eventnotify and Eventnotify-response) 6.5 Packet redirect ------------------- One suggestion: main hdr (eg type = Packet Redirect) | | +--- T = LFBselect | | | +-- LFBCLASSID = target class | | | | | +-- LFBInstance = target instance | | | +-- T = PACKET_REDIR_OPER | | | | | +-- // one or more packets 6.6 State Maintanance --------------------- Gone. This should target the FE protocol object LFB . 6.7 Heartbeats -------------- My opinion is that this is gone or needs to target some LFB. Hormuzd so far is of mindest to maintain old approach. $Log: potential-protocol-changes.txt,v $ Revision 1.3 2004/10/18 12:29:22 hadi updated config/get to be query/get Revision 1.2 2004/10/16 14:58:04 hadi some minor changes based on input from Hormuzd one outstanding issue seems to be the query Revision 1.1 2004/10/14 18:53:40 hadi Initial revision --=-zzdBNMkrwWat8jTPH6uT Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=-zzdBNMkrwWat8jTPH6uT-- From forces-protocol-bounces@ietf.org Mon Oct 18 10:25:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21099 for ; Mon, 18 Oct 2004 10:25:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJYdk-0001QR-Ar for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 10:37:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJYPs-0001zO-QO; Mon, 18 Oct 2004 10:23:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJYJv-00017b-5p for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 10:17:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20165 for ; Mon, 18 Oct 2004 10:17:05 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJYVs-0001FP-0x for forces-protocol@ietf.org; Mon, 18 Oct 2004 10:29:31 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CJXUZ-0007me-3W for forces-protocol@ietf.org; Mon, 18 Oct 2004 09:24:03 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Mon, 18 Oct 2004 22:35:16 +0800 (CST) Received: from wwm1 (unverified [219.82.176.110]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Mon, 18 Oct 2004 22:15:02 +0800 Message-ID: <013101c4b51d$a50761e0$020aa8c0@wwm1> From: "Weiming Wang" To: References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408><002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Mon, 18 Oct 2004 22:20:28 +0800 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, "Joel M. Halpern" , "Steven Blake \(petri-meat\)" , zsolt@nc.rr.com, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Hi Jamal, main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance [Weiming] The more I'm thinking, the more I see the value to address multipul LFB instances here (I can now live with single LFB class). To speak of this, I have an aspire to show my yesterday experience with my GRMP test platform (sorry I have to mention it). As you know, GRMP does not support multipul LFB instance addressing. Yesterday, we had to prepare a show of the platform to guests from our sponsors. Before the show, we spent near one hour to operate on the menu to construct a scenario, in which there were 5 output port, 5 associated schedulers (LFBs), and several other LFBs that have many instances. unfortunately, we faced a problem with one of the machine. Then we had to do it again. At that time, I had a VERY VERY strong desire that batch configuration based on multipul LFB isntance addressing can be used. I can see very simple scheme to include multipul instances here (by ranging, or by enum, or by both). Definitely, I believe this will greatly improve our protocol. I sincerely hope this be considered seriously by gentlemen. Best regards, Weiming | | | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | In other words: Very similar to the way we have it already except the naming has changed and we can target multiple operations and multiple paths in an LFB instance ----- Original Message ----- From: "Jamal Hadi Salim" > > Welcome back Weiming. I have updated the text with the query/response. > The only outstanding issue is 6.7. Please weigh in. > I think we are ready top start making updates. > > cheers, > jamal > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 12:48:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00858 for ; Mon, 18 Oct 2004 12:48:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJas0-0004Ca-SP for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 13:00:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJaRx-0004cr-9d; Mon, 18 Oct 2004 12:33:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJZwH-0000ii-NO for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 12:01:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27428 for ; Mon, 18 Oct 2004 12:00:42 -0400 (EDT) Received: from [204.85.2.226] (helo=mail.modnetinc.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJa8D-0003HY-Gc for forces-protocol@ietf.org; Mon, 18 Oct 2004 12:13:10 -0400 Received: (qmail 25397 invoked by uid 530); 18 Oct 2004 16:00:09 -0000 Received: from zsolt@modularnet.com by proteus-01.proteandevices.com by uid 527 with qmail-scanner-1.16 (clamscan: 0.54. Clear:. Processed in 0.837266 secs); 18 Oct 2004 16:00:09 -0000 Received: from proteus-02.proteandevices.com (HELO ?127.0.0.1?) (192.168.0.202) by 0 with SMTP; 18 Oct 2004 16:00:08 -0000 From: Zsolt Haraszti To: "Steven Blake (petri-meat)" In-Reply-To: <1098113089.2364.12.camel@localhost.localdomain> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-2pae5+tzeOel/qmalusL" Organization: Modular Networks, Inc. Message-Id: <1098115003.2884.67.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 18 Oct 2004 11:56:50 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2f46977da373544777a750d5247d6ccc Cc: "Khosravi, Hormuzd M" , "Joel M. Halpern" , ram.gopal@nokia.com, forces-protocol@ietf.org, "Yang, Lily L" , Jamal Hadi Salim , Alan DeKok , Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: efc5d1db3729b4b7031f1bb5f5a30ae3 --=-2pae5+tzeOel/qmalusL Content-Type: text/plain Content-Transfer-Encoding: 7bit Attached is our proposal for data encoding over the wire for ForCES. This initial description has a blank chapter on ARRAY (table) encoding. We do have a proposal for that but we still need to write it down (hope to do so today), but wanted to air the rest of the proposal ASAP. As always, eager to get bombarded with your comments. Cheers, Zsolt -- Zsolt Haraszti Phone: +1 919-765-0027/2017 Modular Networks Mobile: +1 919-522-2337 Email: zsolt@modularnet.com --=-2pae5+tzeOel/qmalusL Content-Disposition: attachment; filename=forces_data_encoding_1.txt Content-Type: text/plain; name=forces_data_encoding_1.txt; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Z. Haraszti S. Blake Modular Networks, Inc. Proposal for ForCES Data Encoding Version 1.0 1 Scope ======== This document specifies how data is encoded for the wire inside ForCES messages. Data refers to the content of ForCES LFB attributes and their sub-elements, carried in various CONFIG-REQUEST operations (SET/ADD) and QUERY-RESPONSE messages (e.g., response to a GET operation). 2 Desing objectives and assumptions ==================================== - It is assumed that the type of the data can be inferred by the context in which data is used. Hence, data will not include its type information. The basis for the inference is typically the LFB class id and the path. In other cases it may also include a KEY selector. It is imperative that the CE and FE have identical assumptions on the data types. This requires that they both use the same set of LFB class specifications which is a must anyway. - Not only that the type of the data element node must be known to both parties, but in case the node is a complex data type, all its sub-elements' type must also be known to both parties. - Data encoding should be recursive, i.e., it should support encoding of nested data at an arbitrary level. It should not only be possible to encode atomic data types, but also full structs, entire or partial arrays including arrays of structs, structs containing structs and arrays, arrays of arrays, etc., as dictated by the type of the target element. - The encoding and decoding algorithmn should be as simple as possible. Specifically both should be a standard sequential deep-first operation with no look-ahead ever required. - Random sub-element access will not be guaranteed. Specifically, random sub-element access will not be provided when the sub-elements inlcude one or more sub-elements with variable-size encoding (there are ARRAYs and STRING[N]'s. In such cases the receiving side will need to sequentially decode the received binary data block to locate the place and value of a given sub-element. - Decoding and encoding should be friendly to C/C++ implementations, i.e., it should require little or no re-encoding of the data (other than changing endianness). In particular, it should be possible to design C/C++ data structures in the CE/FE code such that their content can be simply block-copied when being transfered via ForCES. This is critical to not to compromize protocol processing speed. - The encoding should be byte-efficient (as compact as sensible). This is to not to compromize bandwidth. - The length of the encoded data block will always be a multiple of 32-bit words. 3 Data Types ============= As a refresher, below we summarize the data types allowed in ForCES (see the Model document for more explanation). Built-in atomic types: - Integers (INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64) - Floats (FLOAT32, FLOAT64) - String (STRING[N], null-terminated string of max length N) - Simple byte aray (BYTES[N], simple byte array of fixed size N with no indexing capabilities) Compound type constructs: ARRAY (also called table): array of identical elements, each associated with a sticky/inmutable index, but index is not part of the entry. STRUCT: ordered sequence of fields, each can be of any data type, including atomic and compound types. Each field is associated with an index, derived from its position inside the STRUCT declaration. [For now, we do not cover UNION and AUGMENTATION types.] Derived types: ForCES allows the derivation of new atomic types from the existing (built-in) atomic types to allow specialization, i.e., via renaming, range restricting, and/or defining keywords for special values. New complex types can be defined using the compound type constructs (ARRAY and STRUCT), building complex data structures from atomic data types or from other complex types. 4 Data Encding =============== The encoding process is defined as DATA = encode(path) where path specifies the data element, element[path], to be encoded. Path specifies the element inside an LFB. Path is a sequence (list) of uint32 values. The first element of path (path[0]) identifies the attribute within the LFB. If the attribute is of ARRAY or STRUCT type, the second element of path (path[1]) specifies the entry of the ARRAY or the field in the STRUCT, respectively. As long as path[k] is a complex type, path[k+1] refers to the respective sub-element inside element[path[k]]. Note that the target element of the operation (element[path]), may itself be an atomic type or a complex type. If it is an atomic type, the atomic type will be encoded. If it is a complex type, than the entire element including all its nested sub-elements will be encoded. Let type = type_of(element[path]) denote the type identifier of the target element. DATA is built as follows: DATA := PACK(type, value) + PADDING where type = type_of(element[path]) value = element[path] PACK(type, value) denotes the result of the binary encoding of value according to the specified type. The encoding is type-dependent; see respective specification for each type below. PADDING := 1, 2 or 3 bytes of 0x00 values to round up the resulting data block to the next 32-bit boundary. 4.1 Atomic type encodings -------------------------- 4.1.1 Encoding of Integer Types If type is one of INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, its encoding is as follows: PACK(type, integer) := 1/2/4/8 bytes of binary data in network byte order (big endian). The number of bytes reflects the length of the type. 0 7 +-+-+-+-+-+-+-+-+ | INT8 / UINT8 | +-+-+-+-+-+-+-+-+ 1 0 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INT16 / UINT16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | INT32 / UINT32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- INT64 / UINT64 -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.2 Encoding of Float Types If type is FLOAT32 or FLOAT64, its encoding is as follows: PACK(type, float) := 4/8 bytes of binary data in network byte order, using IEEE floating point numbers encoding. 3 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FLOAT32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- FLOAT64 -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.3 Encoding of STRING[N] Types If type is STRING[N], its encoding is as follows: PACK(STRING[N], string) := LEN + STRING + PADDING where: LEN := 2 byte string length indicator encoded as uint16 (big endian). Length includes only the consecutive non-zero characters from the start of the string. STRING := Non-zero characters of the string. PADDING := see above. 3 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LEN | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+ | | +- -+ ... STRING + 1/2/3 bytes PADDING ... +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Examples: string = "abcde", N = 16: 00 05 61 62 63 64 65 00 string = "abcde", N = 128: same as above, encoding does not care about max. size of string. string = "" 00 00 00 00 string = "abcdef" 00 06 61 62 63 64 65 66 string = "abcdefg" 00 07 61 62 63 64 65 66 67 00 00 00 4.1.4 Encoding of BYTES[N] Types If type is BYTES[N], its encoding is as follows: PACK(BYTES[N], byte_array) := BYTE_ARRAY + PADDING where: BYTE_ARRAY := is all the N bytes of the byte_array in the same order as stored PADDING := see above 3 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ ... N bytes of BYTE_ARRAY + 1/2/3 bytes PADDING ... +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: Note that the four sub-32-bit integer types (INT8, UINT8, INT16 and UINT16) preserve they sizes in PACK(). All other atomic types are packed to integer multiples of 4-byte words. I.e., even though a BYTE[6] is only 6 bytes long, PACK(BYTE[6], value) will be 8 bytes long. 4.2 Encodind of Compound Types 4.2.1 Struct Encoding Struct encoding is rather straight-forward. For struct with fixed-size content the encoding follows the ANSI C struct representation standards. If type is STRUCT (more precisely a derived type using the STRUCT construct), its content is encoded using the following rules: 1 The encoded STRUCT will always contain the entire content of the STRUCT. This includes all its fields, and all sub-elements of its fields. 2 Each sub-element (field) is pre-packed with its respective PACK operation. 3 PACK-ed sub-elements are placed in the resulting data block strictly in the same order in which the fields are specified in the definition of the STUCT data type. 4 If a field is one of the 8-bit or 16-bit integer types, it is placed in the resulting data block aligned on its natural length. For example, if the STRUCT includes a UINT16 field, the 2 bytes of a PACK(UINT16, int) will start on an even byte offset inside PACK(STRUCT, struct element). 5 PACK-ed fields of 32-bit and larger sub-elements will be 32-bit aligned. 6 If alignment requires padding, 1, 2 or 3 all-zero bytes will be appended to the already encoded block until the required alignment is achieved. 7 More than one sub-32-bit fields may be packed into the same 32-bit word in way that rules 3, 4, 5 and 6 are all satisfied. Example: STRUCT { UINT8 A; INT16 B; INT32 C; INT8 D; BYTES[6] E; INT8 F; INT8 G; INT16 H; STRING[32] I = "abcdef" ARRAY { ... } J; } 3 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A |X X X X X X X X| B | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | D |X X X X X X X X X X X X X X X X X X X X X X X X| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E[0] E[1] E[2] E[3] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | E[4] E[5] |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F | G | H | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- I -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | ... J ... | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2.2 Encoding of Array Types This is the only non-trivial type in terms of encoding. Before presenting the encoding format and rules, let's state some requirements: - Number of elements must be specified in a header - If the type of the entries are not of fixed size, the encoded entries will have variable sizes, so the size of each entry must be provided. - The index of each entry may or may not need to be provided with the data. Both cases must be supported. - Optional field specification ... [TBF] --=-2pae5+tzeOel/qmalusL Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=-2pae5+tzeOel/qmalusL-- From forces-protocol-bounces@ietf.org Mon Oct 18 12:59:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01735 for ; Mon, 18 Oct 2004 12:59:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJb2m-0004R9-N3 for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 13:11:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJaUk-0005OH-GX; Mon, 18 Oct 2004 12:36:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJaGq-0002qj-7Q for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 12:22:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25521 for ; Mon, 18 Oct 2004 11:26:19 -0400 (EDT) Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJZau-0002d1-HR for forces-protocol@ietf.org; Mon, 18 Oct 2004 11:38:46 -0400 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.43) id 1CJZNZ-0006Zw-4h; Mon, 18 Oct 2004 11:24:57 -0400 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Steven Blake To: hadi@znyx.com In-Reply-To: <1098102734.1042.134.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1098113089.2364.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 18 Oct 2004 11:24:49 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Zsolt Haraszti , "Joel M. Halpern" , "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , Weiming Wang X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit On Mon, 2004-10-18 at 08:32, Jamal Hadi Salim wrote: > 6.2 Query Messages > ------------------- > > 6.2.1 Query message > ------------------- > > main hdr (eg type = Query) > | > | > +--- T = LFBselect > | | > | +-- LFBCLASSID = target LFB class > | | > | | > | +-- LFBInstance = target LFB instance > | | > | | > | +-- T = GET > | | | > | | +-- // one or more path targets > | | // under discussion > | | > > The LFB is targeted. So if you need to find a route > from an LPM you target that LFB. If you need to find > neighbors of an FE you target the FE object LFB. > > The response is exactly the same as above with type = Query-response. > > 6.3 Configuration Message > -------------------------- > > 6.3.1 Config request > ---------------------- > > main hdr (eg type = config) > | > | > +--- T = LFBselect > | | > | +-- LFBCLASSID = target LFB class > | | > | | > | +-- LFBInstance = target LFB instance > | | > | | > | +-- T = operation { ADD, DEL, GET, etc} > | | | > | | +-- // one or more path targets > | | // under discussion > | | > | +-- T = operation { ADD, DEL, GET, etc} > | | | > | | +-- // one or more path targets > | | // under discussion > | | > | +-- T = operation { ADD, DEL, GET, etc} > | | | > | | +-- // one or more path targets > | | // under discussion > | | > > In other words: Very similar to the way we have it already except > the naming has changed and we can target multiple > operations and multiple paths in an LFB instance If people agree that the protocol should preclude GET operations in CONFIG_REQUEST messages, and only allow them in QUERY_REQUEST messages, then the latter BNF needs to be edited to remove GET from the operation list. I was assuming that the GET would be encoded as an operation TLV in the QUERY_REQUEST message. Regards, // Steve _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 13:44:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05575 for ; Mon, 18 Oct 2004 13:44:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJbku-0005Oy-SU for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 13:57:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJb7b-0001pO-22; Mon, 18 Oct 2004 13:16:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJDKD-0007ZU-6H for forces-protocol@megatron.ietf.org; Sun, 17 Oct 2004 11:52:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02082 for ; Sun, 17 Oct 2004 11:51:58 -0400 (EDT) Received: from ms-smtp-01-lbl.southeast.rr.com ([24.25.9.100] helo=ms-smtp-01-eri0.southeast.rr.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJDW0-0001n1-Vx for forces-protocol@ietf.org; Sun, 17 Oct 2004 12:04:13 -0400 Received: from [192.168.2.3] (rdu74-167-053.nc.rr.com [24.74.167.53]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id i9HFpoKj017085; Sun, 17 Oct 2004 11:51:50 -0400 (EDT) Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? From: Zsolt Haraszti To: Jamal Hadi Salim In-Reply-To: <1098024636.1049.87.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02E985A6@orsmsx408> <1097900642.19064.13.camel@localhost.localdomain> <1097927770.1043.35.camel@jzny.localdomain> <1097940541.1043.51.camel@jzny.localdomain> <1097984736.2681.210.camel@localhost.localdomain> <1098024636.1049.87.camel@jzny.localdomain> Content-Type: text/plain Message-Id: <1098028107.2681.214.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sun, 17 Oct 2004 11:48:28 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 18 Oct 2004 13:16:33 -0400 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Joel M. Halpern" , Alan DeKok , forces-protocol@ietf.org, "Steven Blake \(petri-meat\)" , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit On Sun, 2004-10-17 at 10:50, Jamal Hadi Salim wrote: > > > > * EV_S (subscribe to an event defined in PATH-DATA } > > > * EV_U (unsubscribe to an event defined in PATH-DATA } > > > > An alternative to EV_S/U would be to model this via special > > LFB attributes, i.e., a ADD-ing/DEL-eting entries in a > > subscription table, modeled as an ARRAY attribute of the > > respective LFB. Then there is no need for a separate > > operations. > > The assumption here is the model team will have events defined as > attributes (on a per LFB basis). > For the same semantical reasons as having a query being a separate type, > I think that the events should be separate operation. This also helps so > that if i am running a sniffer/debuger I could easily tell it is an > event vs other attributes. I was talking about the subscribe/un-subscribe messages. The actual asynchronous event notification should indeed be a separate PL type, as Steve called it out by EVENT. /zsolt _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 14:07:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07703 for ; Mon, 18 Oct 2004 14:07:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJc6U-00060R-7D for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 14:19:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbad-0005zQ-8q; Mon, 18 Oct 2004 13:46:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJbFz-0002vG-DW for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 13:25:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03938 for ; Mon, 18 Oct 2004 13:25:02 -0400 (EDT) Received: from [66.46.215.210] (helo=post.ott.idt.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJbRo-0004zO-5i for forces-protocol@ietf.org; Mon, 18 Oct 2004 13:37:31 -0400 Received: from [127.0.0.1] (dhcp195.ott.idt.com [192.168.102.195]) by post.ott.idt.com (Postfix) with ESMTP id 35B801F0001; Mon, 18 Oct 2004 13:24:30 -0400 (EDT) Message-ID: <4173FB88.1000008@idt.com> Date: Mon, 18 Oct 2004 13:21:12 -0400 From: Alan DeKok User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zsolt Haraszti References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> <1098115003.2884.67.camel@localhost.localdomain> In-Reply-To: <1098115003.2884.67.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , "Joel M. Halpern" , forces-protocol@ietf.org, Jamal Hadi Salim , "Steven Blake \(petri-meat\)" , Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Re: Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: 7bit Zsolt Haraszti wrote: > - It is assumed that the type of the data can be inferred by the > context in which data is used. Hence, data will not include its > type information. It may be useful to also be able to explicitly describe a type, if only for initialization purposes. This ensures that the FE can communicate implementation-specific extensions to the CE, and that the CE can understand them. e.g. "ACL is array[n] of struct {ip, ip, proto, port, port}" These types SHOULD NOT be used outside of initialization, as they will make the protocol complex, and the implementation problematic. > - Random sub-element access will not be guaranteed. Specifically, random > sub-element access will not be provided when the sub-elements inlcude > one or more sub-elements with variable-size encoding (there are ARRAYs > and STRING[N]'s. I would phrase that as "random sub-element access is provided only when all sub-elements are of the same, fixed, size". It means the same, but phrasing it in a positive way means that you're defining what's OK. By definition, then, everything else is not OK, and you don't have to enumerate the infinite weird ways that can't be used for access. > - The length of the encoded data block will always be a multiple of 32-bit > words. ... > PADDING := 1, 2 or 3 bytes of 0x00 values to round up the resulting > data block to the next 32-bit boundary. I would say "0, 1, 2, or 3 bytes..." You've defined "DATA := PACK(type, value) + PADDING", so there should be some provision for PADDING to be zero. > PACK(type, integer) := 1/2/4/8 bytes of binary data in network > byte order (big endian). I would say "network byte order", rather than "big endian". It avoids terminology from "religious wars". > PACK(type, float) := 4/8 bytes of binary data in network byte > order, using IEEE floating point numbers > encoding. I think the reference is "ANSI/IEEE Standard 754-1985" > 4.1.3 Encoding of STRING[N] Types > > If type is STRING[N], its encoding is as follows: > > PACK(STRING[N], string) := LEN + STRING + PADDING Where "+" is "concatenation". > where: > > LEN := 2 byte string length indicator encoded as uint16 > (big endian). Length includes only the consecutive > non-zero characters from the start of the string. Can strings contain embedded NULs? > Examples: > > string = "abcde", N = 16: 00 05 61 62 > 63 64 65 00 > > string = "abcde", N = 128: same as above, encoding does not care > about max. size of string. I'm not sure I see why it is necessary to allow NUL terminated strings which have many, many, NULs at the end. Or, why is "N=128" here? (byte arrays) > Note that the four sub-32-bit integer types (INT8, UINT8, INT16 and UINT16) > preserve they sizes in PACK(). All other atomic types are packed ^^^^ "their" (and other miscellaneous typos) > 4.2.1 Struct Encoding > > Struct encoding is rather straight-forward. For struct with fixed-size > content the encoding follows the ANSI C struct representation > standards. What does that mean? > If type is STRUCT (more precisely a derived type using the STRUCT construct), > its content is encoded using the following rules: ... > 2 Each sub-element (field) is pre-packed with its respective PACK > operation. What does that mean? I think you mean to say something like "the packing of the structure is the simple concatenation of the packing of it's elements". e.g. PACK(struct(foo)) = PACK(foo.element1) + PACK(foo.element2) ... If that's true, then it will be possible to write a function which takes a ForCES STRUCT definition and a pointer to a C structure containing the relevant data, and return a PACKed DATA field. While this process often won't be necessary, it may be useful to give a sample function in pseudo-code, or C, to do this packing. That way people implementing the protocol have a "known good" place to start from. > 4 If a field is one of the 8-bit or 16-bit integer types, it is placed in the > resulting data block aligned on its natural length. For example, > if the STRUCT includes a UINT16 field, the 2 bytes of a PACK(UINT16, int) > will start on an even byte offset inside PACK(STRUCT, struct element). Systems which have difficulties addressing byte-aligned data may not like this style of packing. Aligning everything on 32-bit boundaries may not be efficient, though. > 5 PACK-ed fields of 32-bit and larger sub-elements will be 32-bit > aligned. > > 6 If alignment requires padding, 1, 2 or 3 all-zero bytes will be appended > to the already encoded block until the required alignment is achieved. I would say "zero, one, two, or three bytes of zero will be appended to the encoded block, to align it to a 32-bit boundary". > Example: > > STRUCT { > UINT8 A; > INT16 B; It would be great to have some sample code which read in simple STRUCT definitions, and produced the packed DATA. Having a function to produce ASCII art would be even better... > 4.2.2 Encoding of Array Types > > This is the only non-trivial type in terms of encoding. Before presenting > the encoding format and rules, let's state some requirements: > > - Number of elements must be specified in a header > - If the type of the entries are not of fixed size, the encoded entries > will have variable sizes, so the size of each entry must be provided. Variable-sized entries are severely problematic. Is there a requirement to have arrays of variable sized elements? To me, that sounds more like a big STRUCT. Alan DeKok. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 15:53:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17638 for ; Mon, 18 Oct 2004 15:53:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJdlf-0008Q7-2N for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 16:06:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJd81-0000A8-4p; Mon, 18 Oct 2004 15:25:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJcnj-00005a-Pn for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 15:04:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13192 for ; Mon, 18 Oct 2004 15:04:05 -0400 (EDT) Received: from [204.85.2.226] (helo=mail.modnetinc.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJczh-0007I5-FX for forces-protocol@ietf.org; Mon, 18 Oct 2004 15:16:34 -0400 Received: (qmail 26332 invoked by uid 530); 18 Oct 2004 19:03:32 -0000 Received: from zsolt@modularnet.com by proteus-01.proteandevices.com by uid 527 with qmail-scanner-1.16 (clamscan: 0.54. Clear:. Processed in 0.821301 secs); 18 Oct 2004 19:03:32 -0000 Received: from proteus-02.proteandevices.com (HELO ?127.0.0.1?) (192.168.0.202) by 0 with SMTP; 18 Oct 2004 19:03:31 -0000 From: Zsolt Haraszti To: Alan DeKok In-Reply-To: <4173FB88.1000008@idt.com> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> <1098115003.2884.67.camel@localhost.localdomain> <4173FB88.1000008@idt.com> Content-Type: text/plain Organization: Modular Networks, Inc. Message-Id: <1098126011.2884.162.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 18 Oct 2004 15:00:12 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , "Joel M. Halpern" , forces-protocol@ietf.org, Jamal Hadi Salim , "Steven Blake \(petri-meat\)" , Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Re: Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Content-Transfer-Encoding: 7bit Alan, Thanks for your quick but rather exhaustive comments. See some feedback below. On Mon, 2004-10-18 at 13:21, Alan DeKok wrote: > Zsolt Haraszti wrote: > > > - It is assumed that the type of the data can be inferred by the > > context in which data is used. Hence, data will not include its > > type information. > > It may be useful to also be able to explicitly describe a type, if > only for initialization purposes. This ensures that the FE can > communicate implementation-specific extensions to the CE, and that the > CE can understand them. > > e.g. "ACL is array[n] of struct {ip, ip, proto, port, port}" > > These types SHOULD NOT be used outside of initialization, as they > will make the protocol complex, and the implementation problematic. > I agree that this could be useful. We shall find a way to accommodate this in the protocol somewhere. > > - Random sub-element access will not be guaranteed. Specifically, random > > sub-element access will not be provided when the sub-elements inlcude > > one or more sub-elements with variable-size encoding (there are ARRAYs > > and STRING[N]'s. > > I would phrase that as "random sub-element access is provided only > when all sub-elements are of the same, fixed, size". It means the same, > but phrasing it in a positive way means that you're defining what's OK. > By definition, then, everything else is not OK, and you don't have to > enumerate the infinite weird ways that can't be used for access. > OK > > - The length of the encoded data block will always be a multiple of 32-bit > > words. > > > > ... > > PADDING := 1, 2 or 3 bytes of 0x00 values to round up the resulting > > data block to the next 32-bit boundary. > > I would say "0, 1, 2, or 3 bytes..." > > You've defined "DATA := PACK(type, value) + PADDING", so there should > be some provision for PADDING to be zero. > Right. > > > PACK(type, integer) := 1/2/4/8 bytes of binary data in network > > byte order (big endian). > > I would say "network byte order", rather than "big endian". It > avoids terminology from "religious wars". > OK, we can delete the "(big endian)" > > PACK(type, float) := 4/8 bytes of binary data in network byte > > order, using IEEE floating point numbers > > encoding. > > I think the reference is "ANSI/IEEE Standard 754-1985" > I will check (or let me know when you know for sure :). > > > 4.1.3 Encoding of STRING[N] Types > > > > If type is STRING[N], its encoding is as follows: > > > > PACK(STRING[N], string) := LEN + STRING + PADDING > > Where "+" is "concatenation". > That's right. > > where: > > > > LEN := 2 byte string length indicator encoded as uint16 > > (big endian). Length includes only the consecutive > > non-zero characters from the start of the string. > > Can strings contain embedded NULs? > My suggestion would be to follow C string conventions. So the first NUL and anything after it is ignored. And naturally, only the initial non-NUL content is carried over the wire in ForCES messages. > > > Examples: > > > > string = "abcde", N = 16: 00 05 61 62 > > 63 64 65 00 > > > > string = "abcde", N = 128: same as above, encoding does not care > > about max. size of string. > > I'm not sure I see why it is necessary to allow NUL terminated > strings which have many, many, NULs at the end. Or, why is "N=128" here? > There may some misunderstanding here, so let me rewind a bit. N in STRING[N] defines that max size of the string _in the model_. This is analogous to the char if_name[16] C construct (as opposed to the char *if_name). What the above two examples illustrate is that max size N does not really matter when sending the content over the wire (the content still must be smaller then N), because the string encoding will only transfer the useful part of the string, i.e., everything till the terminating '\0'. If people have problem with this we can define alternative string model(s), but I thought this is sufficient. > (byte arrays) > > Note that the four sub-32-bit integer types (INT8, UINT8, INT16 and UINT16) > > preserve they sizes in PACK(). All other atomic types are packed > ^^^^ > "their" (and other miscellaneous typos) > > > > > 4.2.1 Struct Encoding > > > > Struct encoding is rather straight-forward. For struct with fixed-size > > content the encoding follows the ANSI C struct representation > > standards. > > What does that mean? > I hoped this should be clear from the rest of the text, but apparently not. Let me try to clarify it a bit: Suppose you define a STRUCT A data type per ForCES data model. Suppose furthermore that you implement that struct in the FE/CE software by means of a C struct: struct A. The C struct will have a certain memory layout in the host memory. That layout is what I referred to as "ANSI C struct representation" (I may have used the wrong reference here; I shall look it up to be sure). The statement above is that for structs which do not have variable size fields, the ForCES encoded STRUCT will have the same layout as the C struct in memory (minus endianness). The obvious advantage of this is that you can memcpy() between the message buffer and you C struct. > > If type is STRUCT (more precisely a derived type using the STRUCT construct), > > its content is encoded using the following rules: > ... > > 2 Each sub-element (field) is pre-packed with its respective PACK > > operation. > > What does that mean? > > I think you mean to say something like "the packing of the structure > is the simple concatenation of the packing of it's elements". > > e.g. > > PACK(struct(foo)) = PACK(foo.element1) + PACK(foo.element2) ... Almost, but not quite. Since we want to make this layout compatible with C implementations, we need to include padding between some of the elements. The stated alignment rules serve this purpose. The formula would be more precise if stated like this: PACK(STRUCT, foo) = PACK(..., foo.field1) + PADDING1 + PACK(..., foo.field2) + PADDING2 + ... where PADDINGn is k = 0, 1, 2, or 3 bytes of bytes, where k is chosen to make the next sub-element be positioned at its required alignment. I believe the provided example illustrates the rules well. > > If that's true, then it will be possible to write a function which > takes a ForCES STRUCT definition and a pointer to a C structure > containing the relevant data, and return a PACKed DATA field. While > this process often won't be necessary, it may be useful to give a sample > function in pseudo-code, or C, to do this packing. That way people > implementing the protocol have a "known good" place to start from. Are you suggesting putting a pseudo-code into the description here or into the final standard (or both)? > > > 4 If a field is one of the 8-bit or 16-bit integer types, it is placed in the > > resulting data block aligned on its natural length. For example, > > if the STRUCT includes a UINT16 field, the 2 bytes of a PACK(UINT16, int) > > will start on an even byte offset inside PACK(STRUCT, struct element). > > Systems which have difficulties addressing byte-aligned data may not > like this style of packing. Aligning everything on 32-bit boundaries > may not be efficient, though. One extreme would be to densely pack, not caring with alignments at all. The other would be to align everything on 32-bit boundaries, and align the 64-bit float and int types on 64-bit. A sweet spot is to align 32-bit or larger items on 32-bit, and smaller items on their own size. This follows the alignment rules of C structs, which should be a huge merit. > > > 5 PACK-ed fields of 32-bit and larger sub-elements will be 32-bit > > aligned. > > > > 6 If alignment requires padding, 1, 2 or 3 all-zero bytes will be appended > > to the already encoded block until the required alignment is achieved. > > I would say "zero, one, two, or three bytes of zero will be appended > to the encoded block, to align it to a 32-bit boundary". > Again, not always 32-bit. A uint16 or int16 will be aligned to the next 16-bit boundary. > > Example: > > > > STRUCT { > > UINT8 A; > > INT16 B; > > It would be great to have some sample code which read in simple > STRUCT definitions, and produced the packed DATA. Having a function to > produce ASCII art would be even better... You mean "STRUCT definition and actual value, and produced the packed DATA"? ^^^^^^^^^^^^^^^^ We can have a contest on who could post that program first. Input: a) an the XML data specification per current ForCES model document b) value assignment for the fields Output: an ASCII art showing the packet data. > > 4.2.2 Encoding of Array Types > > > > This is the only non-trivial type in terms of encoding. Before presenting > > the encoding format and rules, let's state some requirements: > > > > - Number of elements must be specified in a header > > - If the type of the entries are not of fixed size, the encoded entries > > will have variable sizes, so the size of each entry must be provided. > > Variable-sized entries are severely problematic. > I agree that they are more trouble-some. But I find it too restrictive to prohibit them. Arrays of arrays will have this. Or, if your array is based on a struct that has string field(s), will have this problem. This is one of those places where I would think good designs will avoid such ARRAYs as much as possible, but in some cases it cannot be avoided so we must support it in the protocol. /zsolt > Is there a requirement to have arrays of variable sized elements? To > me, that sounds more like a big STRUCT. > > Alan DeKok. -- Zsolt Haraszti Phone: +1 919-765-0027/2017 Modular Networks Mobile: +1 919-522-2337 Email: zsolt@modularnet.com _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 15:56:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17838 for ; Mon, 18 Oct 2004 15:56:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJdo4-0008Tx-I5 for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 16:08:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJdNL-0003Or-0J; Mon, 18 Oct 2004 15:40:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJd3Y-0006WN-4x for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 15:20:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15283 for ; Mon, 18 Oct 2004 15:20:25 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJdFE-0007dL-6W for forces-protocol@ietf.org; Mon, 18 Oct 2004 15:32:54 -0400 Received: from JLaptop.megisto.com ([192.168.20.163]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Oct 2004 15:19:47 -0400 Message-Id: <5.1.0.14.0.20041018151520.03591698@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Oct 2004 15:19:43 -0400 To: Zsolt Haraszti , Alan DeKok From: "Joel M. Halpern" In-Reply-To: <1098126011.2884.162.camel@localhost.localdomain> References: <4173FB88.1000008@idt.com> <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> <1098115003.2884.67.camel@localhost.localdomain> <4173FB88.1000008@idt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Oct 2004 19:19:47.0638 (UTC) FILETIME=[6E9E2560:01C4B547] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, "Yang, Lily L" , Jamal Hadi Salim , "Steven Blake \(petri-meat\)" , Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Re: Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Note that an array of structs, where the struct itself contains an array (or an array of arrays, which is our equivalent of a two dimensional array) is an array with variable sized components. Note that with the encoding defined, if an array starts with its array count one can parse the array sequentially and find all the boundaries even if the elements are variable length. The inner length (which I may have suggested) just makes decomposition much cleaner. I did find one aspect of the description confusing, but technically correct. The packing of 8 and 16 bit integers is defined without packing. You do this so you can use that encoding in the building of structs. However, the encoding of single 8 or 16 bit integers will require padding. (And likely, an array of 8 bit integers should probably be padded so that iterative array processing is clean. (After all, we have STRING and BYTES for the common packed cases. Yours, Joel M. Halpern At 03:00 PM 10/18/2004 -0400, Zsolt Haraszti wrote: > > > 4.2.2 Encoding of Array Types > > > > > > This is the only non-trivial type in terms of encoding. Before > presenting > > > the encoding format and rules, let's state some requirements: > > > > > > - Number of elements must be specified in a header > > > - If the type of the entries are not of fixed size, the encoded entries > > > will have variable sizes, so the size of each entry must be provided. > > > > Variable-sized entries are severely problematic. > > >I agree that they are more trouble-some. But I find it too restrictive >to prohibit them. Arrays of arrays will have this. Or, if your array >is based on a struct that has string field(s), will have this problem. > >This is one of those places where I would think good designs will avoid >such ARRAYs as much as possible, but in some cases it cannot be avoided >so we must support it in the protocol. > >/zsolt _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 16:22:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19903 for ; Mon, 18 Oct 2004 16:22:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJeE1-0000fI-Bx for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 16:35:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJdd1-0006x6-G2; Mon, 18 Oct 2004 15:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJdW3-0004oG-AB for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 15:49:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17459 for ; Mon, 18 Oct 2004 15:49:52 -0400 (EDT) Received: from [66.46.215.210] (helo=post.ott.idt.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJdhy-0008Ls-TE for forces-protocol@ietf.org; Mon, 18 Oct 2004 16:02:21 -0400 Received: from [127.0.0.1] (dhcp195.ott.idt.com [192.168.102.195]) by post.ott.idt.com (Postfix) with ESMTP id A9A7D1F0001; Mon, 18 Oct 2004 15:49:18 -0400 (EDT) Message-ID: <41741D78.4070205@idt.com> Date: Mon, 18 Oct 2004 15:46:00 -0400 From: Alan DeKok User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zsolt Haraszti References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> <1098115003.2884.67.camel@localhost.localdomain> <4173FB88.1000008@idt.com> <1098126011.2884.162.camel@localhost.localdomain> In-Reply-To: <1098126011.2884.162.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , "Joel M. Halpern" , forces-protocol@ietf.org, Jamal Hadi Salim , "Steven Blake \(petri-meat\)" , Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Re: Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Zsolt Haraszti wrote: >> I think the reference is "ANSI/IEEE Standard 754-1985" > > I will check (or let me know when you know for sure :). http://grouper.ieee.org/groups/754/ http://stevehollasch.com/cgindex/coding/ieeefloat.html Yup. > There may some misunderstanding here, so let me rewind a bit. > > N in STRING[N] defines that max size of the string _in the model_. > This is analogous to the > > char if_name[16] > > C construct (as opposed to the char *if_name). Ah, OK. Having the protocol avoid the zeros is nice, but it means that many structs are now packed to variable-sized data. > Let me try to clarify it a bit: Suppose you define a STRUCT A data type > per ForCES data model. Suppose furthermore that you implement that > struct in the FE/CE software by means of a C struct: struct A. The C > struct will have a certain memory layout in the host memory. That > layout is what I referred to as "ANSI C struct representation" (I may > have used the wrong reference here; I shall look it up to be sure). The problem is that ANSI C struct representation is platform-specific. Some platforms can pack multiple 'uint8_t' into a 32-bit word. Others can't. As an extreme example (not applicable here), big/little-endian systems pack bit arrays differently. So I wouldn't depend on anything other than order, and maybe 32-bit alignment, for platform-independent C structs. This makes mapping ForCES protocol packed data into C structs somewhat problematic. > The statement above is that for structs which do not have variable > size fields, the ForCES encoded STRUCT will have the same layout as > the C struct in memory (minus endianness). The obvious advantage of > this is that you can memcpy() between the message buffer and you > C struct. I would suggest adding a note that implementors are STRONGLY CAUTIONED to validate that the sizes of the structs are the same, and that the padding is the same between ForCES and the C compiler. This kind of "memcpy" of complex structures has historically been open to implementation flaws and security attacks. > Almost, but not quite. Since we want to make this layout compatible > with C implementations, we need to include padding between some of the > elements. The stated alignment rules serve this purpose. OK. It's just that if you have variable rules for padding, the PACK function can't really be recursive, as it varies depending on whether or not it's in a struct, or not. > I believe the provided example illustrates the rules well. Yes. >> If that's true, then it will be possible to write a function which >>takes a ForCES STRUCT definition and a pointer to a C structure >>containing the relevant data, and return a PACKed DATA field. While >>this process often won't be necessary, it may be useful to give a sample >>function in pseudo-code, or C, to do this packing. That way people >>implementing the protocol have a "known good" place to start from. > > Are you suggesting putting a pseudo-code into the description > here or into the final standard (or both)? Yes. Code will clarify a LOT of issues. >> It would be great to have some sample code which read in simple >>STRUCT definitions, and produced the packed DATA. Having a function to >>produce ASCII art would be even better... > > > You mean "STRUCT definition and actual value, and produced the packed > DATA"? ^^^^^^^^^^^^^^^^ Sure. > We can have a contest on who could post that program first. > Input: a) an the XML data specification per current ForCES model > document > b) value assignment for the fields > Output: an ASCII art showing the packet data. Hmm... I don't know if I'll have time. But it would be extremely useful, even for other RFC's containing ASCII art. >> Variable-sized entries are severely problematic. > > I agree that they are more trouble-some. But I find it too restrictive > to prohibit them. Arrays of arrays will have this. Or, if your array > is based on a struct that has string field(s), will have this problem. How about having a packed length for structures? That is, reserve a 32-bit word at the start of the struct for it's length, PACK the struct, and then update the length field with the resulting value. For structs of variable size, this should make it easy to quickly find the N'th element in an array of those structs. The clearest benefit is that you don't have to parse or even know the entries of the struct, in order to find the N'th element. > This is one of those places where I would think good designs will avoid > such ARRAYs as much as possible, but in some cases it cannot be avoided > so we must support it in the protocol. I agree. I would, however, like to see the difference between fixed-size structs && variable-size structs highlighted. The problem is that if a data structure has a sub-structure *anywhere* in it which contains a STRING[N], then the entire data structure is "tainted", and it's size is variable instead of fixed. If we expect that most STRUCTs will contain STRING[N], then it may be reasonable to assume that ALL STRUCT packing includes a 32-bit prefix of the size of the struct, as this will decrease the complexity of the parser. If STRING[N] is the only variable-sized data type in the protocol, then it may be reasonable instead to separate the string packing from the struct packing. i.e. Rather than packing the string in place, pack all of the strings together, and pack a "pointer" in the struct to the string. I'm not sure I like that idea, though, as packing will require multiple passes to get all of the cross-references correct. Alan DeKok. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 16:31:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20503 for ; Mon, 18 Oct 2004 16:31:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJeMR-0000qe-V6 for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 16:44:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJdsn-0001kq-Ov; Mon, 18 Oct 2004 16:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJdb5-0006GF-7m for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 15:55:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17771 for ; Mon, 18 Oct 2004 15:55:04 -0400 (EDT) Received: from [204.85.2.226] (helo=mail.modnetinc.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJdn4-0008RN-0M for forces-protocol@ietf.org; Mon, 18 Oct 2004 16:07:34 -0400 Received: (qmail 26550 invoked by uid 530); 18 Oct 2004 19:54:35 -0000 Received: from zsolt@modularnet.com by proteus-01.proteandevices.com by uid 527 with qmail-scanner-1.16 (clamscan: 0.54. Clear:. Processed in 0.82695 secs); 18 Oct 2004 19:54:35 -0000 Received: from proteus-02.proteandevices.com (HELO ?127.0.0.1?) (192.168.0.202) by 0 with SMTP; 18 Oct 2004 19:54:34 -0000 From: Zsolt Haraszti To: "Joel M. Halpern" In-Reply-To: <5.1.0.14.0.20041018151520.03591698@mail.megisto.com> References: <4173FB88.1000008@idt.com> <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> <1098115003.2884.67.camel@localhost.localdomain> <4173FB88.1000008@idt.com> <5.1.0.14.0.20041018151520.03591698@mail.megisto.com> Content-Type: text/plain Organization: Modular Networks, Inc. Message-Id: <1098129074.2884.195.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 18 Oct 2004 15:51:15 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, Jamal Hadi Salim , Alan DeKok , Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Re: Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit On Mon, 2004-10-18 at 15:19, Joel M. Halpern wrote: > Note that an array of structs, where the struct itself contains an array > (or an array of arrays, which is our equivalent of a two dimensional array) > is an array with variable sized components. Precisely. > > Note that with the encoding defined, if an array starts with its array > count one can parse the array sequentially and find all the boundaries even > if the elements are variable length. Yes, ineed. > The inner length (which I may have > suggested) just makes decomposition much cleaner. > Well, we have pondered on this too. Three pieces of info will be needed to decode an array (and things that may come after the array): the total size of the array, the size of each entry, and the number of entries. Since there is a redundancy in the triplet, you don't need to explicitly encode all these. Entry size is needed if the entries have variable size, so we must include this in the encoding, though (as will be described in the text that we are working on) this info can be omitted in cases where the size can be inferred from the type (means fixed type). Total size and number of entries are redundant info. Total size helps quickly skipping the array (or passing the array block in its entirety to a decoder), number of entries are useful if your implementation needs to reserve memory. We picked the latter, but the former would work too. We can also do both, but that will make the ARRAY header bigger. > > I did find one aspect of the description confusing, but technically > correct. The packing of 8 and 16 bit integers is defined without > packing. You do this so you can use that encoding in the building of > structs. Yes, indeed. > However, the encoding of single 8 or 16 bit integers will require > padding. Yes, but this is handled at the higher level in the current description: If the int8 is all your data, then the top-level definition will pad it to 32-bit. If int8 is part of the struct, then padding entirely depends on what is before and what comes after this field in the struct. > (And likely, an array of 8 bit integers should probably be padded > so that iterative array processing is clean. Well, the proposal will allow tight packing of 8- and 16-bit integers, i.e., with no padding. This is for two reasons: 1. Byte efficiency over the wire 2. Encoding efficiency. When you have an array of the form: typedef uint8 dscp_map_table[64]; then a tight-packed encoding allows you to memcpy() the table when sending it over the wire. > (After all, we have STRING > and BYTES for the common packed cases. Keep in mind that although BYTES can provide a simple mechanism to define int8/uint8 tables, it does not provide the same semantics as ARRAY. Specifically it does not allow access to individual entries. BYTES[N] are really good for things like MAC address (BYTE[6] mac_address) and IPv6 address (BYTE[16] ipv6_address), or for very small tables where you don't want to mess with indexing. In addition, it does not cater for uint16/int16 arrays. /zsolt > > Yours, > Joel M. Halpern > > At 03:00 PM 10/18/2004 -0400, Zsolt Haraszti wrote: > > > > 4.2.2 Encoding of Array Types > > > > > > > > This is the only non-trivial type in terms of encoding. Before > > presenting > > > > the encoding format and rules, let's state some requirements: > > > > > > > > - Number of elements must be specified in a header > > > > - If the type of the entries are not of fixed size, the encoded entries > > > > will have variable sizes, so the size of each entry must be provided. > > > > > > Variable-sized entries are severely problematic. > > > > >I agree that they are more trouble-some. But I find it too restrictive > >to prohibit them. Arrays of arrays will have this. Or, if your array > >is based on a struct that has string field(s), will have this problem. > > > >This is one of those places where I would think good designs will avoid > >such ARRAYs as much as possible, but in some cases it cannot be avoided > >so we must support it in the protocol. > > > >/zsolt -- Zsolt Haraszti Phone: +1 919-765-0027/2017 Modular Networks Mobile: +1 919-522-2337 Email: zsolt@modularnet.com _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 17:33:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25460 for ; Mon, 18 Oct 2004 17:33:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJfKP-00025V-7B for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 17:46:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJeva-00060o-N1; Mon, 18 Oct 2004 17:20:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJeRd-0000VI-LQ for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 16:49:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21816 for ; Mon, 18 Oct 2004 16:49:22 -0400 (EDT) Received: from [204.85.2.226] (helo=mail.modnetinc.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJedY-0001Dl-MD for forces-protocol@ietf.org; Mon, 18 Oct 2004 17:01:52 -0400 Received: (qmail 27905 invoked by uid 530); 18 Oct 2004 20:48:49 -0000 Received: from zsolt@modularnet.com by proteus-01.proteandevices.com by uid 527 with qmail-scanner-1.16 (clamscan: 0.54. Clear:. Processed in 0.825734 secs); 18 Oct 2004 20:48:49 -0000 Received: from proteus-02.proteandevices.com (HELO ?127.0.0.1?) (192.168.0.202) by 0 with SMTP; 18 Oct 2004 20:48:48 -0000 From: Zsolt Haraszti To: Alan DeKok In-Reply-To: <41741D78.4070205@idt.com> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> <1098115003.2884.67.camel@localhost.localdomain> <4173FB88.1000008@idt.com> <1098126011.2884.162.camel@localhost.localdomain> <41741D78.4070205@idt.com> Content-Type: multipart/mixed; boundary="=-t30yS+NtIezQsS922zSN" Organization: Modular Networks, Inc. Message-Id: <1098132328.2884.250.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 18 Oct 2004 16:45:28 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , "Joel M. Halpern" , forces-protocol@ietf.org, Jamal Hadi Salim , "Steven Blake \(petri-meat\)" , Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Re: Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 --=-t30yS+NtIezQsS922zSN Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2004-10-18 at 15:46, Alan DeKok wrote: > Zsolt Haraszti wrote: > > >> I think the reference is "ANSI/IEEE Standard 754-1985" > > > > I will check (or let me know when you know for sure :). > > http://grouper.ieee.org/groups/754/ > > http://stevehollasch.com/cgindex/coding/ieeefloat.html > Thanks. > Yup. > > > There may some misunderstanding here, so let me rewind a bit. > > > > N in STRING[N] defines that max size of the string _in the model_. > > This is analogous to the > > > > char if_name[16] > > > > C construct (as opposed to the char *if_name). > > Ah, OK. Having the protocol avoid the zeros is nice, but it means > that many structs are now packed to variable-sized data. > Yes, its a trade-off. You can use BYTES[N] instead of a STRING[N] and then the full buffer will always be sent. You sacrifice bandwidth, but you have fixed-size. I can see value in both. > > Let me try to clarify it a bit: Suppose you define a STRUCT A data type > > per ForCES data model. Suppose furthermore that you implement that > > struct in the FE/CE software by means of a C struct: struct A. The C > > struct will have a certain memory layout in the host memory. That > > layout is what I referred to as "ANSI C struct representation" (I may > > have used the wrong reference here; I shall look it up to be sure). > > The problem is that ANSI C struct representation is > platform-specific. Some platforms can pack multiple 'uint8_t' into a > 32-bit word. Others can't. > Can you give me an example of a platform where it is not done? > As an extreme example (not applicable here), big/little-endian > systems pack bit arrays differently. Actually, I checked the same simple C test code both on my Intel and PowerPC hosts, and found that the layout was the same on both, albeit the bytes ordering _inside_ 32-bit and 16-bit integer fields were naturally the opposite. Take, for example the following struct definition and field values: struct t_t { char a; int b; char c; short d; } t = { 0x11, 0x22334455, 0x66, 0x7788 }; Here is what the memory layout looks like on an Intel P and PowerPC. In both cases I reset the memory with 0's so that the padding is obvious. Intel: PowerPC: ------------ -------------- 11000000 11000000 55443322 22334455 66008877 66007788 Total length: 12 bytes Total length: 12 bytes I would be happy to see the result of this test program on other architectures (I attached the C source file). > So I wouldn't depend on anything > other than order, and maybe 32-bit alignment, for platform-independent C > structs. This makes mapping ForCES protocol packed data into C structs > somewhat problematic. > OK, lets say I was wrong, and the memory layout is (very) platform-specific. E.g., 64-bit platforms do it differently than others. That means we cannot come up with a layout that pleases everyone (every platform). What shall we do then? One approach is to screw everyone, but make it a clean design. E.g., no alignment at all, i.e., only 8-bit alignment. Another approach is to try to be nice to pre-dominant platforms, and feel sorry for the rest. > > The statement above is that for structs which do not have variable > > size fields, the ForCES encoded STRUCT will have the same layout as > > the C struct in memory (minus endianness). The obvious advantage of > > this is that you can memcpy() between the message buffer and you > > C struct. > > I would suggest adding a note that implementors are STRONGLY > CAUTIONED to validate that the sizes of the structs are the same, and > that the padding is the same between ForCES and the C compiler. This > kind of "memcpy" of complex structures has historically been open to > implementation flaws and security attacks. > Sure. > > Almost, but not quite. Since we want to make this layout compatible > > with C implementations, we need to include padding between some of the > > elements. The stated alignment rules serve this purpose. > > OK. It's just that if you have variable rules for padding, the PACK > function can't really be recursive, as it varies depending on whether or > not it's in a struct, or not. > That is why padding is defined at level[n+1] and not at level[n]. At level[n] you pack your data as its own type dictates. If it is uint8, it will be a byte, if it is uint32, it will be 4 bytes. Then at level[n+1] it will be determined if and how much additional padding is required. > > I believe the provided example illustrates the rules well. > > Yes. > > >> If that's true, then it will be possible to write a function which > >>takes a ForCES STRUCT definition and a pointer to a C structure > >>containing the relevant data, and return a PACKed DATA field. While > >>this process often won't be necessary, it may be useful to give a sample > >>function in pseudo-code, or C, to do this packing. That way people > >>implementing the protocol have a "known good" place to start from. > > > > Are you suggesting putting a pseudo-code into the description > > here or into the final standard (or both)? > > Yes. Code will clarify a LOT of issues. > > >> It would be great to have some sample code which read in simple > >>STRUCT definitions, and produced the packed DATA. Having a function to > >>produce ASCII art would be even better... > > > > > > You mean "STRUCT definition and actual value, and produced the packed > > DATA"? ^^^^^^^^^^^^^^^^ > > Sure. > > > We can have a contest on who could post that program first. > > Input: a) an the XML data specification per current ForCES model > > document > > b) value assignment for the fields > > Output: an ASCII art showing the packet data. > > Hmm... I don't know if I'll have time. But it would be extremely > useful, even for other RFC's containing ASCII art. > > >> Variable-sized entries are severely problematic. > > > > I agree that they are more trouble-some. But I find it too restrictive > > to prohibit them. Arrays of arrays will have this. Or, if your array > > is based on a struct that has string field(s), will have this problem. > > How about having a packed length for structures? That is, reserve a > 32-bit word at the start of the struct for it's length, PACK the struct, > and then update the length field with the resulting value. > > For structs of variable size, this should make it easy to quickly > find the N'th element in an array of those structs. The clearest > benefit is that you don't have to parse or even know the entries of the > struct, in order to find the N'th element. > This is another trade-off issue. You are absolutely right, inserting the size info in front of each struct can be very useful, especially if it is a variable size struct. We will have this in ARRAYs, not part of the struct itself, but part of the ARRAY encoding. That does not help when the STRUCT is embedded in another struct though. > > This is one of those places where I would think good designs will avoid > > such ARRAYs as much as possible, but in some cases it cannot be avoided > > so we must support it in the protocol. > > I agree. I would, however, like to see the difference between > fixed-size structs && variable-size structs highlighted. > > The problem is that if a data structure has a sub-structure > *anywhere* in it which contains a STRING[N], then the entire data > structure is "tainted", and it's size is variable instead of fixed. > Yes, that's right. > If we expect that most STRUCTs will contain STRING[N], then it may be > reasonable to assume that ALL STRUCT packing includes a 32-bit prefix of > the size of the struct, as this will decrease the complexity of the parser. > My hunch is that we will see STRING[N] more in "informational" attributes that are read infrequently (e.g., name of interfaces), and see STRING[N] very infrequently in data that will be touched upon at high frequencies (e.g., classifier table entries, FIB, etc.). > > If STRING[N] is the only variable-sized data type in the protocol, > then it may be reasonable instead to separate the string packing from > the struct packing. i.e. Rather than packing the string in place, pack > all of the strings together, and pack a "pointer" in the struct to the > string. > It's not the only. ARRAY in ARRAY is a more important one. > I'm not sure I like that idea, though, as packing will require > multiple passes to get all of the cross-references correct. > Yeah, we thought about that venue too, but rejected it for the same reason. > Alan DeKok. -- Zsolt Haraszti Phone: +1 919-765-0027/2017 Modular Networks Mobile: +1 919-522-2337 Email: zsolt@modularnet.com --=-t30yS+NtIezQsS922zSN Content-Disposition: attachment; filename=pack_test.c Content-Type: text/x-csrc; name=pack_test.c; charset=iso-8859-15 Content-Transfer-Encoding: 7bit #include struct t_t { char a; int b; char c; short d; } t; main() { int i; // Reset struct with pattern: bzero((void*)&t, sizeof(t)); // Fill up struct with values: t.a = 0x11; t.b = 0x22334455; t.c = 0x66; t.d = 0x7788; // Print content of struct byte-by-byte: for (i=0; i; Mon, 18 Oct 2004 17:44:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJfUk-0002K9-I8 for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 17:57:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJewB-0006DT-Fd; Mon, 18 Oct 2004 17:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJeay-00022P-G3 for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 16:59:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22779 for ; Mon, 18 Oct 2004 16:59:00 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJemf-0001Oc-4W for forces-protocol@ietf.org; Mon, 18 Oct 2004 17:11:31 -0400 Received: from JLaptop.megisto.com ([192.168.20.163]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Oct 2004 16:58:22 -0400 Message-Id: <5.1.0.14.0.20041018165715.03523890@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Oct 2004 16:58:18 -0400 To: Zsolt Haraszti , Alan DeKok From: "Joel M. Halpern" In-Reply-To: <1098132328.2884.250.camel@localhost.localdomain> References: <41741D78.4070205@idt.com> <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> <1098115003.2884.67.camel@localhost.localdomain> <4173FB88.1000008@idt.com> <1098126011.2884.162.camel@localhost.localdomain> <41741D78.4070205@idt.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Oct 2004 20:58:22.0188 (UTC) FILETIME=[33F6DAC0:01C4B555] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, "Yang, Lily L" , Jamal Hadi Salim , "Steven Blake \(petri-meat\)" , Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Re: Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Why not just declare that structs start with their length. Then we can declare that an array consists of its element count (or length and element count) followed by the representation of its contents. [Ignoring for the moment the issue of dense vs sparse packing, subscript representation, etc.] Yours, Joel At 04:45 PM 10/18/2004 -0400, Zsolt Haraszti wrote: >This is another trade-off issue. You are absolutely right, inserting >the size info in front of each struct can be very useful, especially if >it is a variable size struct. We will have this in ARRAYs, not >part of the struct itself, but part of the ARRAY encoding. >That does not help when the STRUCT is embedded in another struct though. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 17:50:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27213 for ; Mon, 18 Oct 2004 17:50:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJfae-0002V8-0G for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 18:02:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJeww-0006UB-Mi; Mon, 18 Oct 2004 17:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJelQ-0004Ix-2A for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 17:09:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23406 for ; Mon, 18 Oct 2004 17:09:48 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJexO-0001ac-9B for forces-protocol@ietf.org; Mon, 18 Oct 2004 17:22:19 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101814121905:32283 ; Mon, 18 Oct 2004 14:12:19 -0700 From: Jamal Hadi Salim To: "Joel M. Halpern" In-Reply-To: <5.1.0.14.0.20041018165715.03523890@mail.megisto.com> References: <41741D78.4070205@idt.com> <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> <1098115003.2884.67.camel@localhost.localdomain> <4173FB88.1000008@idt.com> <1098126011.2884.162.camel@localhost.localdomain> <41741D78.4070205@idt.com> <5.1.0.14.0.20041018165715.03523890@mail.megisto.com> Organization: Znyx Networks Message-Id: <1098133781.1075.437.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Oct 2004 17:09:41 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/18/2004 02:12:19 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/18/2004 02:12:24 PM, Serialize complete at 10/18/2004 02:12:24 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , "Yang, Lily L" , Zsolt Haraszti , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Re: Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit I guess i am gonna have to mention what i refered to as the ugly scheme we use after all ;-> Beside it being ugly it _works_ regardless of wheterh you have tables of tables of tables and you wanted to reference that 10th index 3rd element;-> Every thing is a TLV. The T is the ID as provided by the XML doc. The disadvantage is clearly the abuse of bits. You could play tricks to improve this of course. The advantage is that this is a well know interface. You could go one step and say TLVs would only apply for variable sized items only; which means any struct will have to have _atomic_ attributes first then variable sized at the end of it. cheers, jamal On Mon, 2004-10-18 at 16:58, Joel M. Halpern wrote: > Why not just declare that structs start with their length. Then we can > declare that an array consists of its element count (or length and element > count) followed by the representation of its contents. [Ignoring for the > moment the issue of dense vs sparse packing, subscript representation, etc.] > > Yours, > Joel > > At 04:45 PM 10/18/2004 -0400, Zsolt Haraszti wrote: > >This is another trade-off issue. You are absolutely right, inserting > >the size info in front of each struct can be very useful, especially if > >it is a variable size struct. We will have this in ARRAYs, not > >part of the struct itself, but part of the ARRAY encoding. > >That does not help when the STRUCT is embedded in another struct though. > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 17:55:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27849 for ; Mon, 18 Oct 2004 17:55:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJfg1-0002hR-J3 for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 18:08:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJexI-0006eW-Rr; Mon, 18 Oct 2004 17:22:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJenH-0004g9-HR for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 17:11:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23537 for ; Mon, 18 Oct 2004 17:11:44 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJezG-0001cR-RU for forces-protocol@ietf.org; Mon, 18 Oct 2004 17:24:15 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101814141831:32285 ; Mon, 18 Oct 2004 14:14:18 -0700 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: Steve Blake In-Reply-To: <1098113089.2364.12.camel@localhost.localdomain> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> Organization: Znyx Networks Message-Id: <1098133900.1074.442.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Oct 2004 17:11:41 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/18/2004 02:14:18 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/18/2004 02:14:20 PM, Serialize complete at 10/18/2004 02:14:20 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Zsolt Haraszti , Weiming Wang , "Joel M. Halpern" , forces-protocol@ietf.org, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Mon, 2004-10-18 at 11:24, Steven Blake wrote: [..] > > | +-- T = operation { ADD, DEL, GET, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > | +-- T = operation { ADD, DEL, GET, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > > > In other words: Very similar to the way we have it already except > > the naming has changed and we can target multiple > > operations and multiple paths in an LFB instance > > If people agree that the protocol should preclude GET operations in > CONFIG_REQUEST messages, and only allow them in QUERY_REQUEST messages, > then the latter BNF needs to be edited to remove GET from the operation > list. I was assuming that the GET would be encoded as an operation TLV > in the QUERY_REQUEST message. > Fixed. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 17:56:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27927 for ; Mon, 18 Oct 2004 17:56:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJfgq-0002ib-OV for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 18:09:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJf0K-00073w-Gm; Mon, 18 Oct 2004 17:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJeps-00054b-Ci for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 17:14:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23756 for ; Mon, 18 Oct 2004 17:14:25 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJf1r-0001gR-AU for forces-protocol@ietf.org; Mon, 18 Oct 2004 17:26:55 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101814165810:32292 ; Mon, 18 Oct 2004 14:16:58 -0700 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: Weiming Wang In-Reply-To: <013101c4b51d$a50761e0$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> Organization: Znyx Networks Message-Id: <1098134060.1077.446.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Oct 2004 17:14:20 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/18/2004 02:16:58 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/18/2004 02:17:01 PM, Serialize complete at 10/18/2004 02:17:01 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, "Joel M. Halpern" , "Steven Blake \(petri-meat\)" , zsolt@nc.rr.com, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit So far you are the second person who has shown desire for this. I was the other person; both of us are driven by implementation experience. How about we just keep it as a note in the draft for now (for progress reasons)? Hopefully implementation experience will show the error of whats being proposed right now, then we can come back and fix it? cheers, jamal On Mon, 2004-10-18 at 10:20, Weiming Wang wrote: > Hi Jamal, > > main hdr (eg type = config) > | > | > +--- T = LFBselect > | | > | +-- LFBCLASSID = target LFB class > | | > | | > | +-- LFBInstance = target LFB instance > > [Weiming] The more I'm thinking, the more I see the value to address multipul > LFB instances here (I can now live with single LFB class). To speak of this, I > have an aspire to show my yesterday experience with my GRMP test platform > (sorry I have to mention it). As you know, GRMP does not support multipul LFB > instance addressing. Yesterday, we had to prepare a show of the platform to > guests from our sponsors. Before the show, we spent near one hour to operate on > the menu to construct a scenario, in which there were 5 output port, 5 > associated schedulers (LFBs), and several other LFBs that have many instances. > unfortunately, we faced a problem with one of the machine. Then we had to do it > again. At that time, I had a VERY VERY strong desire that batch configuration > based on multipul LFB isntance addressing can be used. > > I can see very simple scheme to include multipul instances here (by ranging, or > by enum, or by both). Definitely, I believe this will greatly improve our > protocol. > > I sincerely hope this be considered seriously by gentlemen. > > Best regards, > Weiming > > | | > | | > | +-- T = operation { ADD, DEL, GET, etc} > | | | > | | +-- // one or more path targets > | | // under discussion > | | > | +-- T = operation { ADD, DEL, GET, etc} > | | | > | | +-- // one or more path targets > | | // under discussion > | | > | +-- T = operation { ADD, DEL, GET, etc} > | | | > | | +-- // one or more path targets > | | // under discussion > | | > > In other words: Very similar to the way we have it already except > the naming has changed and we can target multiple > operations and multiple paths in an LFB instance > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > > Welcome back Weiming. I have updated the text with the query/response. > > The only outstanding issue is 6.7. Please weigh in. > > I think we are ready top start making updates. > > > > cheers, > > jamal > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 18:16:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29957 for ; Mon, 18 Oct 2004 18:16:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJg02-00036w-Tg for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 18:29:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJfW4-0004pp-2S; Mon, 18 Oct 2004 17:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJf9T-0008Tn-Qi for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 17:34:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25547 for ; Mon, 18 Oct 2004 17:34:40 -0400 (EDT) Received: from [204.85.2.226] (helo=mail.modnetinc.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJfLT-000266-Co for forces-protocol@ietf.org; Mon, 18 Oct 2004 17:47:11 -0400 Received: (qmail 28177 invoked by uid 530); 18 Oct 2004 21:34:12 -0000 Received: from zsolt@modularnet.com by proteus-01.proteandevices.com by uid 527 with qmail-scanner-1.16 (clamscan: 0.54. Clear:. Processed in 0.823526 secs); 18 Oct 2004 21:34:12 -0000 Received: from proteus-02.proteandevices.com (HELO ?127.0.0.1?) (192.168.0.202) by 0 with SMTP; 18 Oct 2004 21:34:11 -0000 From: Zsolt Haraszti To: "Joel M. Halpern" In-Reply-To: <5.1.0.14.0.20041018165715.03523890@mail.megisto.com> References: <41741D78.4070205@idt.com> <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> <1098115003.2884.67.camel@localhost.localdomain> <4173FB88.1000008@idt.com> <1098126011.2884.162.camel@localhost.localdomain> <41741D78.4070205@idt.com> <5.1.0.14.0.20041018165715.03523890@mail.megisto.com> Content-Type: text/plain Organization: Modular Networks, Inc. Message-Id: <1098135051.2884.302.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 18 Oct 2004 17:30:51 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, Jamal Hadi Salim , Alan DeKok , Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Re: Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit On Mon, 2004-10-18 at 16:58, Joel M. Halpern wrote: > Why not just declare that structs start with their length. Then we can > declare that an array consists of its element count (or length and element > count) followed by the representation of its contents. [Ignoring for the > moment the issue of dense vs sparse packing, subscript representation, etc.] > That's because when the struct is of fixed size, it is really not needed and completely destroys even the possibility that you can memcpy() a large array of these structs. We may have put too much stress on the efficiency design goal. But as we are talking to customers and partners, they consistent concern is efficiency. Therefore we decided that we try to design the data transfer such that it scales 1:1 with the data size for large data elements, i.e., tables. If your table is stored on X MBs in memory, it should ideally require X MBs to transfer it over the wire. /zsolt > Yours, > Joel > > At 04:45 PM 10/18/2004 -0400, Zsolt Haraszti wrote: > >This is another trade-off issue. You are absolutely right, inserting > >the size info in front of each struct can be very useful, especially if > >it is a variable size struct. We will have this in ARRAYs, not > >part of the struct itself, but part of the ARRAY encoding. > >That does not help when the STRUCT is embedded in another struct though. -- Zsolt Haraszti Phone: +1 919-765-0027/2017 Modular Networks Mobile: +1 919-522-2337 Email: zsolt@modularnet.com _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 18 18:32:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01212 for ; Mon, 18 Oct 2004 18:32:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJgEh-0003LR-Up for forces-protocol-web-archive@ietf.org; Mon, 18 Oct 2004 18:44:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJfkv-0003dj-Rl; Mon, 18 Oct 2004 18:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJfNN-0002kC-3X for forces-protocol@megatron.ietf.org; Mon, 18 Oct 2004 17:49:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27091 for ; Mon, 18 Oct 2004 17:49:02 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJfZM-0002Tx-Ri for forces-protocol@ietf.org; Mon, 18 Oct 2004 18:01:33 -0400 Received: from JLaptop.megisto.com ([192.168.20.163]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Oct 2004 17:49:02 -0400 Message-Id: <5.1.0.14.0.20041018174605.022d36a8@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 18 Oct 2004 17:48:58 -0400 To: Zsolt Haraszti From: "Joel M. Halpern" In-Reply-To: <1098135051.2884.302.camel@localhost.localdomain> References: <5.1.0.14.0.20041018165715.03523890@mail.megisto.com> <41741D78.4070205@idt.com> <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> <1098115003.2884.67.camel@localhost.localdomain> <4173FB88.1000008@idt.com> <1098126011.2884.162.camel@localhost.localdomain> <41741D78.4070205@idt.com> <5.1.0.14.0.20041018165715.03523890@mail.megisto.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Oct 2004 21:49:02.0321 (UTC) FILETIME=[48065610:01C4B55C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, Jamal Hadi Salim , Alan DeKok , Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Re: Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 I understand the desire for efficiency. But using a different encoding for the array depending upon the ability to know the size seems like asking for trouble. After all, we are going to need to find a way to include additional information anyway. As for including the size in the struct, if we want it there, and an implementor wants the memcpy efficiency, they can always include the size in the front of the struct. (And if they want to generate the structs automatically from the XML, they just need to teach the tool to add the size field.) I want to be careful about letting implementation wrap us around to contorted a protocol encoding. Yours, Joel At 05:30 PM 10/18/2004 -0400, Zsolt Haraszti wrote: >On Mon, 2004-10-18 at 16:58, Joel M. Halpern wrote: > > Why not just declare that structs start with their length. Then we can > > declare that an array consists of its element count (or length and element > > count) followed by the representation of its contents. [Ignoring for the > > moment the issue of dense vs sparse packing, subscript representation, > etc.] > > > >That's because when the struct is of fixed size, it is really not >needed and completely destroys even the possibility that you can >memcpy() a large array of these structs. > >We may have put too much stress on the efficiency design goal. > >But as we are talking to customers and partners, they consistent >concern is efficiency. > >Therefore we decided that we try to design the data transfer such >that it scales 1:1 with the data size for large data elements, i.e., >tables. If your table is stored on X MBs in memory, it should ideally >require X MBs to transfer it over the wire. > >/zsolt > > > Yours, > > Joel > > > > At 04:45 PM 10/18/2004 -0400, Zsolt Haraszti wrote: > > >This is another trade-off issue. You are absolutely right, inserting > > >the size info in front of each struct can be very useful, especially if > > >it is a variable size struct. We will have this in ARRAYs, not > > >part of the struct itself, but part of the ARRAY encoding. > > >That does not help when the STRUCT is embedded in another struct though. >-- >Zsolt Haraszti Phone: +1 919-765-0027/2017 >Modular Networks Mobile: +1 919-522-2337 > Email: zsolt@modularnet.com _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 19 00:44:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00488 for ; Tue, 19 Oct 2004 00:44:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJm3p-0002tx-GU for forces-protocol-web-archive@ietf.org; Tue, 19 Oct 2004 00:57:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJlZz-0003e7-O8; Tue, 19 Oct 2004 00:26:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJlDU-0000AC-SG for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 00:03:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27809 for ; Tue, 19 Oct 2004 00:03:13 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJlPW-0002A1-5V for forces-protocol@ietf.org; Tue, 19 Oct 2004 00:15:48 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CJlDM-0002jM-Ch for forces-protocol@ietf.org; Tue, 19 Oct 2004 00:03:12 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Tue, 19 Oct 2004 12:21:00 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Tue, 19 Oct 2004 11:58:35 +0800 Message-ID: <03a101c4b590$21dcc0d0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Tue, 19 Oct 2004 12:00:10 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, "Joel M. Halpern" , "Steven Blake \(petri-meat\)" , zsolt@nc.rr.com, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Jamal,Hormuzd, and Joel, I think we have already have the issue as an editorial note as below: Editorial Note: 1. Under discussion is, when an 'FE Protocol ... 2. Under discussion is, do we need to support multiple objects addressing at the LFB Type and LFB Instance layer? One simple way to support multiple LFB types or instances is to use TLVs to identify the group of Type IDs and Instance IDs, rather than only one Type and Instance ID. A range of Instance IDs may also be supported in this way. Hormuzd and Joel, do you really think it is not the case? I remember Joel supposed there might be thousands of instances with same LFB calss. In this case, if we do not support a range of intance addressing, it actually makes our protocol unpractical. regards, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > > So far you are the second person who has shown desire for this. I was > the other person; both of us are driven by implementation experience. > How about we just keep it as a note in the draft for now (for progress > reasons)? > Hopefully implementation experience will show the error of whats being > proposed right now, then we can come back and fix it? > > cheers, > jamal > > > On Mon, 2004-10-18 at 10:20, Weiming Wang wrote: > > Hi Jamal, > > > > main hdr (eg type = config) > > | > > | > > +--- T = LFBselect > > | | > > | +-- LFBCLASSID = target LFB class > > | | > > | | > > | +-- LFBInstance = target LFB instance > > > > [Weiming] The more I'm thinking, the more I see the value to address multipul > > LFB instances here (I can now live with single LFB class). To speak of this, I > > have an aspire to show my yesterday experience with my GRMP test platform > > (sorry I have to mention it). As you know, GRMP does not support multipul LFB > > instance addressing. Yesterday, we had to prepare a show of the platform to > > guests from our sponsors. Before the show, we spent near one hour to operate on > > the menu to construct a scenario, in which there were 5 output port, 5 > > associated schedulers (LFBs), and several other LFBs that have many instances. > > unfortunately, we faced a problem with one of the machine. Then we had to do it > > again. At that time, I had a VERY VERY strong desire that batch configuration > > based on multipul LFB isntance addressing can be used. > > > > I can see very simple scheme to include multipul instances here (by ranging, or > > by enum, or by both). Definitely, I believe this will greatly improve our > > protocol. > > > > I sincerely hope this be considered seriously by gentlemen. > > > > Best regards, > > Weiming > > > > | | > > | | > > | +-- T = operation { ADD, DEL, GET, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > | +-- T = operation { ADD, DEL, GET, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > | +-- T = operation { ADD, DEL, GET, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > > > In other words: Very similar to the way we have it already except > > the naming has changed and we can target multiple > > operations and multiple paths in an LFB instance > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > > > > > Welcome back Weiming. I have updated the text with the query/response. > > > The only outstanding issue is 6.7. Please weigh in. > > > I think we are ready top start making updates. > > > > > > cheers, > > > jamal > > > > > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 19 02:08:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13145 for ; Tue, 19 Oct 2004 02:08:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJnN0-0004fv-F2 for forces-protocol-web-archive@ietf.org; Tue, 19 Oct 2004 02:21:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJmiX-0000KP-2H; Tue, 19 Oct 2004 01:39:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJme6-0006t0-NO for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 01:34:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04502 for ; Tue, 19 Oct 2004 01:34:48 -0400 (EDT) Received: from [204.85.2.226] (helo=mail.modnetinc.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJmqA-0003vF-4b for forces-protocol@ietf.org; Tue, 19 Oct 2004 01:47:22 -0400 Received: (qmail 29911 invoked by uid 530); 19 Oct 2004 05:34:18 -0000 Received: from zsolt@modularnet.com by proteus-01.proteandevices.com by uid 527 with qmail-scanner-1.16 (clamscan: 0.54. Clear:. Processed in 0.959901 secs); 19 Oct 2004 05:34:18 -0000 Received: from proteus-02.proteandevices.com (HELO ?127.0.0.1?) (192.168.0.202) by 0 with SMTP; 19 Oct 2004 05:34:17 -0000 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Zsolt Haraszti To: "Wang,Weiming" In-Reply-To: <03a101c4b590$21dcc0d0$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <03a101c4b590$21dcc0d0$845c21d2@Necom.hzic.edu.cn> Content-Type: text/plain Organization: Modular Networks, Inc. Message-Id: <1098163857.2662.81.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 19 Oct 2004 01:30:57 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, "Joel M. Halpern" , "Steven Blake \(petri-meat\)" , Jamal Hadi Salim , Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Content-Transfer-Encoding: 7bit I suggested this already way back, and now I bring this up again. First, I firmly believe that we must support multicast (and I think that is what Weiming is bringing up in his recent emails; if not, then I still do not understand the issue, so please explain; but the rest of this email is still valid.). Second, dividing the LFB address into two components, class ID and instance ID, and splitting the two into two TLVs have nothing to do with solving multicast. I define multicast in the ForCES context as sending the same configuration requests to a set of LFB instances, with the additional constraints: - the (LFB) instances that are targeted are of the same type (class) - the instances may reside over multiple FEs - although one or more instances of a certain class maybe target of a a multicast request on a certain FE, there may be other instances of the same class on the FE that are NOT part of the multicast request. In other words, we must be able to selectively target only a sub-set of the instances of the same class on any FE (that's why it's multicast and not broadcast). - when LFB instances on multiple FEs are part of the same tree, the LFB instances on one FE may have a different set of instance IDs than LFBs on another FE. Further observations: - For all the practical cases where I see this useful, the multicast groups may change over time, but rather infrequently. That is, potentially a large number of config requests may be sent to the LFBs before the group membership changes. - In some cases the same LFB instance may be a member of multiple multicast groups simultaneously. Example: An FE may have 4 instances of IP prefix lookup LFBs, each serving one channelized physical interface with potentially a large number of channels, each channel configured as an IP interface. There may be more than one FEs in the system. Consider two cases: one without VRFs and one with VRFs. When there are no VRFs, the same FIB needs to be loaded into all the 4 LFBs (to all FEs if you have more than one). And all subsequent updates to the FIB must be mirrored to all these LFBs. When there are VRFs and the interfaces can use overlapping address spaces (an all too common case for modern IPv4 edge routers), then we have a more refined situation. The CE maintains as many separate FIBs as many VRFs are in use. What needs to be loaded into a given LFB instance depends on the VRF membership of the interfaces served by the given instance. That may change when the interface configurations change, which can be considered infrequent compared to route changes in the FIB. A brute-force solution would be to mirror all VRFs to all LFB instances; this does not scale very well. A more desirable solution is to download selectively the right content to the rigth LFBs. So in this case we must be able to selectively form a multicast group for each VRF and make sure only those LFB instances are members which serve one or more interfaces that belong to the VRF. Since the same LFB instance may serve interfaces of many VRFs, the LFB must receive the config request of multiple groups. The proposed model: Considering all the above, the notion of configurable multicast groups seems very appealing. The idea is very similar to multicast trees in IP networks. This is what was suggested earlier: We introduce a stateful multicast group model in which the CE can configure the FE to define and manage multicast groups. This can be done, e.g., via a special attribute of the FE class instance. The heart of the model is a multicast table attribute in the FE object, outlined as follows: MTABLE := ARRAY of MGROUP MGROUP := {CID, MIID, IID-LIST} IID-LIST := ARRAY of IID where: - CID is an LFB class ID - IID is an LFB instance ID, valid on the FE - MIID is a "virtual" instance ID from a pre-defined "multicast" range, i.e., it is not the actual IID of any instance on the FE. The CE can add/remove entries in the MTABLE, creating/removing multicast groups. The CE can also add/remove IIDs in the IID-LIST of any existing group, that is, grow or shrink the membership in a given group. Once a group is set, all subsequent requests using a CID:MIID address will be delivered to all LFB instances in the referred group. Benefits: - The above schema supports well the case of overlapping memberships. - Using the same group address across mutiple FEs will enable efficient multi-FE multicasts, i.e., the same message can be sent to multiple FEs. This is because the CE can assign an MIID for each multicast tree, so a config message with given CID:MIID address in the LFB TLV will address the right set of LFB instances on all FEs. Cheers, Zsolt On Tue, 2004-10-19 at 00:00, Wang,Weiming wrote: > Jamal,Hormuzd, and Joel, > > I think we have already have the issue as an editorial note as below: > > Editorial Note: > 1. Under discussion is, when an 'FE Protocol ... > > 2. Under discussion is, do we need to support > multiple objects addressing at the LFB Type > and LFB Instance layer? One simple way to > support multiple LFB types or instances is > to use TLVs to identify the group of Type > IDs and Instance IDs, rather than only one > Type and Instance ID. A range of Instance > IDs may also be supported in this way. > > Hormuzd and Joel, do you really think it is not the case? I remember Joel > supposed there might be thousands of instances with same LFB calss. In this > case, if we do not support a range of intance addressing, it actually makes our > protocol unpractical. > > regards, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > > So far you are the second person who has shown desire for this. I was > > the other person; both of us are driven by implementation experience. > > How about we just keep it as a note in the draft for now (for progress > > reasons)? > > Hopefully implementation experience will show the error of whats being > > proposed right now, then we can come back and fix it? > > > > cheers, > > jamal > > > > > > On Mon, 2004-10-18 at 10:20, Weiming Wang wrote: > > > Hi Jamal, > > > > > > main hdr (eg type = config) > > > | > > > | > > > +--- T = LFBselect > > > | | > > > | +-- LFBCLASSID = target LFB class > > > | | > > > | | > > > | +-- LFBInstance = target LFB instance > > > > > > [Weiming] The more I'm thinking, the more I see the value to address > multipul > > > LFB instances here (I can now live with single LFB class). To speak of this, > I > > > have an aspire to show my yesterday experience with my GRMP test platform > > > (sorry I have to mention it). As you know, GRMP does not support multipul > LFB > > > instance addressing. Yesterday, we had to prepare a show of the platform to > > > guests from our sponsors. Before the show, we spent near one hour to operate > on > > > the menu to construct a scenario, in which there were 5 output port, 5 > > > associated schedulers (LFBs), and several other LFBs that have many > instances. > > > unfortunately, we faced a problem with one of the machine. Then we had to do > it > > > again. At that time, I had a VERY VERY strong desire that batch > configuration > > > based on multipul LFB isntance addressing can be used. > > > > > > I can see very simple scheme to include multipul instances here (by ranging, > or > > > by enum, or by both). Definitely, I believe this will greatly improve our > > > protocol. > > > > > > I sincerely hope this be considered seriously by gentlemen. > > > > > > Best regards, > > > Weiming > > > > > > | | > > > | | > > > | +-- T = operation { ADD, DEL, GET, etc} > > > | | | > > > | | +-- // one or more path targets > > > | | // under discussion > > > | | > > > | +-- T = operation { ADD, DEL, GET, etc} > > > | | | > > > | | +-- // one or more path targets > > > | | // under discussion > > > | | > > > | +-- T = operation { ADD, DEL, GET, etc} > > > | | | > > > | | +-- // one or more path targets > > > | | // under discussion > > > | | > > > > > > In other words: Very similar to the way we have it already except > > > the naming has changed and we can target multiple > > > operations and multiple paths in an LFB instance > > > ----- Original Message ----- > > > From: "Jamal Hadi Salim" > > > > > > > > Welcome back Weiming. I have updated the text with the query/response. > > > > The only outstanding issue is 6.7. Please weigh in. > > > > I think we are ready top start making updates. > > > > > > > > cheers, > > > > jamal > > > > > > > > > > > > -- Zsolt Haraszti Phone: +1 919-765-0027/2017 Modular Networks Mobile: +1 919-522-2337 Email: zsolt@modularnet.com _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 19 04:37:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01253 for ; Tue, 19 Oct 2004 04:37:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJpgq-0007PX-B4 for forces-protocol-web-archive@ietf.org; Tue, 19 Oct 2004 04:49:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJpAJ-0007YH-8o; Tue, 19 Oct 2004 04:16:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJopR-0004Y0-8a for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 03:54:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27849 for ; Tue, 19 Oct 2004 03:54:38 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJp1V-0006hU-UX for forces-protocol@ietf.org; Tue, 19 Oct 2004 04:07:14 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9J7sXxn000678; Tue, 19 Oct 2004 07:54:33 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9J7lmrh026119; Tue, 19 Oct 2004 07:47:48 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101900535705960 ; Tue, 19 Oct 2004 00:53:57 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 00:53:57 -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 Subject: RE: [Forces-protocol] RE: GET/SET in one msg ? Date: Tue, 19 Oct 2004 00:51:51 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408> Thread-Topic: [Forces-protocol] RE: GET/SET in one msg ? Thread-Index: AcS1kJoRQaburKgcSmWWNaIPX57HBwAHsSMg From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 19 Oct 2004 07:53:57.0519 (UTC) FILETIME=[C9A609F0:01C4B5B0] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, zsolt@nc.rr.com, "Joel M. Halpern" , "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, Alan DeKok , "Deleganes, Ellen M" , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: quoted-printable Weiming, In majority of cases, most of us have only seen single LFB instances on FEs. In any case, your requirement can easily be solved by defining a special Instance ID for LFBs that addresses all instances of that LFB on the FE. I thought we already had some text along these lines in the protocol draft (probably the header section) regards Hormuzd p.s. I haven't read Zsolt's email on this yet... -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn]=20 Sent: Monday, October 18, 2004 9:00 PM To: hadi@znyx.com Cc: Khosravi, Hormuzd M; ram.gopal@nokia.com; Steven Blake (petri-meat); Joel M. Halpern; Alan DeKok; zsolt@nc.rr.com; forces-protocol@ietf.org; Deleganes, Ellen M; Yang, Lily L Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Jamal,Hormuzd, and Joel, I think we have already have the issue as an editorial note as below: Editorial Note: 1. Under discussion is, when an 'FE Protocol ... 2. Under discussion is, do we need to support multiple objects addressing at the LFB Type and LFB Instance layer? One simple way to support multiple LFB types or instances is to use TLVs to identify the group of Type IDs and Instance IDs, rather than only one Type and Instance ID. A range of Instance IDs may also be supported in this way. Hormuzd and Joel, do you really think it is not the case? I remember Joel supposed there might be thousands of instances with same LFB calss. In this case, if we do not support a range of intance addressing, it actually makes our protocol unpractical. regards, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > > So far you are the second person who has shown desire for this. I was > the other person; both of us are driven by implementation experience. > How about we just keep it as a note in the draft for now (for progress > reasons)? > Hopefully implementation experience will show the error of whats being > proposed right now, then we can come back and fix it? > > cheers, > jamal > > > On Mon, 2004-10-18 at 10:20, Weiming Wang wrote: > > Hi Jamal, > > > > main hdr (eg type =3D config) > > | > > | > > +--- T =3D LFBselect > > | | > > | +-- LFBCLASSID =3D target LFB class > > | | > > | | > > | +-- LFBInstance =3D target LFB instance > > > > [Weiming] The more I'm thinking, the more I see the value to address multipul > > LFB instances here (I can now live with single LFB class). To speak of this, I > > have an aspire to show my yesterday experience with my GRMP test platform > > (sorry I have to mention it). As you know, GRMP does not support multipul LFB > > instance addressing. Yesterday, we had to prepare a show of the platform to > > guests from our sponsors. Before the show, we spent near one hour to operate on > > the menu to construct a scenario, in which there were 5 output port, 5 > > associated schedulers (LFBs), and several other LFBs that have many instances. > > unfortunately, we faced a problem with one of the machine. Then we had to do it > > again. At that time, I had a VERY VERY strong desire that batch configuration > > based on multipul LFB isntance addressing can be used. > > > > I can see very simple scheme to include multipul instances here (by ranging, or > > by enum, or by both). Definitely, I believe this will greatly improve our > > protocol. > > > > I sincerely hope this be considered seriously by gentlemen. > > > > Best regards, > > Weiming > > > > | | > > | | > > | +-- T =3D operation { ADD, DEL, GET, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > | +-- T =3D operation { ADD, DEL, GET, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > | +-- T =3D operation { ADD, DEL, GET, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > > > In other words: Very similar to the way we have it already except > > the naming has changed and we can target multiple > > operations and multiple paths in an LFB instance > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > > > > > Welcome back Weiming. I have updated the text with the query/response. > > > The only outstanding issue is 6.7. Please weigh in. > > > I think we are ready top start making updates. > > > > > > cheers, > > > jamal > > > > > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 19 07:11:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11235 for ; Tue, 19 Oct 2004 07:11:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJs6L-0001oQ-20 for forces-protocol-web-archive@ietf.org; Tue, 19 Oct 2004 07:24:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJrVi-00046e-6D; Tue, 19 Oct 2004 06:46:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJrGA-0000kL-Ji for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 06:30:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08361 for ; Tue, 19 Oct 2004 06:30:23 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJrRx-00013I-ON for forces-protocol@ietf.org; Tue, 19 Oct 2004 06:43:01 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CJrFk-0002T4-7Z for forces-protocol@ietf.org; Tue, 19 Oct 2004 06:30:04 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Tue, 19 Oct 2004 18:48:04 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Tue, 19 Oct 2004 18:25:02 +0800 Message-ID: <04a501c4b5c6$323cbd50$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Zsolt Haraszti" References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <03a101c4b590$21dcc0d0$845c21d2@Necom.hzic.edu.cn> <1098163857.2662.81.camel@localhost.localdomain> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Tue, 19 Oct 2004 18:27:12 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, "Joel M. Halpern" , "Steven Blake \(petri-meat\)" , Jamal Hadi Salim , Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Zsolt, Thank you for your intensive reply. Yes, what I suggest is trying a multicast config (that is, the data is the same for all instances) at pure instance layer by use of a very simple and explicit multipul instance scheme. I understand your scheme for multicast at both FE layer and instance layer. It's ture defining such a scheme can supply much more powerful function than purely by use of explicit instances for object addressing. Actually I think we have considered such scheme during protocol design (by use of multicast FE id address and LFB isntance id address).I also agree that the scheme you presented below to use an FE attribute to define instance multicast group is practical to realize such multicast. What I just see is, apart from using FEs and Instance multicast address, to use multipul explicit instances is still valuable for customers. For example, consider there are two LFBs that have one same attribute data to config, and the attribute data is quite lenthy in protocol text. Because there is only one message to use, users may be tired of defining a specific instance multicast group for such only one time config. But they will definitely be very tired of repeating the lenthy protocol text. In this case, by use of multipul instances, I'm sure they will be very happy. Thank you. Weiming ----- Original Message ----- From: "Zsolt Haraszti" > I suggested this already way back, and now I bring this up again. > > First, I firmly believe that we must support multicast (and I think > that is what Weiming is bringing up in his recent emails; if not, > then I still do not understand the issue, so please explain; but the > rest of this email is still valid.). > > Second, dividing the LFB address into two components, class ID and > instance ID, and splitting the two into two TLVs have nothing > to do with solving multicast. What I think is to use a TLV to structuraly represent instances, for example, to use a range structure for a range of instances. > > I define multicast in the ForCES context as sending the same > configuration requests to a set of LFB instances, with the additional > constraints: > - the (LFB) instances that are targeted are of the same type (class) > - the instances may reside over multiple FEs > - although one or more instances of a certain class maybe target of a > a multicast request on a certain FE, there may be other instances of > the same class on the FE that are NOT part of the multicast request. > In other words, we must be able to selectively target only a sub-set > of the instances of the same class on any FE (that's why it's > multicast and not broadcast). > - when LFB instances on multiple FEs are part of the same tree, the > LFB instances on one FE may have a different set of instance > IDs than LFBs on another FE. > > Further observations: > - For all the practical cases where I see this useful, the multicast > groups may change over time, but rather infrequently. That is, > potentially a large number of config requests may be sent to the > LFBs before the group membership changes. > - In some cases the same LFB instance may be a member of multiple > multicast groups simultaneously. > > Example: > > An FE may have 4 instances of IP prefix lookup LFBs, > each serving one channelized physical interface with potentially a > large number of channels, each channel configured as an IP interface. > There may be more than one FEs in the system. Consider two cases: one > without VRFs and one with VRFs. > > When there are no VRFs, the same FIB needs to be loaded into > all the 4 LFBs (to all FEs if you have more than one). And > all subsequent updates to the FIB must be mirrored to all these > LFBs. > > When there are VRFs and the interfaces can use overlapping address > spaces (an all too common case for modern IPv4 edge routers), > then we have a more refined situation. The CE maintains as many > separate FIBs as many VRFs are in use. What needs to be loaded > into a given LFB instance depends on the VRF membership of the > interfaces served by the given instance. That may change when > the interface configurations change, which can be considered > infrequent compared to route changes in the FIB. A brute-force > solution would be to mirror all VRFs to all LFB instances; this > does not scale very well. A more desirable solution is to download > selectively the right content to the rigth LFBs. So in this > case we must be able to selectively form a multicast group for > each VRF and make sure only those LFB instances are members which > serve one or more interfaces that belong to the VRF. Since > the same LFB instance may serve interfaces of many VRFs, the > LFB must receive the config request of multiple groups. > > The proposed model: > > Considering all the above, the notion of configurable multicast > groups seems very appealing. The idea is very similar to multicast > trees in IP networks. This is what was suggested earlier: > > We introduce a stateful multicast group model in which the CE can > configure the FE to define and manage multicast groups. This > can be done, e.g., via a special attribute of the FE class instance. > The heart of the model is a multicast table attribute in the FE > object, outlined as follows: > > MTABLE := ARRAY of MGROUP > MGROUP := {CID, MIID, IID-LIST} > IID-LIST := ARRAY of IID > > where: > - CID is an LFB class ID > - IID is an LFB instance ID, valid on the FE > - MIID is a "virtual" instance ID from a pre-defined "multicast" range, > i.e., it is not the actual IID of any instance on the FE. > > The CE can add/remove entries in the MTABLE, creating/removing multicast > groups. > > The CE can also add/remove IIDs in the IID-LIST of any existing group, > that is, grow or shrink the membership in a given group. > > Once a group is set, all subsequent requests using a CID:MIID > address will be delivered to all LFB instances in the referred group. > > Benefits: > - The above schema supports well the case of overlapping memberships. > - Using the same group address across mutiple FEs will enable efficient > multi-FE multicasts, i.e., the same message can be sent to multiple > FEs. This is because the CE can assign an MIID for each multicast > tree, so a config message with given CID:MIID address in the LFB TLV > will address the right set of LFB instances on all FEs. > > Cheers, > Zsolt > > On Tue, 2004-10-19 at 00:00, Wang,Weiming wrote: > > Jamal,Hormuzd, and Joel, > > > > I think we have already have the issue as an editorial note as below: > > > > Editorial Note: > > 1. Under discussion is, when an 'FE Protocol ... > > > > 2. Under discussion is, do we need to support > > multiple objects addressing at the LFB Type > > and LFB Instance layer? One simple way to > > support multiple LFB types or instances is > > to use TLVs to identify the group of Type > > IDs and Instance IDs, rather than only one > > Type and Instance ID. A range of Instance > > IDs may also be supported in this way. > > > > Hormuzd and Joel, do you really think it is not the case? I remember Joel > > supposed there might be thousands of instances with same LFB calss. In this > > case, if we do not support a range of intance addressing, it actually makes our > > protocol unpractical. > > > > regards, > > Weiming > > > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > > > > > So far you are the second person who has shown desire for this. I was > > > the other person; both of us are driven by implementation experience. > > > How about we just keep it as a note in the draft for now (for progress > > > reasons)? > > > Hopefully implementation experience will show the error of whats being > > > proposed right now, then we can come back and fix it? > > > > > > cheers, > > > jamal > > > > > > > > > On Mon, 2004-10-18 at 10:20, Weiming Wang wrote: > > > > Hi Jamal, > > > > > > > > main hdr (eg type = config) > > > > | > > > > | > > > > +--- T = LFBselect > > > > | | > > > > | +-- LFBCLASSID = target LFB class > > > > | | > > > > | | > > > > | +-- LFBInstance = target LFB instance > > > > > > > > [Weiming] The more I'm thinking, the more I see the value to address > > multipul > > > > LFB instances here (I can now live with single LFB class). To speak of this, > > I > > > > have an aspire to show my yesterday experience with my GRMP test platform > > > > (sorry I have to mention it). As you know, GRMP does not support multipul > > LFB > > > > instance addressing. Yesterday, we had to prepare a show of the platform to > > > > guests from our sponsors. Before the show, we spent near one hour to operate > > on > > > > the menu to construct a scenario, in which there were 5 output port, 5 > > > > associated schedulers (LFBs), and several other LFBs that have many > > instances. > > > > unfortunately, we faced a problem with one of the machine. Then we had to do > > it > > > > again. At that time, I had a VERY VERY strong desire that batch > > configuration > > > > based on multipul LFB isntance addressing can be used. > > > > > > > > I can see very simple scheme to include multipul instances here (by ranging, > > or > > > > by enum, or by both). Definitely, I believe this will greatly improve our > > > > protocol. > > > > > > > > I sincerely hope this be considered seriously by gentlemen. > > > > > > > > Best regards, > > > > Weiming > > > > > > > > | | > > > > | | > > > > | +-- T = operation { ADD, DEL, GET, etc} > > > > | | | > > > > | | +-- // one or more path targets > > > > | | // under discussion > > > > | | > > > > | +-- T = operation { ADD, DEL, GET, etc} > > > > | | | > > > > | | +-- // one or more path targets > > > > | | // under discussion > > > > | | > > > > | +-- T = operation { ADD, DEL, GET, etc} > > > > | | | > > > > | | +-- // one or more path targets > > > > | | // under discussion > > > > | | > > > > > > > > In other words: Very similar to the way we have it already except > > > > the naming has changed and we can target multiple > > > > operations and multiple paths in an LFB instance > > > > ----- Original Message ----- > > > > From: "Jamal Hadi Salim" > > > > > > > > > > Welcome back Weiming. I have updated the text with the query/response. > > > > > The only outstanding issue is 6.7. Please weigh in. > > > > > I think we are ready top start making updates. > > > > > > > > > > cheers, > > > > > jamal > > > > > > > > > > > > > > > > > -- > Zsolt Haraszti Phone: +1 919-765-0027/2017 > Modular Networks Mobile: +1 919-522-2337 > Email: zsolt@modularnet.com > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 19 07:12:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11314 for ; Tue, 19 Oct 2004 07:12:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJs73-0001pG-FU for forces-protocol-web-archive@ietf.org; Tue, 19 Oct 2004 07:25:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJrVv-00049m-Fb; Tue, 19 Oct 2004 06:46:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJrMO-0001ah-Ai for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 06:36:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08738 for ; Tue, 19 Oct 2004 06:36:48 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJrY0-00017g-3E for forces-protocol@ietf.org; Tue, 19 Oct 2004 06:49:27 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Tue, 19 Oct 2004 18:54:22 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Tue, 19 Oct 2004 18:31:20 +0800 Message-ID: <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Tue, 19 Oct 2004 18:33:29 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: ram.gopal@nokia.com, zsolt@nc.rr.com, "Joel M. Halpern" , Alan DeKok , forces-protocol@ietf.org, "Steven Blake \(petri-meat\)" , "Deleganes, Ellen M" , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Hormuzd, Thanks for reply. ----- Original Message ----- From: "Khosravi, Hormuzd M" Weiming, In majority of cases, most of us have only seen single LFB instances on FEs. [Weiming] I'm afraid this is not true. From my experience, it's very often we have more than one instances. In any case, your requirement can easily be solved by defining a special Instance ID for LFBs that addresses all instances of that LFB on the FE. I thought we already had some text along these lines in the protocol draft (probably the header section) [Weiming] Yes, we have proposed using an insatnce broadcast address to address all instances. It's useful, but still from my experience, it's not enough. I'v very often seen the case where there is only one insatnce that has different config requriement than all other instances. regards Hormuzd p.s. I haven't read Zsolt's email on this yet... -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn] Sent: Monday, October 18, 2004 9:00 PM To: hadi@znyx.com Cc: Khosravi, Hormuzd M; ram.gopal@nokia.com; Steven Blake (petri-meat); Joel M. Halpern; Alan DeKok; zsolt@nc.rr.com; forces-protocol@ietf.org; Deleganes, Ellen M; Yang, Lily L Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Jamal,Hormuzd, and Joel, I think we have already have the issue as an editorial note as below: Editorial Note: 1. Under discussion is, when an 'FE Protocol ... 2. Under discussion is, do we need to support multiple objects addressing at the LFB Type and LFB Instance layer? One simple way to support multiple LFB types or instances is to use TLVs to identify the group of Type IDs and Instance IDs, rather than only one Type and Instance ID. A range of Instance IDs may also be supported in this way. Hormuzd and Joel, do you really think it is not the case? I remember Joel supposed there might be thousands of instances with same LFB calss. In this case, if we do not support a range of intance addressing, it actually makes our protocol unpractical. regards, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > > So far you are the second person who has shown desire for this. I was > the other person; both of us are driven by implementation experience. > How about we just keep it as a note in the draft for now (for progress > reasons)? > Hopefully implementation experience will show the error of whats being > proposed right now, then we can come back and fix it? > > cheers, > jamal > > > On Mon, 2004-10-18 at 10:20, Weiming Wang wrote: > > Hi Jamal, > > > > main hdr (eg type = config) > > | > > | > > +--- T = LFBselect > > | | > > | +-- LFBCLASSID = target LFB class > > | | > > | | > > | +-- LFBInstance = target LFB instance > > > > [Weiming] The more I'm thinking, the more I see the value to address multipul > > LFB instances here (I can now live with single LFB class). To speak of this, I > > have an aspire to show my yesterday experience with my GRMP test platform > > (sorry I have to mention it). As you know, GRMP does not support multipul LFB > > instance addressing. Yesterday, we had to prepare a show of the platform to > > guests from our sponsors. Before the show, we spent near one hour to operate on > > the menu to construct a scenario, in which there were 5 output port, 5 > > associated schedulers (LFBs), and several other LFBs that have many instances. > > unfortunately, we faced a problem with one of the machine. Then we had to do it > > again. At that time, I had a VERY VERY strong desire that batch configuration > > based on multipul LFB isntance addressing can be used. > > > > I can see very simple scheme to include multipul instances here (by ranging, or > > by enum, or by both). Definitely, I believe this will greatly improve our > > protocol. > > > > I sincerely hope this be considered seriously by gentlemen. > > > > Best regards, > > Weiming > > > > | | > > | | > > | +-- T = operation { ADD, DEL, GET, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > | +-- T = operation { ADD, DEL, GET, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > | +-- T = operation { ADD, DEL, GET, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > > > In other words: Very similar to the way we have it already except > > the naming has changed and we can target multiple > > operations and multiple paths in an LFB instance > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > > > > > Welcome back Weiming. I have updated the text with the query/response. > > > The only outstanding issue is 6.7. Please weigh in. > > > I think we are ready top start making updates. > > > > > > cheers, > > > jamal > > > > > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 19 21:28:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12813 for ; Tue, 19 Oct 2004 21:28:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK5TC-0002L6-RC for forces-protocol-web-archive@ietf.org; Tue, 19 Oct 2004 21:40:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3mC-0001IX-TN; Tue, 19 Oct 2004 19:52:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJtR5-0007N5-7b for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 08:49:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19471 for ; Tue, 19 Oct 2004 08:49:48 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJtdC-0003qv-Ja for forces-protocol@ietf.org; Tue, 19 Oct 2004 09:02:27 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101905521804:32935 ; Tue, 19 Oct 2004 05:52:18 -0700 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: "Wang,Weiming" In-Reply-To: <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408> <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1098190180.1089.912.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Oct 2004 08:49:40 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/19/2004 05:52:19 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/19/2004 05:52:23 AM, Serialize complete at 10/19/2004 05:52:23 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, zsolt@nc.rr.com, forces-protocol@ietf.org, Alan DeKok , "Joel M. Halpern" , "Steven Blake \(petri-meat\)" , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: 7bit Folks, There are two issues at stake: - Single class, multiple instances, same data -> multicast solves it. We have started such discussions in current protocol draft. Lets just continue along that line. - Single class, multiple instances, different data -> multicast not useful. We know how to achieve this; however, lets shelf it for now by adding a note to the draft and revisit it after some more implementation experiences. This should help us progress. Note that i agree with you Weiming on the need for this. Hormuzd, Steve/Zsolt and Joel disagree. Thats 4-2. Lets give them time to play with this some more and they may come to the same conclusion;-> The weigh in is efficiency between wasted bandwidth vs wasted compute cycles. cheers, jamal On Tue, 2004-10-19 at 06:33, Wang,Weiming wrote: > Hormuzd, > > Thanks for reply. > > ----- Original Message ----- > From: "Khosravi, Hormuzd M" > Weiming, > > In majority of cases, most of us have only seen single LFB instances on > FEs. > [Weiming] I'm afraid this is not true. From my experience, it's very often we > have more than one instances. > > In any case, your requirement can easily be solved by defining a special > Instance ID for LFBs that addresses all instances of that LFB on the FE. > I thought we already had some text along these lines in the protocol > draft (probably the header section) > [Weiming] Yes, we have proposed using an insatnce broadcast address to address > all instances. It's useful, but still from my experience, it's not enough. I'v > very often seen the case where there is only one insatnce that has different > config requriement than all other instances. > > regards > Hormuzd > p.s. I haven't read Zsolt's email on this yet... > > -----Original Message----- > From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn] > Sent: Monday, October 18, 2004 9:00 PM > To: hadi@znyx.com > Cc: Khosravi, Hormuzd M; ram.gopal@nokia.com; Steven Blake (petri-meat); > Joel M. Halpern; Alan DeKok; zsolt@nc.rr.com; forces-protocol@ietf.org; > Deleganes, Ellen M; Yang, Lily L > Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? > > Jamal,Hormuzd, and Joel, > > I think we have already have the issue as an editorial note as below: > > Editorial Note: > 1. Under discussion is, when an 'FE Protocol > ... > > 2. Under discussion is, do we need to support > multiple objects addressing at the LFB Type > and LFB Instance layer? One simple way to > support multiple LFB types or instances is > to use TLVs to identify the group of Type > IDs and Instance IDs, rather than only one > Type and Instance ID. A range of Instance > IDs may also be supported in this way. > > Hormuzd and Joel, do you really think it is not the case? I remember > Joel > supposed there might be thousands of instances with same LFB calss. In > this > case, if we do not support a range of intance addressing, it actually > makes our > protocol unpractical. > > regards, > Weiming > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > > So far you are the second person who has shown desire for this. I was > > the other person; both of us are driven by implementation experience. > > How about we just keep it as a note in the draft for now (for progress > > reasons)? > > Hopefully implementation experience will show the error of whats being > > proposed right now, then we can come back and fix it? > > > > cheers, > > jamal > > > > > > On Mon, 2004-10-18 at 10:20, Weiming Wang wrote: > > > Hi Jamal, > > > > > > main hdr (eg type = config) > > > | > > > | > > > +--- T = LFBselect > > > | | > > > | +-- LFBCLASSID = target LFB class > > > | | > > > | | > > > | +-- LFBInstance = target LFB instance > > > > > > [Weiming] The more I'm thinking, the more I see the value to address > multipul > > > LFB instances here (I can now live with single LFB class). To speak > of this, > I > > > have an aspire to show my yesterday experience with my GRMP test > platform > > > (sorry I have to mention it). As you know, GRMP does not support > multipul > LFB > > > instance addressing. Yesterday, we had to prepare a show of the > platform to > > > guests from our sponsors. Before the show, we spent near one hour to > operate > on > > > the menu to construct a scenario, in which there were 5 output port, > 5 > > > associated schedulers (LFBs), and several other LFBs that have many > instances. > > > unfortunately, we faced a problem with one of the machine. Then we > had to do > it > > > again. At that time, I had a VERY VERY strong desire that batch > configuration > > > based on multipul LFB isntance addressing can be used. > > > > > > I can see very simple scheme to include multipul instances here (by > ranging, > or > > > by enum, or by both). Definitely, I believe this will greatly > improve our > > > protocol. > > > > > > I sincerely hope this be considered seriously by gentlemen. > > > > > > Best regards, > > > Weiming > > > > > > | | > > > | | > > > | +-- T = operation { ADD, DEL, GET, etc} > > > | | | > > > | | +-- // one or more path targets > > > | | // under discussion > > > | | > > > | +-- T = operation { ADD, DEL, GET, etc} > > > | | | > > > | | +-- // one or more path targets > > > | | // under discussion > > > | | > > > | +-- T = operation { ADD, DEL, GET, etc} > > > | | | > > > | | +-- // one or more path targets > > > | | // under discussion > > > | | > > > > > > In other words: Very similar to the way we have it already except > > > the naming has changed and we can target multiple > > > operations and multiple paths in an LFB instance > > > ----- Original Message ----- > > > From: "Jamal Hadi Salim" > > > > > > > > Welcome back Weiming. I have updated the text with the > query/response. > > > > The only outstanding issue is 6.7. Please weigh in. > > > > I think we are ready top start making updates. > > > > > > > > cheers, > > > > jamal > > > > > > > > > > > > > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 19 21:49:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14376 for ; Tue, 19 Oct 2004 21:49:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK5ns-0002na-81 for forces-protocol-web-archive@ietf.org; Tue, 19 Oct 2004 22:02:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3yY-0005xx-Lc; Tue, 19 Oct 2004 20:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJuCb-000682-J8 for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 09:39:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25003 for ; Tue, 19 Oct 2004 09:38:54 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJuOT-0005Tt-MI for forces-protocol@ietf.org; Tue, 19 Oct 2004 09:51:33 -0400 Received: from JLaptop.megisto.com ([192.168.20.163]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 19 Oct 2004 09:38:39 -0400 Message-Id: <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Oct 2004 09:38:34 -0400 To: "Wang,Weiming" , From: "Joel M. Halpern" Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? In-Reply-To: <03a101c4b590$21dcc0d0$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 19 Oct 2004 13:38:39.0489 (UTC) FILETIME=[F1103710:01C4B5E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, "Steven Blake \(petri-meat\)" , zsolt@nc.rr.com, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 I do think that there may be thousands of instances. I do not think that this requires multiple addressing. I think that there are some interesting cases prompted by the possibility of very large numbers of LFBs, but they do not drive multiple addressing. My reasoning is based on the following premise. Firstly, if there are many LFBinstances s of a class, then it is likely that many fields of the LFB instances will be the same, but it is extremely unlikely that all fields of the LFB instances will be the same. The simplest case to understand when one would need to setup all those LFBs at once is in a power recovery situation (the FE lost power, then recovered to an empty state.) The CE needs to send the configuration information to the FE. Secondly, I believe that transaction count is much more important than data volume. The FE is going to have to set every field in every LFB. Encoding is not going to change that. Given that there are distinct values in each LFB instance, there must be an operation against each LFB instance. The marginal gain from having a single transaction to update the identical fields, and then individual transactions for the distinct fields is very small. It does not reduce the number of IOs or the core transaction rate. If it is desired to optimize for this case, we may want to introduce (in a future version of the protocol) some kind of block checkpoint / restart mechanism. The CE would record its full state about the FE, and then ask the FE for a dump suitable for restoral of the FE state. Upon restart, the CE would rebuild its state from its stored representation, and would ship the dump back to the FE to enable efficient rebuilding there. I can see significant value in such a mechanism. I do not however see a need to include this in the first deliverable of the protocol. Yours, Joel M. Halpern At 12:00 PM 10/19/2004 +0800, Wang,Weiming wrote: >Jamal,Hormuzd, and Joel, > >I think we have already have the issue as an editorial note as below: > > Editorial Note: > 1. Under discussion is, when an 'FE Protocol ... > > 2. Under discussion is, do we need to support > multiple objects addressing at the LFB Type > and LFB Instance layer? One simple way to > support multiple LFB types or instances is > to use TLVs to identify the group of Type > IDs and Instance IDs, rather than only one > Type and Instance ID. A range of Instance > IDs may also be supported in this way. > >Hormuzd and Joel, do you really think it is not the case? I remember Joel >supposed there might be thousands of instances with same LFB calss. In this >case, if we do not support a range of intance addressing, it actually >makes our >protocol unpractical. > >regards, >Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 19 22:07:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15853 for ; Tue, 19 Oct 2004 22:07:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK658-0003BD-8C for forces-protocol-web-archive@ietf.org; Tue, 19 Oct 2004 22:20:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK45N-0001Kl-4c; Tue, 19 Oct 2004 20:12:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJvK8-0006Bk-OD for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 10:50:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03070 for ; Tue, 19 Oct 2004 10:50:50 -0400 (EDT) Received: from [66.46.215.210] (helo=post.ott.idt.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJvWL-0007fT-UZ for forces-protocol@ietf.org; Tue, 19 Oct 2004 11:03:30 -0400 Received: from [127.0.0.1] (dhcp195.ott.idt.com [192.168.102.195]) by post.ott.idt.com (Postfix) with ESMTP id 9B8971F0001; Tue, 19 Oct 2004 10:50:20 -0400 (EDT) Message-ID: <417528E3.3080305@idt.com> Date: Tue, 19 Oct 2004 10:46:59 -0400 From: Alan DeKok User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com References: <41741D78.4070205@idt.com> <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> <1098115003.2884.67.camel@localhost.localdomain> <4173FB88.1000008@idt.com> <1098126011.2884.162.camel@localhost.localdomain> <41741D78.4070205@idt.com> <5.1.0.14.0.20041018165715.03523890@mail.megisto.com> <1098133781.1075.437.camel@jzny.localdomain> In-Reply-To: <1098133781.1075.437.camel@jzny.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Steven \"Blake \(petri-meat\)\"" , "Yang, Lily L" , Zsolt Haraszti , "Joel M. Halpern" , forces-protocol@ietf.org, Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Re: Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Jamal Hadi Salim wrote: > Every thing is a TLV. > The T is the ID as provided by the XML doc. > > The disadvantage is clearly the abuse of bits. You could play tricks to > improve this of course. > The advantage is that this is a well know interface. There are intermediate possibilities. Rather than putting every element of every data structure into a unique TLV, you can have a TLV like "LFB-Instance-Data", which contains all of the PACKed information that Zsolt is talking about. The benefits with this approach are: - you have one LFB-Instance-Data TLV for all LFB's, rather than multiple data-specific TLV's, or multiple LFB-specific LFB's. - The protocol is more compact, efficient, and easy to parse by things that don't understand the internals of LFB configuration. - you can update the PACKed data and STRUCTs inside of LFB-Instance-Data without adding or deleting TLV's. I would propose the above scheme, and also a TLV such as LFB-Data-Structure, which could hold an encoded representation of the STRUCTs and data that the LFB understands, so that the CE can "bootstrap" it's knowledge of how to configure the LFB. This process could be very powerful. Alan DeKok. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 19 22:07:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15890 for ; Tue, 19 Oct 2004 22:07:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK65I-0003BY-1q for forces-protocol-web-archive@ietf.org; Tue, 19 Oct 2004 22:20:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK45c-0001Sr-0y; Tue, 19 Oct 2004 20:12:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJvOB-0006ez-61 for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 10:55:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03532 for ; Tue, 19 Oct 2004 10:54:55 -0400 (EDT) Received: from [66.46.215.210] (helo=post.ott.idt.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJvaJ-0007oi-KE for forces-protocol@ietf.org; Tue, 19 Oct 2004 11:07:35 -0400 Received: from [127.0.0.1] (dhcp195.ott.idt.com [192.168.102.195]) by post.ott.idt.com (Postfix) with ESMTP id C5C631F0002; Tue, 19 Oct 2004 10:54:26 -0400 (EDT) Message-ID: <417529DC.8000704@idt.com> Date: Tue, 19 Oct 2004 10:51:08 -0400 From: Alan DeKok User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zsolt Haraszti References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <1098113089.2364.12.camel@localhost.localdomain> <1098115003.2884.67.camel@localhost.localdomain> <4173FB88.1000008@idt.com> <1098126011.2884.162.camel@localhost.localdomain> <41741D78.4070205@idt.com> <1098132328.2884.250.camel@localhost.localdomain> In-Reply-To: <1098132328.2884.250.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , "Joel M. Halpern" , forces-protocol@ietf.org, Jamal Hadi Salim , "Steven Blake \(petri-meat\)" , Ellen M Deleganes , Weiming Wang Subject: [Forces-protocol] Re: Data encoding -- first part X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Zsolt Haraszti wrote: >> The problem is that ANSI C struct representation is >>platform-specific. Some platforms can pack multiple 'uint8_t' into a >>32-bit word. Others can't. > > Can you give me an example of a platform where it is not done? DSP's, for one. sizeof(char) == sizeof(short) == sizeof(int) == 8. > Actually, I checked the same simple C test code both on my Intel > and PowerPC hosts, and found that the layout was the same on > both, albeit the bytes ordering _inside_ 32-bit and 16-bit integer > fields were naturally the opposite. Did you use the same compiler? Not that that matters much, the struct packign should be the same across all compilers on the same architecture. Maybe my worries are not relevant. I just remember having problems with this sort of thing in the past. > OK, lets say I was wrong, and the memory layout is (very) > platform-specific. E.g., 64-bit platforms do it differently > than others. That means we cannot come up with a layout that > pleases everyone (every platform). What shall we do then? > > One approach is to screw everyone, but make it a clean design. > E.g., no alignment at all, i.e., only 8-bit alignment. Yuck. > Another approach is to try to be nice to pre-dominant platforms, > and feel sorry for the rest. That sounds like a plan. Alan DeKok. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 19 22:08:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16085 for ; Tue, 19 Oct 2004 22:08:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK66Q-0003FO-6p for forces-protocol-web-archive@ietf.org; Tue, 19 Oct 2004 22:21:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK49V-0002mV-MM; Tue, 19 Oct 2004 20:16:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJvaa-0008AJ-DX for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 11:07:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04995 for ; Tue, 19 Oct 2004 11:07:45 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJvmi-0008JE-10 for forces-protocol@ietf.org; Tue, 19 Oct 2004 11:20:25 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101908101802:33085 ; Tue, 19 Oct 2004 08:10:18 -0700 From: Jamal Hadi Salim To: forces-protocol@ietf.org Organization: Znyx Networks Message-Id: <1098198457.1032.1.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Oct 2004 11:07:37 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/19/2004 08:10:18 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/19/2004 08:10:20 AM, Serialize complete at 10/19/2004 08:10:20 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Forces-protocol] protocol draft editing? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Now that we seem to have made progress on the basics.. Avri, Could you post a URL to the xml docs that we could start editing? We could start with the TODO action items as posted by Hormuzd. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 19 23:54:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23322 for ; Tue, 19 Oct 2004 23:54:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK7lH-0005YV-TR for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 00:07:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4ia-0003mN-Qx; Tue, 19 Oct 2004 20:52:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK0HM-0005At-5d for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 16:08:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07874 for ; Tue, 19 Oct 2004 16:08:13 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK0TW-0000oF-PO for forces-protocol@ietf.org; Tue, 19 Oct 2004 16:20:56 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9JK7bxD078684; Tue, 19 Oct 2004 20:07:37 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9JK7W1S201904; Tue, 19 Oct 2004 22:07:32 +0200 Received: from [9.145.248.133] (sig-9-145-248-133.de.ibm.com [9.145.248.133]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA34022; Tue, 19 Oct 2004 22:07:17 +0200 Message-ID: <417573E8.7070502@zurich.ibm.com> Date: Tue, 19 Oct 2004 22:07:04 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wang,Weiming" Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408> <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> In-Reply-To: <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> X-Spam-Score: 0.5 (/) X-Scan-Signature: f45599941caef2d9ac4ed98df73589d5 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , zsolt@nc.rr.com, "Joel M. Halpern" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0288518029==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: d9951f061208886fc6ada4b24aa6f98d This is a multi-part message in MIME format. --===============0288518029== Content-Type: multipart/alternative; boundary="------------070004090900040600050400" This is a multi-part message in MIME format. --------------070004090900040600050400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.de.ibm.com id i9JK7bxD078684 Content-Transfer-Encoding: quoted-printable I think Zsolt has specified the multicast at LFB Instance-level very=20 well. We had some discussions with Joel a while back and such a table=20 with pointers from a -virtualID- to a list of LFB Instances was=20 considered the way to go. But the subtle difference betwen Zsolt's proposal and the current=20 approach taken in the protocol draft is that the PL-message destination=20 ID is the -virtualID-, instead of introducing a new MIID. See Section 5=20 point g in the protocol draft. I would favor the current approach for the following reasons (but I am=20 not religious and want to hear other opinions): 1) -virtualID- must be unique NE-wide. The PL-level addressing IDs are=20 by definition unique NE-wide. 2) Messages addressed to a group of LFBs that spans FE A and B should=20 not be delivered to FE C. So a PL-level multicasting is anyway needed .=20 Adding an additional MIID would then be redundant. To cover the case of a list of LFB Instances (reminds me of xcast ;-) we=20 can modify the LFBSelect TLV as follows: main hdr (eg type =3D config) | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D target LFB class | | | | | +-- one more LFBInstance(s) =3D target LFB instance(s).=20 [the size of this TLV tells how long the list is] But in the case of a multicast, I would simply drop the LFBSelect TLV alt= ogether as it is redundant (the LFB Instances are already selected by the= -virtualID-). What do you think ? Regards, -Robert Wang,Weiming wrote: >Hormuzd, > >Thanks for reply. > >----- Original Message ----- >From: "Khosravi, Hormuzd M" >Weiming, > >In majority of cases, most of us have only seen single LFB instances on >FEs. >[Weiming] I'm afraid this is not true. From my experience, it's very oft= en we >have more than one instances. > >In any case, your requirement can easily be solved by defining a special >Instance ID for LFBs that addresses all instances of that LFB on the FE. >I thought we already had some text along these lines in the protocol >draft (probably the header section) >[Weiming] Yes, we have proposed using an insatnce broadcast address to a= ddress >all instances. It's useful, but still from my experience, it's not enoug= h. I'v >very often seen the case where there is only one insatnce that has diffe= rent >config requriement than all other instances. > >regards >Hormuzd >p.s. I haven't read Zsolt's email on this yet... > >-----Original Message----- >From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn] >Sent: Monday, October 18, 2004 9:00 PM >To: hadi@znyx.com >Cc: Khosravi, Hormuzd M; ram.gopal@nokia.com; Steven Blake (petri-meat); >Joel M. Halpern; Alan DeKok; zsolt@nc.rr.com; forces-protocol@ietf.org; >Deleganes, Ellen M; Yang, Lily L >Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? > >Jamal,Hormuzd, and Joel, > >I think we have already have the issue as an editorial note as below: > > Editorial Note: > 1. Under discussion is, when an 'FE Protocol >... > > 2. Under discussion is, do we need to support > multiple objects addressing at the LFB Type > and LFB Instance layer? One simple way to > support multiple LFB types or instances is > to use TLVs to identify the group of Type > IDs and Instance IDs, rather than only one > Type and Instance ID. A range of Instance > IDs may also be supported in this way. > >Hormuzd and Joel, do you really think it is not the case? I remember >Joel >supposed there might be thousands of instances with same LFB calss. In >this >case, if we do not support a range of intance addressing, it actually >makes our >protocol unpractical. > >regards, >Weiming > >----- Original Message ----- >From: "Jamal Hadi Salim" > =20 > >>So far you are the second person who has shown desire for this. I was >>the other person; both of us are driven by implementation experience. >>How about we just keep it as a note in the draft for now (for progress >>reasons)? >>Hopefully implementation experience will show the error of whats being >>proposed right now, then we can come back and fix it? >> >>cheers, >>jamal >> >> >>On Mon, 2004-10-18 at 10:20, Weiming Wang wrote: >> =20 >> >>>Hi Jamal, >>> >>>main hdr (eg type =3D config) >>> | >>> | >>> +--- T =3D LFBselect >>> | | >>> | +-- LFBCLASSID =3D target LFB class >>> | | >>> | | >>> | +-- LFBInstance =3D target LFB instance >>> >>>[Weiming] The more I'm thinking, the more I see the value to address >>> =20 >>> >multipul > =20 > >>>LFB instances here (I can now live with single LFB class). To speak >>> =20 >>> >of this, >I > =20 > >>>have an aspire to show my yesterday experience with my GRMP test >>> =20 >>> >platform > =20 > >>>(sorry I have to mention it). As you know, GRMP does not support >>> =20 >>> >multipul >LFB > =20 > >>>instance addressing. Yesterday, we had to prepare a show of the >>> =20 >>> >platform to > =20 > >>>guests from our sponsors. Before the show, we spent near one hour to >>> =20 >>> >operate >on > =20 > >>>the menu to construct a scenario, in which there were 5 output port, >>> =20 >>> >5 > =20 > >>>associated schedulers (LFBs), and several other LFBs that have many >>> =20 >>> >instances. > =20 > >>>unfortunately, we faced a problem with one of the machine. Then we >>> =20 >>> >had to do >it > =20 > >>>again. At that time, I had a VERY VERY strong desire that batch >>> =20 >>> >configuration > =20 > >>>based on multipul LFB isntance addressing can be used. >>> >>>I can see very simple scheme to include multipul instances here (by >>> =20 >>> >ranging, >or > =20 > >>>by enum, or by both). Definitely, I believe this will greatly >>> =20 >>> >improve our > =20 > >>>protocol. >>> >>>I sincerely hope this be considered seriously by gentlemen. >>> >>>Best regards, >>>Weiming >>> >>> | | >>> | | >>> | +-- T =3D operation { ADD, DEL, GET, etc} >>> | | | >>> | | +-- // one or more path targets >>> | | // under discussion >>> | | >>> | +-- T =3D operation { ADD, DEL, GET, etc} >>> | | | >>> | | +-- // one or more path targets >>> | | // under discussion >>> | | >>> | +-- T =3D operation { ADD, DEL, GET, etc} >>> | | | >>> | | +-- // one or more path targets >>> | | // under discussion >>> | | >>> >>>In other words: Very similar to the way we have it already except >>>the naming has changed and we can target multiple >>>operations and multiple paths in an LFB instance >>>----- Original Message ----- >>>From: "Jamal Hadi Salim" >>> =20 >>> >>>>Welcome back Weiming. I have updated the text with the >>>> =20 >>>> >query/response. > =20 > >>>>The only outstanding issue is 6.7. Please weigh in. >>>>I think we are ready top start making updates. >>>> >>>>cheers, >>>>jamal >>>> >>>> =20 >>>> >>> =20 >>> > > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------070004090900040600050400 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
I think Zsolt has specified the multicast at LFB Instance-level very well. We had some discussions with Joel a while back and such a table with pointers from a -virtualID- to a list of LFB Instances was considered the way to go.

But the subtle difference betwen Zsolt's proposal and the current approach taken in the protocol draft is that the PL-message destination ID is the -virtualID-, instead of introducing a new MIID. See Section 5 point g in the protocol draft.

I would favor the current approach for the following reasons (but I am not religious and want to hear other opinions):

1)  -virtualID- must be unique NE-wide. The PL-level addressing IDs are by definition unique NE-wide.

2)  Messages addressed to a group of LFBs that spans FE A and B should not be delivered to FE C. So a PL-level multicasting is anyway needed . Adding an additional MIID would then be redundant.

To cover the case of a list of LFB Instances (reminds me of xcast ;-) we can modify the LFBSelect TLV as follows:
main hdr (eg type = config)
|
+--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = target LFB class
     |        |
     |        |
     |        +-- one more LFBInstance(s) = target LFB instance(s). 
                  [the size of this TLV tells how long the list is]

But in the case of a multicast, I would simply drop the LFBSelect TLV altogether as it is redundant (the LFB Instances are already selected by the -virtualID-). What do you think ?

Regards,
-Robert

Wang,Weiming wrote: 
Hormuzd,

Thanks for reply.

----- Original Message -----
From: "Khosravi, Hormuzd M" <hormuzd.m.khosravi@intel.com>
Weiming,

In majority of cases, most of us have only seen single LFB instances on
FEs.
[Weiming] I'm afraid this is not true. From my experience, it's very often we
have more than  one instances.

In any case, your requirement can easily be solved by defining a special
Instance ID for LFBs that addresses all instances of that LFB on the FE.
I thought we already had some text along these lines in the protocol
draft (probably the header section)
[Weiming] Yes, we have proposed using an insatnce broadcast address to address
all instances. It's useful, but still from my experience, it's not enough. I'v
very often seen the case where there is only one insatnce that has different
config requriement than all other instances.

regards
Hormuzd
p.s. I haven't read Zsolt's email on this yet...

-----Original Message-----
From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn]
Sent: Monday, October 18, 2004 9:00 PM
To: hadi@znyx.com
Cc: Khosravi, Hormuzd M; ram.gopal@nokia.com; Steven Blake (petri-meat);
Joel M. Halpern; Alan DeKok; zsolt@nc.rr.com; forces-protocol@ietf.org;
Deleganes, Ellen M; Yang, Lily L
Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?

Jamal,Hormuzd, and Joel,

I think we have already have the issue as an editorial note as below:

       Editorial Note:
                        1.  Under discussion is, when an 'FE Protocol
...

                        2.  Under discussion is, do we need to support
                            multiple objects addressing at the LFB Type
                            and LFB Instance layer? One simple way to
                            support multiple LFB types or instances is
                            to use TLVs to identify the group of Type
                            IDs and Instance IDs, rather than only one
                            Type and Instance ID.  A range of Instance
                            IDs may also be supported in this way.

Hormuzd and Joel, do you really think it is not the case? I remember
Joel
supposed there might be thousands of instances with same LFB calss.  In
this
case, if we do not support a range of intance addressing, it actually
makes our
protocol unpractical.

regards,
Weiming

----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>
  
So far you are the second person who has shown desire for this. I was
the other person; both of us are driven by implementation experience.
How about we just keep it as a note in the draft for now (for progress
reasons)?
Hopefully implementation experience will show the error of whats being
proposed right now, then we can come back and fix it?

cheers,
jamal


On Mon, 2004-10-18 at 10:20, Weiming Wang wrote:
    
Hi Jamal,

main hdr (eg type = config)
     |
     |
     +--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = target LFB class
     |        |
     |        |
     |        +-- LFBInstance = target LFB instance

[Weiming] The more I'm thinking, the more I see the value to address
      
multipul
  
LFB instances here (I can now live with single LFB class). To speak
      
of this,
I
  
have an aspire  to show my yesterday experience with my GRMP test
      
platform
  
(sorry I have to mention it). As you know, GRMP  does not support
      
multipul
LFB
  
instance addressing.  Yesterday, we had to prepare a show of the
      
platform to
  
guests from our sponsors. Before the show, we spent near one hour to
      
operate
on
  
the menu to construct a scenario, in which there were 5 output port,
      
5
  
associated schedulers (LFBs), and several other LFBs that have many
      
instances.
  
unfortunately, we faced a problem with one of the machine. Then we
      
had to do
it
  
again.  At that time, I had a VERY VERY strong desire that batch
      
configuration
  
based on multipul LFB isntance addressing can be used.

I can see very simple scheme to include multipul instances here (by
      
ranging,
or
  
by enum, or by both). Definitely, I believe this will greatly
      
improve our
  
protocol.

I sincerely hope this be considered seriously by gentlemen.

Best regards,
Weiming

     |        |
     |        |
     |        +-- T = operation { ADD, DEL, GET, etc}
     |        |   |
     |        |   +--  // one or more path targets
     |        |        // under discussion
     |        |
     |        +-- T = operation { ADD, DEL, GET, etc}
     |        |   |
     |        |   +--  // one or more path targets
     |        |        // under discussion
     |        |
     |        +-- T = operation { ADD, DEL, GET, etc}
     |        |   |
     |        |   +--  // one or more path targets
     |        |        // under discussion
     |        |

In other words: Very similar to the way we have it already except
the naming has changed and we can target multiple
operations and multiple paths in an LFB instance
----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>
      
Welcome back Weiming. I have updated the text with the
        
query/response.
  
The only outstanding issue is 6.7. Please weigh in.
I think we are ready top start making updates.

cheers,
jamal

        
      



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



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


  

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------070004090900040600050400-- --===============0288518029== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0288518029==-- From forces-protocol-bounces@ietf.org Tue Oct 19 23:55:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23370 for ; Tue, 19 Oct 2004 23:55:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK7ll-0005Yr-1w for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 00:08:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4ib-0003n8-Hl; Tue, 19 Oct 2004 20:52:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK0He-0005DA-0m for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 16:08:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07892 for ; Tue, 19 Oct 2004 16:08:31 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK0To-0000oc-MA for forces-protocol@ietf.org; Tue, 19 Oct 2004 16:21:13 -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 i9JK80xX085532; Tue, 19 Oct 2004 20:08:00 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9JK7xqT174404; Tue, 19 Oct 2004 22:07:59 +0200 Received: from [9.145.248.133] (sig-9-145-248-133.de.ibm.com [9.145.248.133]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA55126; Tue, 19 Oct 2004 22:07:52 +0200 Message-ID: <41757407.2040007@zurich.ibm.com> Date: Tue, 19 Oct 2004 22:07:35 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model folks References: <468F3FDA28AA87429AD807992E22D07E025791DB@orsmsx408> <1097865957.1036.235.camel@jzny.localdomain> In-Reply-To: <1097865957.1036.235.camel@jzny.localdomain> X-Spam-Score: 0.5 (/) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 Cc: "Khosravi, Hormuzd M" , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1155900408==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d This is a multi-part message in MIME format. --===============1155900408== Content-Type: multipart/alternative; boundary="------------050607070002010304070304" This is a multi-part message in MIME format. --------------050607070002010304070304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.de.ibm.com id i9JK80xX085532 Content-Transfer-Encoding: quoted-printable I hope my note makes it before Jamal's noon ... Finally I got a 3 hours=20 slot on a train ride (with phone off and no email access) to read the=20 threads ... In summary: - I think it is good to keep the query separate from config. Reasons=20 given by Steve/Zsolt sound very valid to me. - I am glad to see the "consolidation" into FE Protocol LFB operations=20 of FE attributes config, FE events, and association maintenance messages. - The heartbeat message is currently not "targeted" at the FE protocol=20 LFB. It is an exception to the rule. The reasoning was to keep such=20 messages as short and simple as possible. Basically, you have the choice=20 between a heartbeat to look like this: main hdr (eg type =3D heartbeat) | | +--- T =3D LFBselect | +-- LFBCLASSID =3D FE Protocol LFB Class (=3D0x01) | | +-- LFBInstance =3D FE Protocol LFB Instance(=3D0x01) or like this: main hdr (eg type =3D heartbeat) The difference is only 6-8 bytes (I don't remember what was the final=20 consensus for the T in the TLV). But as the values in the LFBSelect TLV=20 must ALWAYS be 0x01 and 0x01 (we have statically defined the class and=20 instance ID of the FE protocol LFB), it is a waste to transmit them. And=20 if you do, then someone might use wrong values and then you have to=20 decide how to deal with such cases. Regards, -Robert Jamal Hadi Salim wrote: >On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote: > > =20 > >>Is there a reason you want to keep that type=3Dquery? >>[HK] The responses will be more involved for query,=20 >>also the request might be more involved.=20 >> =20 >> > >This is true. But i dont know how you escape it with any scheme. >If you ask to get, you must specify a path whether you use query or=20 >config. I would think the response will also have a path and the >requested data for that path. > > =20 > >>The other reason is that=20 >>I have never seen query bundled with SET/DEL in practice... >> =20 >> > >I dont either; dont wanna rule it - but the more i think about it the >more i am concluding its just about sending bundled commands. I think >you can not possibly make it any simpler by introducing type=3Dquery. > > =20 > >>Is this a requirement from >>Joel or the Model team ? I didn't get that impression, but I might have >>missed it. >> >> =20 >> > >I cant remember where it came or where the discussion took place. >However, it does make logical sense given now that "everything is an >LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to >the same way: FE->LFBclass->LFBinstance->path >Other than the operator, the operand to a GET is _exactly_ the same >as a DEL. ADD has one extra operand. >So its not really an issue of requirements; but one of a natural fit (as >in the case of SNMP for example) >If you can show that you can get an object easier with type=3Dquery i >think that would help. Otherwise we would have an additional unneeded >message. > > =20 > >>>6.3 -> looks good...we might still need the Flags, also the Event Type >>>is needed since Event Subscribe, UnSubscribe are currently part of >>> =20 >>> >>this >> =20 >> >>>message. >>> =20 >>> >>Probably makes sense to keep event subscription under config. Sorry >>I missed that in my quick scan and thought it belonged to type=3Devent = in >>6.4. >>Do we then need operation =3D Event_un/subscribe [HK] Yes >>I suspect that events will end up being defined in the LFB XML >>definition and therefore will have a path to them (eg link event in por= t >>LFB being path 1.2.3 etc). >>In which case, the value of the Event_un/subscribe will be to the >>event. >>Thoughts? [HK] We could simplify this for generic events, but what >>you're suggesting seems reasonable. >> =20 >> > >I think its safer to have the XML define what those events are. I sent a >query to Joel who will forward it to the model team. He seems to be in >agreement. Note this will be equivalent to SNMP traps (which is defined >in the mib together with other attributes). >As far as i can see, the event is another attribute. So it would look >like: >Operation =3D subscribe; operand =3D eventpath >In our case we should go ahead and choose events that are necessary for >the protocol to function and put them in eitehr the FE object or FE >protocol LFB. The model team can them adapt from them > =20 > =20 > >>>6.6 -> Fine...I am assuming the States will be exchanged in Event msgs >>> =20 >>> >>? >> >>Since everything is an LFB, then its per LFB event - in this case i >>would guess the states will belong to the FE Object LFB?=20 >> >>[HK] Yes they would, I have no objection to FE Object or everything >>being a LFB. The FE States would be part of the FE object sent in Event >>msgs. >> >> =20 >> > >Sounds reasonable. > > =20 > >>>6.7 -> remains the same (I assume) >>> =20 >>> >>I missed that one, sorry. >>Again my take is this is gone. I would think this would per FE >>heartebats belong to the FE Protocol LFB. >>[HK] No, this doesn't need to go, its just a header anyways, it doesn't >>have any TLVs...its a very light weight msg, remember? I think you are >>confusing this with the FE Protocol Object, that doesn't have any effec= t >>on this msg. >> =20 >> > >But who is the target for this message now? >Remember, there MUST be an LFB as the end target. > > =20 > >>I think that the two FE LFBs deserve speacial attention now. >>We need to describe what they are expected to do in more detail. We als= o >>need to sync on them with the model people. >>[HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead >>on defining this >> >> =20 >> > >We may all have to be involved in these two. I think they are very >important that we all need to be involved. > >BTW, Heres a suggestions: > >If we dont hear from anybody by Tuesday(I know Weiming mentioned >something about being back Monday), lets start assuming noone will >and move towards updating the draft to beat the deadline. >I dont think people will mind if they are busy. > >cheers, >jamal > > > > >_______________________________________________ >Forces-protocol mailing list >Forces-protocol@ietf.org >https://www1.ietf.org/mailman/listinfo/forces-protocol > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------050607070002010304070304 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I hope my note makes it before Jamal's noon ... Finally I got a 3 hours slot on a train ride (with phone off and no email access) to read the threads ...

In summary:

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

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

- The heartbeat message is currently not "targeted" at the FE protocol LFB. It is an exception to the rule. The reasoning was to keep such messages as short and simple as possible. Basically, you have the choice between a heartbeat to look like this:
main hdr (eg type = heartbeat)
      |
      |
      +--- T = LFBselect
               |
               +-- LFBCLASSID = FE Protocol LFB Class (=0x01)
               |
               |
               +-- LFBInstance = FE Protocol LFB Instance(=0x01)
or like this:
main hdr (eg type = heartbeat)

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

Regards,
-Robert

Jamal Hadi Salim wrote: 
On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote:

  
Is there a reason you want to keep that type=query?
[HK] The responses will be more involved for query, 
also the request <path> might be more involved. 
    

This is true. But i dont know how you escape it with any scheme.
If you ask to get, you must specify a path whether you use query or 
config. I would think the response will also have a path and the
requested data for that path.

  
The other reason is that 
I have never seen query bundled with SET/DEL in practice...
    

I dont either; dont wanna rule it - but the more i think about it the
more i am concluding its just about sending bundled commands. I think
you can not possibly make it any simpler by introducing type=query.

  
Is this a requirement from
Joel or the Model team ? I didn't get that impression, but I might have
missed it.

    

I cant remember where it came or where the discussion took place.
However, it does make logical sense given now that "everything is an
LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to
the same way: FE->LFBclass->LFBinstance->path
Other than the operator, the operand to a GET is _exactly_ the same
as a DEL. ADD has one extra operand.
So its not really an issue of requirements; but one of a natural fit (as
in the case of SNMP for example)
If you can show that you can get an object easier with type=query i
think that would help. Otherwise we would have an additional unneeded
message.

  
6.3 -> looks good...we might still need the Flags, also the Event Type
is needed since Event Subscribe, UnSubscribe are currently part of
      
this
    
message.
      
Probably makes sense to keep event subscription under config. Sorry
I missed that in my quick scan and thought it belonged to type=event in
6.4.
Do we then need operation = Event_un/subscribe [HK] Yes
I suspect that events will end up being defined in the LFB XML
definition and therefore will have a path to them (eg link event in port
LFB being path 1.2.3 etc).
In which case, the value of the Event_un/subscribe will be to the
event.
Thoughts? [HK] We could simplify this for generic events, but what
you're suggesting seems reasonable.
    

I think its safer to have the XML define what those events are. I sent a
query to Joel who will forward it to the model team. He seems to be in
agreement. Note this will be equivalent to SNMP traps (which is defined
in the mib together with other attributes).
As far as i can see, the event is another attribute. So it would look
like:
Operation = subscribe; operand = eventpath
In our case we should go ahead and choose events that are necessary for
the protocol to function and put them in eitehr the FE object or FE
protocol LFB. The model team can them adapt from them
  
  
6.6 -> Fine...I am assuming the States will be exchanged in Event msgs
      
?

Since everything is an LFB, then its per LFB event - in this case i
would guess the states will belong to the FE Object LFB? 

[HK] Yes they would, I have no objection to FE Object or everything
being a LFB. The FE States would be part of the FE object sent in Event
msgs.

    

Sounds reasonable.

  
6.7 -> remains the same (I assume)
      
I missed that one, sorry.
Again my take is this is gone. I would think this would per FE
heartebats belong to the FE Protocol LFB.
[HK] No, this doesn't need to go, its just a header anyways, it doesn't
have any TLVs...its a very light weight msg, remember? I think you are
confusing this with the FE Protocol Object, that doesn't have any effect
on this msg.
    

But who is the target for this message now?
Remember, there MUST be an LFB as the end target.

  
I think that the two FE LFBs deserve speacial attention now.
We need to describe what they are expected to do in more detail. We also
need to sync on them with the model people.
[HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead
on defining this

    

We may all have to be involved in these two. I think they are very
important that we all need to be involved.

BTW, Heres a suggestions:

If we dont hear from anybody by Tuesday(I know Weiming mentioned
something about being back Monday), lets start assuming noone will
and move towards updating the draft to beat the deadline.
I dont think people will mind if they are busy.

cheers,
jamal




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


  

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------050607070002010304070304-- --===============1155900408== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1155900408==-- From forces-protocol-bounces@ietf.org Wed Oct 20 00:19:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25054 for ; Wed, 20 Oct 2004 00:19:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK88u-0005zY-QL for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 00:32:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4j7-0004dB-RX; Tue, 19 Oct 2004 20:53:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK0UP-0008Gv-Dj for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 16:21:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09322 for ; Tue, 19 Oct 2004 16:21:41 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK0ga-0001Ko-A4 for forces-protocol@ietf.org; Tue, 19 Oct 2004 16:34:25 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101913241472:33554 ; Tue, 19 Oct 2004 13:24:14 -0700 Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model folks From: Jamal Hadi Salim To: Robert Haas In-Reply-To: <41757407.2040007@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E025791DB@orsmsx408> <1097865957.1036.235.camel@jzny.localdomain> <41757407.2040007@zurich.ibm.com> Organization: Znyx Networks Message-Id: <1098217299.1029.63.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Oct 2004 16:21:39 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/19/2004 01:24:15 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/19/2004 01:24:17 PM X-Spam-Score: 2.2 (++) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: "Khosravi, Hormuzd M" , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2114148056==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc --===============2114148056== Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Um9iZXJ0LA0KQ291bGQgc29tZW9uZSBub3Qgc2VuZCBhIGhlYXJ0YmVhdCB0byBhIHNwZWNpZmlj IExGQj8NCkluIHdoaWNoIGNhc2UgYSBoZWFydGJlIHRvIHRoZSBGRSBvYmplY3QgZXF1YXRlcyBh IGhlYXJ0YmVhdCB0byB0aGUgRkUuDQoNCmNoZWVycywNCmphbWFsDQoNCk9uIFR1ZSwgMjAwNC0x MC0xOSBhdCAxNjowNywgUm9iZXJ0IEhhYXMgd3JvdGU6DQo+IEkgaG9wZSBteSBub3RlIG1ha2Vz IGl0IGJlZm9yZSBKYW1hbCdzIG5vb24gLi4uIEZpbmFsbHkgSSBnb3QgYSAzDQo+IGhvdXJzIHNs b3Qgb24gYSB0cmFpbiByaWRlICh3aXRoIHBob25lIG9mZiBhbmQgbm8gZW1haWwgYWNjZXNzKSB0 bw0KPiByZWFkIHRoZSB0aHJlYWRzIC4uLg0KPiANCj4gSW4gc3VtbWFyeToNCj4gDQo+IC0gSSB0 aGluayBpdCBpcyBnb29kIHRvIGtlZXAgdGhlIHF1ZXJ5IHNlcGFyYXRlIGZyb20gY29uZmlnLiBS ZWFzb25zDQo+IGdpdmVuIGJ5IFN0ZXZlL1pzb2x0IHNvdW5kIHZlcnkgdmFsaWQgdG8gbWUuDQo+ IA0KPiAtIEkgYW0gZ2xhZCB0byBzZWUgdGhlICJjb25zb2xpZGF0aW9uIiBpbnRvIEZFIFByb3Rv Y29sIExGQiBvcGVyYXRpb25zDQo+IG9mIEZFIGF0dHJpYnV0ZXMgY29uZmlnLCBGRSBldmVudHMs IGFuZCBhc3NvY2lhdGlvbiBtYWludGVuYW5jZQ0KPiBtZXNzYWdlcy4NCj4gDQo+IC0gVGhlIGhl YXJ0YmVhdCBtZXNzYWdlIGlzIGN1cnJlbnRseSBub3QgInRhcmdldGVkIiBhdCB0aGUgRkUgcHJv dG9jb2wNCj4gTEZCLiBJdCBpcyBhbiBleGNlcHRpb24gdG8gdGhlIHJ1bGUuIFRoZSByZWFzb25p bmcgd2FzIHRvIGtlZXAgc3VjaA0KPiBtZXNzYWdlcyBhcyBzaG9ydCBhbmQgc2ltcGxlIGFzIHBv c3NpYmxlLiBCYXNpY2FsbHksIHlvdSBoYXZlIHRoZQ0KPiBjaG9pY2UgYmV0d2VlbiBhIGhlYXJ0 YmVhdCB0byBsb29rIGxpa2UgdGhpczoNCj4gDQo+IG1haW4gaGRyIChlZyB0eXBlID0gaGVhcnRi ZWF0KQ0KPiAgICAgICB8DQo+ICAgICAgIHwNCj4gICAgICAgKy0tLSBUID0gTEZCc2VsZWN0DQo+ ICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgICAgICAgKy0tIExGQkNMQVNTSUQgPSBGRSBQ cm90b2NvbCBMRkIgQ2xhc3MgKD0weDAxKQ0KPiAgICAgICAgICAgICAgICB8DQo+ICAgICAgICAg ICAgICAgIHwNCj4gICAgICAgICAgICAgICAgKy0tIExGQkluc3RhbmNlID0gRkUgUHJvdG9jb2wg TEZCIEluc3RhbmNlKD0weDAxKQ0KPiBvciBsaWtlIHRoaXM6DQo+IA0KPiBtYWluIGhkciAoZWcg dHlwZSA9IGhlYXJ0YmVhdCkNCj4gVGhlIGRpZmZlcmVuY2UgaXMgb25seSA2LTggYnl0ZXMgKEkg ZG9uJ3QgcmVtZW1iZXIgd2hhdCB3YXMgdGhlIGZpbmFsDQo+IGNvbnNlbnN1cyBmb3IgdGhlIFQg aW4gdGhlIFRMVikuIEJ1dCBhcyB0aGUgdmFsdWVzIGluIHRoZSBMRkJTZWxlY3QNCj4gVExWIG11 c3QgQUxXQVlTIGJlIDB4MDEgYW5kIDB4MDEgKHdlIGhhdmUgc3RhdGljYWxseSBkZWZpbmVkIHRo ZSBjbGFzcw0KPiBhbmQgaW5zdGFuY2UgSUQgb2YgdGhlIEZFIHByb3RvY29sIExGQiksIGl0IGlz IGEgd2FzdGUgdG8gdHJhbnNtaXQNCj4gdGhlbS4gQW5kIGlmIHlvdSBkbywgdGhlbiBzb21lb25l IG1pZ2h0IHVzZSB3cm9uZyB2YWx1ZXMgYW5kIHRoZW4geW91DQo+IGhhdmUgdG8gZGVjaWRlIGhv dyB0byBkZWFsIHdpdGggc3VjaCBjYXNlcy4NCj4gDQo+IFJlZ2FyZHMsDQo+IC1Sb2JlcnQNCj4g DQo+IEphbWFsIEhhZGkgU2FsaW0gd3JvdGU6IA0KPiA+IE9uIEZyaSwgMjAwNC0xMC0xNSBhdCAw MTozMywgS2hvc3JhdmksIEhvcm11emQgTSB3cm90ZToNCj4gPiANCj4gPiAgIA0KPiA+ID4gSXMg dGhlcmUgYSByZWFzb24geW91IHdhbnQgdG8ga2VlcCB0aGF0IHR5cGU9cXVlcnk/DQo+ID4gPiBb SEtdIFRoZSByZXNwb25zZXMgd2lsbCBiZSBtb3JlIGludm9sdmVkIGZvciBxdWVyeSwgDQo+ID4g PiBhbHNvIHRoZSByZXF1ZXN0IDxwYXRoPiBtaWdodCBiZSBtb3JlIGludm9sdmVkLiANCj4gPiA+ ICAgICANCj4gPiANCj4gPiBUaGlzIGlzIHRydWUuIEJ1dCBpIGRvbnQga25vdyBob3cgeW91IGVz Y2FwZSBpdCB3aXRoIGFueSBzY2hlbWUuDQo+ID4gSWYgeW91IGFzayB0byBnZXQsIHlvdSBtdXN0 IHNwZWNpZnkgYSBwYXRoIHdoZXRoZXIgeW91IHVzZSBxdWVyeSBvciANCj4gPiBjb25maWcuIEkg d291bGQgdGhpbmsgdGhlIHJlc3BvbnNlIHdpbGwgYWxzbyBoYXZlIGEgcGF0aCBhbmQgdGhlDQo+ ID4gcmVxdWVzdGVkIGRhdGEgZm9yIHRoYXQgcGF0aC4NCj4gPiANCj4gPiAgIA0KPiA+ID4gVGhl IG90aGVyIHJlYXNvbiBpcyB0aGF0IA0KPiA+ID4gSSBoYXZlIG5ldmVyIHNlZW4gcXVlcnkgYnVu ZGxlZCB3aXRoIFNFVC9ERUwgaW4gcHJhY3RpY2UuLi4NCj4gPiA+ICAgICANCj4gPiANCj4gPiBJ IGRvbnQgZWl0aGVyOyBkb250IHdhbm5hIHJ1bGUgaXQgLSBidXQgdGhlIG1vcmUgaSB0aGluayBh Ym91dCBpdCB0aGUNCj4gPiBtb3JlIGkgYW0gY29uY2x1ZGluZyBpdHMganVzdCBhYm91dCBzZW5k aW5nIGJ1bmRsZWQgY29tbWFuZHMuIEkgdGhpbmsNCj4gPiB5b3UgY2FuIG5vdCBwb3NzaWJseSBt YWtlIGl0IGFueSBzaW1wbGVyIGJ5IGludHJvZHVjaW5nIHR5cGU9cXVlcnkuDQo+ID4gDQo+ID4g ICANCj4gPiA+IElzIHRoaXMgYSByZXF1aXJlbWVudCBmcm9tDQo+ID4gPiBKb2VsIG9yIHRoZSBN b2RlbCB0ZWFtID8gSSBkaWRuJ3QgZ2V0IHRoYXQgaW1wcmVzc2lvbiwgYnV0IEkgbWlnaHQgaGF2 ZQ0KPiA+ID4gbWlzc2VkIGl0Lg0KPiA+ID4gDQo+ID4gPiAgICAgDQo+ID4gDQo+ID4gSSBjYW50 IHJlbWVtYmVyIHdoZXJlIGl0IGNhbWUgb3Igd2hlcmUgdGhlIGRpc2N1c3Npb24gdG9vayBwbGFj ZS4NCj4gPiBIb3dldmVyLCBpdCBkb2VzIG1ha2UgbG9naWNhbCBzZW5zZSBnaXZlbiBub3cgdGhh dCAiZXZlcnl0aGluZyBpcyBhbg0KPiA+IExGQiIgYW5kIHdlIGhhdmUgcGF0aHMgdG8gZ2V0IHRv IG9iamVjdHM7IGkuZSBhbiBBREQsIERFTCBvciBHRVQgZ29lcyB0bw0KPiA+IHRoZSBzYW1lIHdh eTogRkUtPkxGQmNsYXNzLT5MRkJpbnN0YW5jZS0+cGF0aA0KPiA+IE90aGVyIHRoYW4gdGhlIG9w ZXJhdG9yLCB0aGUgb3BlcmFuZCB0byBhIEdFVCBpcyBfZXhhY3RseV8gdGhlIHNhbWUNCj4gPiBh cyBhIERFTC4gQUREIGhhcyBvbmUgZXh0cmEgb3BlcmFuZC4NCj4gPiBTbyBpdHMgbm90IHJlYWxs eSBhbiBpc3N1ZSBvZiByZXF1aXJlbWVudHM7IGJ1dCBvbmUgb2YgYSBuYXR1cmFsIGZpdCAoYXMN Cj4gPiBpbiB0aGUgY2FzZSBvZiBTTk1QIGZvciBleGFtcGxlKQ0KPiA+IElmIHlvdSBjYW4gc2hv dyB0aGF0IHlvdSBjYW4gZ2V0IGFuIG9iamVjdCBlYXNpZXIgd2l0aCB0eXBlPXF1ZXJ5IGkNCj4g PiB0aGluayB0aGF0IHdvdWxkIGhlbHAuIE90aGVyd2lzZSB3ZSB3b3VsZCBoYXZlIGFuIGFkZGl0 aW9uYWwgdW5uZWVkZWQNCj4gPiBtZXNzYWdlLg0KPiA+IA0KPiA+ICAgDQo+ID4gPiA+IDYuMyAt PiBsb29rcyBnb29kLi4ud2UgbWlnaHQgc3RpbGwgbmVlZCB0aGUgRmxhZ3MsIGFsc28gdGhlIEV2 ZW50IFR5cGUNCj4gPiA+ID4gaXMgbmVlZGVkIHNpbmNlIEV2ZW50IFN1YnNjcmliZSwgVW5TdWJz Y3JpYmUgYXJlIGN1cnJlbnRseSBwYXJ0IG9mDQo+ID4gPiA+ICAgICAgIA0KPiA+ID4gDQo+ID4g PiB0aGlzDQo+ID4gPiAgICAgDQo+ID4gPiA+IG1lc3NhZ2UuDQo+ID4gPiA+ICAgICAgIA0KPiA+ ID4gDQo+ID4gPiBQcm9iYWJseSBtYWtlcyBzZW5zZSB0byBrZWVwIGV2ZW50IHN1YnNjcmlwdGlv biB1bmRlciBjb25maWcuIFNvcnJ5DQo+ID4gPiBJIG1pc3NlZCB0aGF0IGluIG15IHF1aWNrIHNj YW4gYW5kIHRob3VnaHQgaXQgYmVsb25nZWQgdG8gdHlwZT1ldmVudCBpbg0KPiA+ID4gNi40Lg0K PiA+ID4gRG8gd2UgdGhlbiBuZWVkIG9wZXJhdGlvbiA9IEV2ZW50X3VuL3N1YnNjcmliZSBbSEtd IFllcw0KPiA+ID4gSSBzdXNwZWN0IHRoYXQgZXZlbnRzIHdpbGwgZW5kIHVwIGJlaW5nIGRlZmlu ZWQgaW4gdGhlIExGQiBYTUwNCj4gPiA+IGRlZmluaXRpb24gYW5kIHRoZXJlZm9yZSB3aWxsIGhh dmUgYSBwYXRoIHRvIHRoZW0gKGVnIGxpbmsgZXZlbnQgaW4gcG9ydA0KPiA+ID4gTEZCIGJlaW5n IHBhdGggMS4yLjMgZXRjKS4NCj4gPiA+IEluIHdoaWNoIGNhc2UsIHRoZSB2YWx1ZSBvZiB0aGUg RXZlbnRfdW4vc3Vic2NyaWJlIHdpbGwgYmUgdG8gdGhlDQo+ID4gPiBldmVudC4NCj4gPiA+IFRo b3VnaHRzPyBbSEtdIFdlIGNvdWxkIHNpbXBsaWZ5IHRoaXMgZm9yIGdlbmVyaWMgZXZlbnRzLCBi dXQgd2hhdA0KPiA+ID4geW91J3JlIHN1Z2dlc3Rpbmcgc2VlbXMgcmVhc29uYWJsZS4NCj4gPiA+ ICAgICANCj4gPiANCj4gPiBJIHRoaW5rIGl0cyBzYWZlciB0byBoYXZlIHRoZSBYTUwgZGVmaW5l IHdoYXQgdGhvc2UgZXZlbnRzIGFyZS4gSSBzZW50IGENCj4gPiBxdWVyeSB0byBKb2VsIHdobyB3 aWxsIGZvcndhcmQgaXQgdG8gdGhlIG1vZGVsIHRlYW0uIEhlIHNlZW1zIHRvIGJlIGluDQo+ID4g YWdyZWVtZW50LiBOb3RlIHRoaXMgd2lsbCBiZSBlcXVpdmFsZW50IHRvIFNOTVAgdHJhcHMgKHdo aWNoIGlzIGRlZmluZWQNCj4gPiBpbiB0aGUgbWliIHRvZ2V0aGVyIHdpdGggb3RoZXIgYXR0cmli dXRlcykuDQo+ID4gQXMgZmFyIGFzIGkgY2FuIHNlZSwgdGhlIGV2ZW50IGlzIGFub3RoZXIgYXR0 cmlidXRlLiBTbyBpdCB3b3VsZCBsb29rDQo+ID4gbGlrZToNCj4gPiBPcGVyYXRpb24gPSBzdWJz Y3JpYmU7IG9wZXJhbmQgPSBldmVudHBhdGgNCj4gPiBJbiBvdXIgY2FzZSB3ZSBzaG91bGQgZ28g YWhlYWQgYW5kIGNob29zZSBldmVudHMgdGhhdCBhcmUgbmVjZXNzYXJ5IGZvcg0KPiA+IHRoZSBw cm90b2NvbCB0byBmdW5jdGlvbiBhbmQgcHV0IHRoZW0gaW4gZWl0ZWhyIHRoZSBGRSBvYmplY3Qg b3IgRkUNCj4gPiBwcm90b2NvbCBMRkIuIFRoZSBtb2RlbCB0ZWFtIGNhbiB0aGVtIGFkYXB0IGZy b20gdGhlbQ0KPiA+ICAgDQo+ID4gICANCj4gPiA+ID4gNi42IC0+IEZpbmUuLi5JIGFtIGFzc3Vt aW5nIHRoZSBTdGF0ZXMgd2lsbCBiZSBleGNoYW5nZWQgaW4gRXZlbnQgbXNncw0KPiA+ID4gPiAg ICAgICANCj4gPiA+IA0KPiA+ID4gPw0KPiA+ID4gDQo+ID4gPiBTaW5jZSBldmVyeXRoaW5nIGlz IGFuIExGQiwgdGhlbiBpdHMgcGVyIExGQiBldmVudCAtIGluIHRoaXMgY2FzZSBpDQo+ID4gPiB3 b3VsZCBndWVzcyB0aGUgc3RhdGVzIHdpbGwgYmVsb25nIHRvIHRoZSBGRSBPYmplY3QgTEZCPyAN Cj4gPiA+IA0KPiA+ID4gW0hLXSBZZXMgdGhleSB3b3VsZCwgSSBoYXZlIG5vIG9iamVjdGlvbiB0 byBGRSBPYmplY3Qgb3IgZXZlcnl0aGluZw0KPiA+ID4gYmVpbmcgYSBMRkIuIFRoZSBGRSBTdGF0 ZXMgd291bGQgYmUgcGFydCBvZiB0aGUgRkUgb2JqZWN0IHNlbnQgaW4gRXZlbnQNCj4gPiA+IG1z Z3MuDQo+ID4gPiANCj4gPiA+ICAgICANCj4gPiANCj4gPiBTb3VuZHMgcmVhc29uYWJsZS4NCj4g PiANCj4gPiAgIA0KPiA+ID4gPiA2LjcgLT4gcmVtYWlucyB0aGUgc2FtZSAoSSBhc3N1bWUpDQo+ ID4gPiA+ICAgICAgIA0KPiA+ID4gDQo+ID4gPiBJIG1pc3NlZCB0aGF0IG9uZSwgc29ycnkuDQo+ ID4gPiBBZ2FpbiBteSB0YWtlIGlzIHRoaXMgaXMgZ29uZS4gSSB3b3VsZCB0aGluayB0aGlzIHdv dWxkIHBlciBGRQ0KPiA+ID4gaGVhcnRlYmF0cyBiZWxvbmcgdG8gdGhlIEZFIFByb3RvY29sIExG Qi4NCj4gPiA+IFtIS10gTm8sIHRoaXMgZG9lc24ndCBuZWVkIHRvIGdvLCBpdHMganVzdCBhIGhl YWRlciBhbnl3YXlzLCBpdCBkb2Vzbid0DQo+ID4gPiBoYXZlIGFueSBUTFZzLi4uaXRzIGEgdmVy eSBsaWdodCB3ZWlnaHQgbXNnLCByZW1lbWJlcj8gSSB0aGluayB5b3UgYXJlDQo+ID4gPiBjb25m dXNpbmcgdGhpcyB3aXRoIHRoZSBGRSBQcm90b2NvbCBPYmplY3QsIHRoYXQgZG9lc24ndCBoYXZl IGFueSBlZmZlY3QNCj4gPiA+IG9uIHRoaXMgbXNnLg0KPiA+ID4gICAgIA0KPiA+IA0KPiA+IEJ1 dCB3aG8gaXMgdGhlIHRhcmdldCBmb3IgdGhpcyBtZXNzYWdlIG5vdz8NCj4gPiBSZW1lbWJlciwg dGhlcmUgTVVTVCBiZSBhbiBMRkIgYXMgdGhlIGVuZCB0YXJnZXQuDQo+ID4gDQo+ID4gICANCj4g PiA+IEkgdGhpbmsgdGhhdCB0aGUgdHdvIEZFIExGQnMgZGVzZXJ2ZSBzcGVhY2lhbCBhdHRlbnRp b24gbm93Lg0KPiA+ID4gV2UgbmVlZCB0byBkZXNjcmliZSB3aGF0IHRoZXkgYXJlIGV4cGVjdGVk IHRvIGRvIGluIG1vcmUgZGV0YWlsLiBXZSBhbHNvDQo+ID4gPiBuZWVkIHRvIHN5bmMgb24gdGhl bSB3aXRoIHRoZSBtb2RlbCBwZW9wbGUuDQo+ID4gPiBbSEtdIFN1cmUsIGFncmVlIG9uIHRoaXMu Lkkgd2FzIGhvcGluZyBSb2JlcnQvV2VpbWluZyB3aWxsIHRha2UgYSBsZWFkDQo+ID4gPiBvbiBk ZWZpbmluZyB0aGlzDQo+ID4gPiANCj4gPiA+ICAgICANCj4gPiANCj4gPiBXZSBtYXkgYWxsIGhh dmUgdG8gYmUgaW52b2x2ZWQgaW4gdGhlc2UgdHdvLiBJIHRoaW5rIHRoZXkgYXJlIHZlcnkNCj4g PiBpbXBvcnRhbnQgdGhhdCB3ZSBhbGwgbmVlZCB0byBiZSBpbnZvbHZlZC4NCj4gPiANCj4gPiBC VFcsIEhlcmVzIGEgc3VnZ2VzdGlvbnM6DQo+ID4gDQo+ID4gSWYgd2UgZG9udCBoZWFyIGZyb20g YW55Ym9keSBieSBUdWVzZGF5KEkga25vdyBXZWltaW5nIG1lbnRpb25lZA0KPiA+IHNvbWV0aGlu ZyBhYm91dCBiZWluZyBiYWNrIE1vbmRheSksIGxldHMgc3RhcnQgYXNzdW1pbmcgbm9vbmUgd2ls bA0KPiA+IGFuZCBtb3ZlIHRvd2FyZHMgdXBkYXRpbmcgdGhlIGRyYWZ0IHRvIGJlYXQgdGhlIGRl YWRsaW5lLg0KPiA+IEkgZG9udCB0aGluayBwZW9wbGUgd2lsbCBtaW5kIGlmIHRoZXkgYXJlIGJ1 c3kuDQo+ID4gDQo+ID4gY2hlZXJzLA0KPiA+IGphbWFsDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4g DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBGb3JjZXMtcHJvdG9jb2wgbWFpbGluZyBsaXN0DQo+ID4gRm9yY2VzLXByb3RvY29sQGlldGYu b3JnDQo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzLXBy b3RvY29sDQo+ID4gDQo+ID4gDQo+ID4gICANCj4gDQo+IA0KPiAtLSANCj4gUm9iZXJ0IEhhYXMN Cj4gSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5DQo+IFPkdW1lcnN0cmFzc2UgNA0KPiBD SC04ODAzIFL8c2NobGlrb24vU3dpdHplcmxhbmQNCj4gcGhvbmUgKzQxLTEtNzI0LTg2OTggIGZh eCArNDEtMS03MjQtODU3OCAgaHR0cDovL3d3dy56dXJpY2guaWJtLmNvbS9+cmhhDQoNCg== --===============2114148056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============2114148056==-- From forces-protocol-bounces@ietf.org Wed Oct 20 00:49:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27622 for ; Wed, 20 Oct 2004 00:49:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK8bb-0006p6-Uh for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 01:01:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4nX-0003xZ-8S; Tue, 19 Oct 2004 20:57:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK3KO-0000ZK-Cb for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 19:23:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00316 for ; Tue, 19 Oct 2004 19:23:37 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK3Wf-00075D-Ks for forces-protocol@ietf.org; Tue, 19 Oct 2004 19:36:22 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004101916261001:33772 ; Tue, 19 Oct 2004 16:26:10 -0700 From: Jamal Hadi Salim To: forces-protocol@ietf.org, avri@psg.com In-Reply-To: <1098198457.1032.1.camel@jzny.localdomain> References: <1098198457.1032.1.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1098228213.1044.56.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Oct 2004 19:23:33 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/19/2004 04:26:10 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/19/2004 04:26:12 PM, Serialize complete at 10/19/2004 04:26:12 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Hormuzd M , ram.gopal@nokia.com, Ligang Dong , Weiming Wang , Robert Haas Subject: [Forces-protocol] Re: protocol draft editing? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote: > Now that we seem to have made progress on the basics.. > Avri, > Could you post a URL to the xml docs that we could start editing? > We could start with the TODO action items as posted by Hormuzd. > > cheers, > jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 20 04:27:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09805 for ; Wed, 20 Oct 2004 04:26:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKC0W-0002Us-KG for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 04:39:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK9Lw-0005B4-IP; Wed, 20 Oct 2004 01:49:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK7x1-0003HN-MZ for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 00:19:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25078 for ; Wed, 20 Oct 2004 00:19:43 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CK899-0005yy-1I for forces-protocol@ietf.org; Wed, 20 Oct 2004 00:32:31 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Wed, 20 Oct 2004 12:37:38 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Wed, 20 Oct 2004 12:14:26 +0800 Message-ID: <054301c4b65b$96a52120$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Robert Haas" References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408><04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> <417573E8.7070502@zurich.ibm.com> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Wed, 20 Oct 2004 12:16:34 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, zsolt@nc.rr.com, "Joel M. Halpern" , hadi@znyx.com, Alan DeKok , forces-protocol@ietf.org, "Steven Blake \(petri-meat\)" , "Deleganes, Ellen M" , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Hi Robert, >To cover the case of a list of LFB Instances (reminds me of xcast ;-) we can modify the LFBSelect TLV as follows: > >main hdr (eg type = config) >| >+--- T = LFBselect > | | > | +-- LFBCLASSID = target LFB class > | | > | | > | +-- one more LFBInstance(s) = target LFB instance(s). > [the size of this TLV tells how long the list is] [Weiming]That's just the point I propose. I can see the TLV with three more types (the types can firther be represented by tags or purely by different TLV type): 1. List of Instances The V format is a list of instances, as InstanceId1, Instance Id 2, ... Instance Id N, representing to address the insatnces individually 2. A range of Insatnces The V format is a range of Insatnce, as InsatnceId1, Instance Id2, representing to addresss insatnces from Id1 to Id2. 3. A combination of above two. We may use some flags to represent if it is for individual instance or for range instance description. [/Weiming] But in the case of a multicast, I would simply drop the LFBSelect TLV altogether as it is redundant (the LFB Instances are already selected by the -virtualID-). What do you think ? [Weiming] I just think the virtualID scheme and the above explicit ID (real ID) scheme are all necessary. virtualID multicast can address comparatively infrequent change LFB groups, while real ID mulitpul addressing can address some instant and frequent changed LFB groups. Thank you for the post. Weiming Regards, -Robert Wang,Weiming wrote: Hormuzd, Thanks for reply. ----- Original Message ----- From: "Khosravi, Hormuzd M" Weiming, In majority of cases, most of us have only seen single LFB instances on FEs. [Weiming] I'm afraid this is not true. From my experience, it's very often we have more than one instances. In any case, your requirement can easily be solved by defining a special Instance ID for LFBs that addresses all instances of that LFB on the FE. I thought we already had some text along these lines in the protocol draft (probably the header section) [Weiming] Yes, we have proposed using an insatnce broadcast address to address all instances. It's useful, but still from my experience, it's not enough. I'v very often seen the case where there is only one insatnce that has different config requriement than all other instances. regards Hormuzd p.s. I haven't read Zsolt's email on this yet... -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn] Sent: Monday, October 18, 2004 9:00 PM To: hadi@znyx.com Cc: Khosravi, Hormuzd M; ram.gopal@nokia.com; Steven Blake (petri-meat); Joel M. Halpern; Alan DeKok; zsolt@nc.rr.com; forces-protocol@ietf.org; Deleganes, Ellen M; Yang, Lily L Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Jamal,Hormuzd, and Joel, I think we have already have the issue as an editorial note as below: Editorial Note: 1. Under discussion is, when an 'FE Protocol ... 2. Under discussion is, do we need to support multiple objects addressing at the LFB Type and LFB Instance layer? One simple way to support multiple LFB types or instances is to use TLVs to identify the group of Type IDs and Instance IDs, rather than only one Type and Instance ID. A range of Instance IDs may also be supported in this way. Hormuzd and Joel, do you really think it is not the case? I remember Joel supposed there might be thousands of instances with same LFB calss. In this case, if we do not support a range of intance addressing, it actually makes our protocol unpractical. regards, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" So far you are the second person who has shown desire for this. I was the other person; both of us are driven by implementation experience. How about we just keep it as a note in the draft for now (for progress reasons)? Hopefully implementation experience will show the error of whats being proposed right now, then we can come back and fix it? cheers, jamal On Mon, 2004-10-18 at 10:20, Weiming Wang wrote: Hi Jamal, main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance [Weiming] The more I'm thinking, the more I see the value to address multipul LFB instances here (I can now live with single LFB class). To speak of this, I have an aspire to show my yesterday experience with my GRMP test platform (sorry I have to mention it). As you know, GRMP does not support multipul LFB instance addressing. Yesterday, we had to prepare a show of the platform to guests from our sponsors. Before the show, we spent near one hour to operate on the menu to construct a scenario, in which there were 5 output port, 5 associated schedulers (LFBs), and several other LFBs that have many instances. unfortunately, we faced a problem with one of the machine. Then we had to do it again. At that time, I had a VERY VERY strong desire that batch configuration based on multipul LFB isntance addressing can be used. I can see very simple scheme to include multipul instances here (by ranging, or by enum, or by both). Definitely, I believe this will greatly improve our protocol. I sincerely hope this be considered seriously by gentlemen. Best regards, Weiming | | | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | | +-- T = operation { ADD, DEL, GET, etc} | | | | | +-- // one or more path targets | | // under discussion | | In other words: Very similar to the way we have it already except the naming has changed and we can target multiple operations and multiple paths in an LFB instance ----- Original Message ----- From: "Jamal Hadi Salim" Welcome back Weiming. I have updated the text with the query/response. The only outstanding issue is 6.7. Please weigh in. I think we are ready top start making updates. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol -- Robert Haas IBM Zurich Research Laboratory Säumerstrasse 4 CH-8803 Rüschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 20 05:24:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13695 for ; Wed, 20 Oct 2004 05:24:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKCuX-0003ew-Lj for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 05:37:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK9JD-0003mc-55; Wed, 20 Oct 2004 01:46:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK6LJ-0007Cx-C0 for forces-protocol@megatron.ietf.org; Tue, 19 Oct 2004 22:36:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18369 for ; Tue, 19 Oct 2004 22:36:42 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CK6WV-0003uP-Ez for forces-protocol@ietf.org; Tue, 19 Oct 2004 22:49:28 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Wed, 20 Oct 2004 10:53:43 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Wed, 20 Oct 2004 10:30:32 +0800 Message-ID: <050c01c4b64d$12c9f960$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , , "Khosravi, Hormuzd M" References: <1098198457.1032.1.camel@jzny.localdomain> Subject: Re: [Forces-protocol] protocol draft editing? Date: Wed, 20 Oct 2004 10:32:39 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 That's the point. One followed point is the BNF or bitmap. I'm ok with both. What's your idea, Hormuzd and other guys? weiming ----- Original Message ----- From: "Jamal Hadi Salim" To: Sent: Tuesday, October 19, 2004 11:07 PM Subject: [Forces-protocol] protocol draft editing? > > Now that we seem to have made progress on the basics.. > Avri, > Could you post a URL to the xml docs that we could start editing? > We could start with the TODO action items as posted by Hormuzd. > > cheers, > jamal > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 20 05:29:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14243 for ; Wed, 20 Oct 2004 05:29:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKCzO-0003ox-5W for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 05:42:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKBQd-00032Q-7W; Wed, 20 Oct 2004 04:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK9Vc-0006ob-Uk for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 01:59:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03689 for ; Wed, 20 Oct 2004 01:59:34 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK9hr-0008Vj-NW for forces-protocol@ietf.org; Wed, 20 Oct 2004 02:12:22 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CK9VS-0005d6-FD for forces-protocol@ietf.org; Wed, 20 Oct 2004 01:59:31 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Wed, 20 Oct 2004 14:17:54 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Wed, 20 Oct 2004 13:54:41 +0800 Message-ID: <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , "Joel M. Halpern" References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408><002d01c4b50b$1ecc9c10$020aa8c0@wwm1><1098102734.1042.134.camel@jzny.localdomain><013101c4b51d$a50761e0$020aa8c0@wwm1><1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Wed, 20 Oct 2004 13:56:50 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, zsolt@nc.rr.com, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Joel, ----- Original Message ----- From: "Joel M. Halpern" Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? > I do think that there may be thousands of instances. > I do not think that this requires multiple addressing. > > I think that there are some interesting cases prompted by the possibility > of very large numbers of LFBs, but they do not drive multiple addressing. > > My reasoning is based on the following premise. > Firstly, if there are many LFBinstances s of a class, then it is likely > that many fields of the LFB instances will be the same, but it is extremely > unlikely that all fields of the LFB instances will be the same. [Weiming]That's just why explicit multipul addressing is needed. For the case of fields of all LFBinsatnces are the same, we can simply use a broadcast to do so. Let me try to show a scenario why multipul addressing is needed for different fields case. Firstly, because we have assumed the 16bit insatnce Id is not enough, we can reasonably assmue there is a case where there are 64k or more instances (say 64k). Further, we suppose Id1 to Id32k need to config parameter 1, Id(32k+1) to Id 64k to set parameter2. Then, by using single instance addressing, the protocol becomes horrible, either using one message or using separate messages. I just show the one message case. The message format would like like: Msghdr LFBselect LFBClassID Instance ID1 Parameter1 Instance ID2 Parameter1 ... ... Instance ID 32k Parameter1 Insatnce ID (32k+1) Parameter2 .... Instance ID 64k Parameter 2 Remember we then have 64k pair of instance and parameter in the protocol text. In some cases, I'm just worried this make protocol unpractical. By using multipul addressing, the only text is as: Msghdr LFBselect LFBClassID Instance ID1 to ID 32k Parameter1 Instance ID (32k+1) to ID 64k Parameter2 By using multicast scheme supposed by Zsolt, I suppose we need following steps: 1. send a FE attribute to FE object to setup a virtualID1 for Instance 1 to Instance 32k 2. send a FE attribute to FE object to setup a virtualID2 for Instance (32k+1) to Instance 64k 3. config: Msghdr LFBselect LFBClassID Virtual ID1 Parameter1 Virtual ID2 Parameter2 4. send a message to release virtual ID1 5. send a message to release virtual ID2 I can see the advatage of above explicit multipul addressing scheme very clearly. > The simplest case to understand when one would need to setup all those LFBs > at once is in a power recovery situation (the FE lost power, then > recovered to an empty state.) The CE needs to send the configuration > information to the FE. [Weiming]Yes, that's the one case but not the only. > Secondly, I believe that transaction count is much more important than data > volume. The FE is going to have to set every field in every LFB. Encoding > is not going to change that. [Weiming]I'm not sure if you mean for every operation, we should maintain a transaction count. If is, then I have to say our current one message with multiple Operation definitions has already be against the requirement. My opinion is transaction maintenance is moderate, while multicast and multiple operation are more important. > Given that there are distinct values in each LFB instance, there must be an > operation against each LFB instance. I don't think multicast will loose operation individuality. > > The marginal gain from having a single transaction to update the identical > fields, and then individual transactions for the distinct fields is very > small. It does not reduce the number of IOs or the core transaction rate. [Weiming]At least it saves bits greatly and makes protocol practical. Remember the capability between CE and FE are quite limited, especially in muli-hop ForCES application. > > If it is desired to optimize for this case, we may want to introduce (in a > future version of the protocol) some kind of block checkpoint / restart > mechanism. The CE would record its full state about the FE, and then ask > the FE for a dump suitable for restoral of the FE state. Upon restart, the > CE would rebuild its state from its stored representation, and would ship > the dump back to the FE to enable efficient rebuilding there. I can see > significant value in such a mechanism. I do not however see a need to > include this in the first deliverable of the protocol. [Weiming]I suppose this is only for restart case, I can see many cases where multiple addressing can apply, such as delete, change of LFB parameter, load and unload of LFBs, etc. And also I think the scheme above is much more complex than multiple addressing. So, my conclusion is, with a little bit expansion, we can gain much, then why not we adpot it? Best regards, Weiming > > Yours, > Joel M. Halpern _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 20 05:30:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14271 for ; Wed, 20 Oct 2004 05:30:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKCzd-0003pJ-TA for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 05:42:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKBQg-00032w-3W; Wed, 20 Oct 2004 04:02:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK9Yk-0008A5-3Q for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 02:02:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05741 for ; Wed, 20 Oct 2004 02:02:42 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK9ku-00006m-S1 for forces-protocol@ietf.org; Wed, 20 Oct 2004 02:15:30 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9K65xbh007186; Wed, 20 Oct 2004 06:05:59 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9K65JUL023089; Wed, 20 Oct 2004 06:05:43 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004101923020504367 ; Tue, 19 Oct 2004 23:02:05 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 23:02:05 -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 Subject: RE: [Forces-protocol] protocol draft editing? Date: Tue, 19 Oct 2004 23:01:45 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791EF@orsmsx408> Thread-Topic: [Forces-protocol] protocol draft editing? Thread-Index: AcS2TXtMui0oLE+zQ2ulHNCJOF+GkwAHK1ww From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , , X-OriginalArrivalTime: 20 Oct 2004 06:02:05.0592 (UTC) FILETIME=[53710180:01C4B66A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Weiming, I think we should have both, it wouldn't harm. Regards Hormuzd -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn]=20 That's the point. One followed point is the BNF or bitmap. I'm ok with both. What's your idea, Hormuzd and other guys? weiming ----- Original Message ----- From: "Jamal Hadi Salim" > > Now that we seem to have made progress on the basics.. > Avri, > Could you post a URL to the xml docs that we could start editing? > We could start with the TODO action items as posted by Hormuzd. > > cheers, > jamal > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 20 07:48:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24623 for ; Wed, 20 Oct 2004 07:48:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKF9H-0006kY-06 for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 08:00:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKDjz-0000cH-N3; Wed, 20 Oct 2004 06:30:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKCqH-00058U-3c for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 05:33:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14556 for ; Wed, 20 Oct 2004 05:33:05 -0400 (EDT) From: ram.gopal@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKD2Y-0003te-VL for forces-protocol@ietf.org; Wed, 20 Oct 2004 05:45:56 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9K9Wrh00430; Wed, 20 Oct 2004 12:32:53 +0300 (EET DST) X-Scanned: Wed, 20 Oct 2004 12:30:32 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9K9UWV2024517; Wed, 20 Oct 2004 12:30:32 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00lXX8S6; Wed, 20 Oct 2004 12:30:30 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9K9UMa16219; Wed, 20 Oct 2004 12:30:22 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 20 Oct 2004 04:30:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Forces-protocol] RE: sync with BNF as discussed with model folks Date: Wed, 20 Oct 2004 05:30:19 -0400 Message-ID: Thread-Topic: [Forces-protocol] RE: sync with BNF as discussed with model folks thread-index: AcS2WPf61RxZ3ee/TxeLe07+fv7PuAALY7dQ To: , , X-OriginalArrivalTime: 20 Oct 2004 09:30:22.0026 (UTC) FILETIME=[6BE582A0:01C4B687] X-Spam-Score: 0.9 (/) X-Scan-Signature: 8279e2b0006e70acac79ca9454596384 Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1979272838==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: c52a6b2685a9a1f963a24bd74e30b072 This is a multi-part message in MIME format. --===============1979272838== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B687.6A30F04C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B687.6A30F04C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 Agree. Keeping config and query makes simpler. =20 But another point is forces is mostly going to be used as configuration = protocol, in may case GET/(and SET) as automatic=20 may be ideal one.(SET operation is optional). Are we are not going to = accommodate command bundling, this discussion thread is converging well, = may its a correct place to=20 resolve that also. =20 =20 =20 If if I recollect correctly, in one of the teleconference - the issue of = command this issue was popped and was didn't got time to resolve. =20 =20 regards ramg -----Original Message----- From: forces-protocol-bounces@ietf.org = [mailto:forces-protocol-bounces@ietf.org]On Behalf Of ext Robert Haas Sent: Tuesday, October 19, 2004 4:08 PM To: hadi@znyx.com Cc: Khosravi, Hormuzd M; forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model = folks I hope my note makes it before Jamal's noon ... Finally I got a 3 hours = slot on a train ride (with phone off and no email access) to read the = threads ... In summary: - I think it is good to keep the query separate from config. Reasons = given by Steve/Zsolt sound very valid to me. - I am glad to see the "consolidation" into FE Protocol LFB operations = of FE attributes config, FE events, and association maintenance = messages. - The heartbeat message is currently not "targeted" at the FE protocol = LFB. It is an exception to the rule. The reasoning was to keep such = messages as short and simple as possible. Basically, you have the choice = between a heartbeat to look like this: main hdr (eg type =3D heartbeat) | | +--- T =3D LFBselect | +-- LFBCLASSID =3D FE Protocol LFB Class (=3D0x01) | | +-- LFBInstance =3D FE Protocol LFB Instance(=3D0x01) or like this: main hdr (eg type =3D heartbeat) The difference is only 6-8 bytes (I don't remember what was the final = consensus for the T in the TLV). But as the values in the LFBSelect TLV = must ALWAYS be 0x01 and 0x01 (we have statically defined the class and = instance ID of the FE protocol LFB), it is a waste to transmit them. And = if you do, then someone might use wrong values and then you have to = decide how to deal with such cases. Regards, -Robert Jamal Hadi Salim wrote:=20 On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote: =20 Is there a reason you want to keep that type=3Dquery? [HK] The responses will be more involved for query,=20 also the request might be more involved.=20 =20 This is true. But i dont know how you escape it with any scheme. If you ask to get, you must specify a path whether you use query or=20 config. I would think the response will also have a path and the requested data for that path. =20 The other reason is that=20 I have never seen query bundled with SET/DEL in practice... =20 I dont either; dont wanna rule it - but the more i think about it the more i am concluding its just about sending bundled commands. I think you can not possibly make it any simpler by introducing type=3Dquery. =20 Is this a requirement from Joel or the Model team ? I didn't get that impression, but I might have missed it. =20 I cant remember where it came or where the discussion took place. However, it does make logical sense given now that "everything is an LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to the same way: FE->LFBclass->LFBinstance->path Other than the operator, the operand to a GET is _exactly_ the same as a DEL. ADD has one extra operand. So its not really an issue of requirements; but one of a natural fit (as in the case of SNMP for example) If you can show that you can get an object easier with type=3Dquery i think that would help. Otherwise we would have an additional unneeded message. =20 6.3 -> looks good...we might still need the Flags, also the Event Type is needed since Event Subscribe, UnSubscribe are currently part of =20 this =20 message. =20 Probably makes sense to keep event subscription under config. Sorry I missed that in my quick scan and thought it belonged to type=3Devent = in 6.4. Do we then need operation =3D Event_un/subscribe [HK] Yes I suspect that events will end up being defined in the LFB XML definition and therefore will have a path to them (eg link event in port LFB being path 1.2.3 etc). In which case, the value of the Event_un/subscribe will be to the event. Thoughts? [HK] We could simplify this for generic events, but what you're suggesting seems reasonable. =20 I think its safer to have the XML define what those events are. I sent a query to Joel who will forward it to the model team. He seems to be in agreement. Note this will be equivalent to SNMP traps (which is defined in the mib together with other attributes). As far as i can see, the event is another attribute. So it would look like: Operation =3D subscribe; operand =3D eventpath In our case we should go ahead and choose events that are necessary for the protocol to function and put them in eitehr the FE object or FE protocol LFB. The model team can them adapt from them =20 =20 6.6 -> Fine...I am assuming the States will be exchanged in Event msgs =20 ? Since everything is an LFB, then its per LFB event - in this case i would guess the states will belong to the FE Object LFB?=20 [HK] Yes they would, I have no objection to FE Object or everything being a LFB. The FE States would be part of the FE object sent in Event msgs. =20 Sounds reasonable. =20 6.7 -> remains the same (I assume) =20 I missed that one, sorry. Again my take is this is gone. I would think this would per FE heartebats belong to the FE Protocol LFB. [HK] No, this doesn't need to go, its just a header anyways, it doesn't have any TLVs...its a very light weight msg, remember? I think you are confusing this with the FE Protocol Object, that doesn't have any effect on this msg. =20 But who is the target for this message now? Remember, there MUST be an LFB as the end target. =20 I think that the two FE LFBs deserve speacial attention now. We need to describe what they are expected to do in more detail. We also need to sync on them with the model people. [HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead on defining this =20 We may all have to be involved in these two. I think they are very important that we all need to be involved. BTW, Heres a suggestions: If we dont hear from anybody by Tuesday(I know Weiming mentioned something about being back Monday), lets start assuming noone will and move towards updating the draft to beat the deadline. I dont think people will mind if they are busy. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol =20 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 = http://www.zurich.ibm.com/~rha ------_=_NextPart_001_01C4B687.6A30F04C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
Agree.=20 Keeping config and query makes simpler.
 
But=20 another point is forces is mostly going to be used as configuration = protocol, in=20 may case GET/(and SET) as automatic
may be=20 ideal one.(SET operation is optional). Are we are not going to = accommodate=20 command bundling, this discussion thread is converging well, may its a = correct=20 place to
resolve that also.
 
 
 
If if=20 I recollect correctly, in one of the teleconference - the issue of = command this=20 issue was popped and was didn't got time to resolve.
 
 
regards
ramg
-----Original Message-----
From:=20 forces-protocol-bounces@ietf.org = [mailto:forces-protocol-bounces@ietf.org]On=20 Behalf Of ext Robert Haas
Sent: Tuesday, October 19, 2004 = 4:08=20 PM
To: hadi@znyx.com
Cc: Khosravi, Hormuzd M;=20 forces-protocol@ietf.org
Subject: Re: [Forces-protocol] RE: = sync with=20 BNF as discussed with model folks

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

In = summary:

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

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

- The heartbeat = message is=20 currently not "targeted" at the FE protocol LFB. It is an exception to = the rule.=20 The reasoning was to keep such messages as short and simple as possible. = Basically, you have the choice between a heartbeat to look like = this:
main hdr (eg type =3D heartbeat)
      |
      |
      +--- T =3D LFBselect
               |
               +-- LFBCLASSID =3D =
FE Protocol LFB Class (=3D0x01)
               |
               |
               +-- LFBInstance =3D =
FE Protocol LFB Instance(=3D0x01)
or=20 like this:
main hdr (eg type =3D =
heartbeat)

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

Regards,
-Robert

Jamal Hadi Salim wrote:=20 
On Fri, 2004-10-15 at 01:33, Khosravi, =
Hormuzd M wrote:

  
Is there a reason you want to =
keep that type=3Dquery?
[HK] The responses will be more involved for query,=20
also the request <path> might be more involved.=20
    

This is true. But i dont know how you escape it with any scheme.
If you ask to get, you must specify a path whether you use query or=20
config. I would think the response will also have a path and the
requested data for that path.

  
The other reason is that=20
I have never seen query bundled with SET/DEL in practice...
    

I dont either; dont wanna rule it - but the more i think about it the
more i am concluding its just about sending bundled commands. I think
you can not possibly make it any simpler by introducing type=3Dquery.

  
Is this a requirement from
Joel or the Model team ? I didn't get that impression, but I might have
missed it.

    

I cant remember where it came or where the discussion took place.
However, it does make logical sense given now that "everything is an
LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to
the same way: FE->LFBclass->LFBinstance->path
Other than the operator, the operand to a GET is _exactly_ the same
as a DEL. ADD has one extra operand.
So its not really an issue of requirements; but one of a natural fit (as
in the case of SNMP for example)
If you can show that you can get an object easier with type=3Dquery i
think that would help. Otherwise we would have an additional unneeded
message.

  
6.3 -> looks good...we =
might still need the Flags, also the Event Type
is needed since Event Subscribe, UnSubscribe are currently part of
      
this
    
message.
      
Probably makes sense to keep =
event subscription under config. Sorry
I missed that in my quick scan and thought it belonged to type=3Devent =
in
6.4.
Do we then need operation =3D Event_un/subscribe [HK] Yes
I suspect that events will end up being defined in the LFB XML
definition and therefore will have a path to them (eg link event in port
LFB being path 1.2.3 etc).
In which case, the value of the Event_un/subscribe will be to the
event.
Thoughts? [HK] We could simplify this for generic events, but what
you're suggesting seems reasonable.
    

I think its safer to have the XML define what those events are. I sent a
query to Joel who will forward it to the model team. He seems to be in
agreement. Note this will be equivalent to SNMP traps (which is defined
in the mib together with other attributes).
As far as i can see, the event is another attribute. So it would look
like:
Operation =3D subscribe; operand =3D eventpath
In our case we should go ahead and choose events that are necessary for
the protocol to function and put them in eitehr the FE object or FE
protocol LFB. The model team can them adapt from them
 =20
  
6.6 -> Fine...I am =
assuming the States will be exchanged in Event msgs
      
?

Since everything is an LFB, then its per LFB event - in this case i
would guess the states will belong to the FE Object LFB?=20

[HK] Yes they would, I have no objection to FE Object or everything
being a LFB. The FE States would be part of the FE object sent in Event
msgs.

    

Sounds reasonable.

  
6.7 -> remains the same =
(I assume)
      
I missed that one, sorry.
Again my take is this is gone. I would think this would per FE
heartebats belong to the FE Protocol LFB.
[HK] No, this doesn't need to go, its just a header anyways, it doesn't
have any TLVs...its a very light weight msg, remember? I think you are
confusing this with the FE Protocol Object, that doesn't have any effect
on this msg.
    

But who is the target for this message now?
Remember, there MUST be an LFB as the end target.

  
I think that the two FE LFBs =
deserve speacial attention now.
We need to describe what they are expected to do in more detail. We also
need to sync on them with the model people.
[HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead
on defining this

    

We may all have to be involved in these two. I think they are very
important that we all need to be involved.

BTW, Heres a suggestions:

If we dont hear from anybody by Tuesday(I know Weiming mentioned
something about being back Monday), lets start assuming noone will
and move towards updating the draft to beat the deadline.
I dont think people will mind if they are busy.

cheers,
jamal




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


  

--=20
Robert Haas
IBM Zurich Research Laboratory
S=E4umerstrasse 4
CH-8803 R=FCschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
------_=_NextPart_001_01C4B687.6A30F04C-- --===============1979272838== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1979272838==-- From forces-protocol-bounces@ietf.org Wed Oct 20 08:52:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29104 for ; Wed, 20 Oct 2004 08:52:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKG9p-0008Cf-LM for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 09:05:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKF4J-0008Po-Ni; Wed, 20 Oct 2004 07:55:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKEO2-0007nH-4C for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 07:12:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22310 for ; Wed, 20 Oct 2004 07:12:01 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKEaK-00064B-FA for forces-protocol@ietf.org; Wed, 20 Oct 2004 07:24:54 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9K7tNxD051072; Wed, 20 Oct 2004 07:55:23 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9K7tMkJ169824; Wed, 20 Oct 2004 09:55:22 +0200 Received: from [9.146.217.14] (sig-9-146-217-14.de.ibm.com [9.146.217.14]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA38960; Wed, 20 Oct 2004 09:55:21 +0200 Message-ID: <417619DA.4050000@zurich.ibm.com> Date: Wed, 20 Oct 2004 09:55:06 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model folks References: <468F3FDA28AA87429AD807992E22D07E025791DB@orsmsx408> <1097865957.1036.235.camel@jzny.localdomain> <41757407.2040007@zurich.ibm.com> <1098217299.1029.63.camel@jzny.localdomain> In-Reply-To: <1098217299.1029.63.camel@jzny.localdomain> X-Spam-Score: 0.5 (/) X-Scan-Signature: 559439f19b20fd64c5cd872aef84c6f3 Cc: "Khosravi, Hormuzd M" , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0480624954==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 0aa23132abbc731e36938583486affe0 This is a multi-part message in MIME format. --===============0480624954== Content-Type: multipart/alternative; boundary="------------060306080605040008050000" This is a multi-part message in MIME format. --------------060306080605040008050000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.de.ibm.com id i9K7tNxD051072 Content-Transfer-Encoding: quoted-printable Jamal, I don't see the point of sending a heartbeat to any LFB other than the=20 FE Protocol LFB. Here is why: The PL-level heartbeat is really about saying: the sender (FE or CE) of=20 this hearbeat is alive. FEs will typically be sending this to their CE=20 (after the CE has configured in the FE Protocol LFB at what frequency it=20 wants to receive heartbeats). Note that in the current draft we have=20 explicitely asked to ignore any ACK flag that would be set in the=20 hearbeat message header. If what you want to have is a ECHO-REQUEST/ECHO-REPLY to a particular=20 LFB (to check its status, etc), what should be used instead is a Query=20 msg with GET(status of the particular LFB instance). Would this answer=20 your needs ? -Robert Jamal Hadi Salim wrote: >Robert, >Could someone not send a heartbeat to a specific LFB? >In which case a heartbe to the FE object equates a heartbeat to the FE. > >cheers, >jamal > >On Tue, 2004-10-19 at 16:07, Robert Haas wrote: > =20 > >>I hope my note makes it before Jamal's noon ... Finally I got a 3 >>hours slot on a train ride (with phone off and no email access) to >>read the threads ... >> >>In summary: >> >>- I think it is good to keep the query separate from config. Reasons >>given by Steve/Zsolt sound very valid to me. >> >>- I am glad to see the "consolidation" into FE Protocol LFB operations >>of FE attributes config, FE events, and association maintenance >>messages. >> >>- The heartbeat message is currently not "targeted" at the FE protocol >>LFB. It is an exception to the rule. The reasoning was to keep such >>messages as short and simple as possible. Basically, you have the >>choice between a heartbeat to look like this: >> >>main hdr (eg type =3D heartbeat) >> | >> | >> +--- T =3D LFBselect >> | >> +-- LFBCLASSID =3D FE Protocol LFB Class (=3D0x01) >> | >> | >> +-- LFBInstance =3D FE Protocol LFB Instance(=3D0x01) >>or like this: >> >>main hdr (eg type =3D heartbeat) >>The difference is only 6-8 bytes (I don't remember what was the final >>consensus for the T in the TLV). But as the values in the LFBSelect >>TLV must ALWAYS be 0x01 and 0x01 (we have statically defined the class >>and instance ID of the FE protocol LFB), it is a waste to transmit >>them. And if you do, then someone might use wrong values and then you >>have to decide how to deal with such cases. >> >>Regards, >>-Robert >> >>Jamal Hadi Salim wrote:=20 >> =20 >> >>>On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote: >>> >>> =20 >>> =20 >>> >>>>Is there a reason you want to keep that type=3Dquery? >>>>[HK] The responses will be more involved for query,=20 >>>>also the request might be more involved.=20 >>>> =20 >>>> =20 >>>> >>>This is true. But i dont know how you escape it with any scheme. >>>If you ask to get, you must specify a path whether you use query or=20 >>>config. I would think the response will also have a path and the >>>requested data for that path. >>> >>> =20 >>> =20 >>> >>>>The other reason is that=20 >>>>I have never seen query bundled with SET/DEL in practice... >>>> =20 >>>> =20 >>>> >>>I dont either; dont wanna rule it - but the more i think about it the >>>more i am concluding its just about sending bundled commands. I think >>>you can not possibly make it any simpler by introducing type=3Dquery. >>> >>> =20 >>> =20 >>> >>>>Is this a requirement from >>>>Joel or the Model team ? I didn't get that impression, but I might ha= ve >>>>missed it. >>>> >>>> =20 >>>> =20 >>>> >>>I cant remember where it came or where the discussion took place. >>>However, it does make logical sense given now that "everything is an >>>LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes = to >>>the same way: FE->LFBclass->LFBinstance->path >>>Other than the operator, the operand to a GET is _exactly_ the same >>>as a DEL. ADD has one extra operand. >>>So its not really an issue of requirements; but one of a natural fit (= as >>>in the case of SNMP for example) >>>If you can show that you can get an object easier with type=3Dquery i >>>think that would help. Otherwise we would have an additional unneeded >>>message. >>> >>> =20 >>> =20 >>> >>>>>6.3 -> looks good...we might still need the Flags, also the Event Ty= pe >>>>>is needed since Event Subscribe, UnSubscribe are currently part of >>>>> =20 >>>>> =20 >>>>> >>>>this >>>> =20 >>>> =20 >>>> >>>>>message. >>>>> =20 >>>>> =20 >>>>> >>>>Probably makes sense to keep event subscription under config. Sorry >>>>I missed that in my quick scan and thought it belonged to type=3Deven= t in >>>>6.4. >>>>Do we then need operation =3D Event_un/subscribe [HK] Yes >>>>I suspect that events will end up being defined in the LFB XML >>>>definition and therefore will have a path to them (eg link event in p= ort >>>>LFB being path 1.2.3 etc). >>>>In which case, the value of the Event_un/subscribe will be to the >>>>event. >>>>Thoughts? [HK] We could simplify this for generic events, but what >>>>you're suggesting seems reasonable. >>>> =20 >>>> =20 >>>> >>>I think its safer to have the XML define what those events are. I sent= a >>>query to Joel who will forward it to the model team. He seems to be in >>>agreement. Note this will be equivalent to SNMP traps (which is define= d >>>in the mib together with other attributes). >>>As far as i can see, the event is another attribute. So it would look >>>like: >>>Operation =3D subscribe; operand =3D eventpath >>>In our case we should go ahead and choose events that are necessary fo= r >>>the protocol to function and put them in eitehr the FE object or FE >>>protocol LFB. The model team can them adapt from them >>> =20 >>> =20 >>> =20 >>> >>>>>6.6 -> Fine...I am assuming the States will be exchanged in Event ms= gs >>>>> =20 >>>>> =20 >>>>> >>>>? >>>> >>>>Since everything is an LFB, then its per LFB event - in this case i >>>>would guess the states will belong to the FE Object LFB?=20 >>>> >>>>[HK] Yes they would, I have no objection to FE Object or everything >>>>being a LFB. The FE States would be part of the FE object sent in Eve= nt >>>>msgs. >>>> >>>> =20 >>>> =20 >>>> >>>Sounds reasonable. >>> >>> =20 >>> =20 >>> >>>>>6.7 -> remains the same (I assume) >>>>> =20 >>>>> =20 >>>>> >>>>I missed that one, sorry. >>>>Again my take is this is gone. I would think this would per FE >>>>heartebats belong to the FE Protocol LFB. >>>>[HK] No, this doesn't need to go, its just a header anyways, it doesn= 't >>>>have any TLVs...its a very light weight msg, remember? I think you ar= e >>>>confusing this with the FE Protocol Object, that doesn't have any eff= ect >>>>on this msg. >>>> =20 >>>> =20 >>>> >>>But who is the target for this message now? >>>Remember, there MUST be an LFB as the end target. >>> >>> =20 >>> =20 >>> >>>>I think that the two FE LFBs deserve speacial attention now. >>>>We need to describe what they are expected to do in more detail. We a= lso >>>>need to sync on them with the model people. >>>>[HK] Sure, agree on this..I was hoping Robert/Weiming will take a lea= d >>>>on defining this >>>> >>>> =20 >>>> =20 >>>> >>>We may all have to be involved in these two. I think they are very >>>important that we all need to be involved. >>> >>>BTW, Heres a suggestions: >>> >>>If we dont hear from anybody by Tuesday(I know Weiming mentioned >>>something about being back Monday), lets start assuming noone will >>>and move towards updating the draft to beat the deadline. >>>I dont think people will mind if they are busy. >>> >>>cheers, >>>jamal >>> >>> >>> >>> >>>_______________________________________________ >>>Forces-protocol mailing list >>>Forces-protocol@ietf.org >>>https://www1.ietf.org/mailman/listinfo/forces-protocol >>> >>> >>> =20 >>> =20 >>> >>--=20 >>Robert Haas >>IBM Zurich Research Laboratory >>S=E4umerstrasse 4 >>CH-8803 R=FCschlikon/Switzerland >>phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rh= a >> =20 >> > > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------060306080605040008050000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jamal,
I don't see the point of sending a heartbeat to any LFB other than the FE Protocol LFB. Here is why:

The PL-level heartbeat is really about saying: the sender (FE or CE) of this hearbeat is alive. FEs will typically be sending this to their CE (after the CE has configured in the FE Protocol LFB at what frequency it wants to receive heartbeats). Note that in the current draft we have explicitely asked to ignore any ACK flag that would be set in the hearbeat message header.

If what you want to have is a ECHO-REQUEST/ECHO-REPLY to a particular LFB (to check its status, etc), what should be used instead is a Query msg with GET(status of the particular LFB instance). Would this answer your needs ?

-Robert


Jamal Hadi Salim wrote:
Robert,
Could someone not send a heartbeat to a specific LFB?
In which case a heartbe to the FE object equates a heartbeat to the FE.

cheers,
jamal

On Tue, 2004-10-19 at 16:07, Robert Haas wrote:
  
I hope my note makes it before Jamal's noon ... Finally I got a 3
hours slot on a train ride (with phone off and no email access) to
read the threads ...

In summary:

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

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

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

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

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

Regards,
-Robert

Jamal Hadi Salim wrote: 
    
On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote:

  
      
Is there a reason you want to keep that type=query?
[HK] The responses will be more involved for query, 
also the request <path> might be more involved. 
    
        
This is true. But i dont know how you escape it with any scheme.
If you ask to get, you must specify a path whether you use query or 
config. I would think the response will also have a path and the
requested data for that path.

  
      
The other reason is that 
I have never seen query bundled with SET/DEL in practice...
    
        
I dont either; dont wanna rule it - but the more i think about it the
more i am concluding its just about sending bundled commands. I think
you can not possibly make it any simpler by introducing type=query.

  
      
Is this a requirement from
Joel or the Model team ? I didn't get that impression, but I might have
missed it.

    
        
I cant remember where it came or where the discussion took place.
However, it does make logical sense given now that "everything is an
LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to
the same way: FE->LFBclass->LFBinstance->path
Other than the operator, the operand to a GET is _exactly_ the same
as a DEL. ADD has one extra operand.
So its not really an issue of requirements; but one of a natural fit (as
in the case of SNMP for example)
If you can show that you can get an object easier with type=query i
think that would help. Otherwise we would have an additional unneeded
message.

  
      
6.3 -> looks good...we might still need the Flags, also the Event Type
is needed since Event Subscribe, UnSubscribe are currently part of
      
          
this
    
        
message.
      
          
Probably makes sense to keep event subscription under config. Sorry
I missed that in my quick scan and thought it belonged to type=event in
6.4.
Do we then need operation = Event_un/subscribe [HK] Yes
I suspect that events will end up being defined in the LFB XML
definition and therefore will have a path to them (eg link event in port
LFB being path 1.2.3 etc).
In which case, the value of the Event_un/subscribe will be to the
event.
Thoughts? [HK] We could simplify this for generic events, but what
you're suggesting seems reasonable.
    
        
I think its safer to have the XML define what those events are. I sent a
query to Joel who will forward it to the model team. He seems to be in
agreement. Note this will be equivalent to SNMP traps (which is defined
in the mib together with other attributes).
As far as i can see, the event is another attribute. So it would look
like:
Operation = subscribe; operand = eventpath
In our case we should go ahead and choose events that are necessary for
the protocol to function and put them in eitehr the FE object or FE
protocol LFB. The model team can them adapt from them
  
  
      
6.6 -> Fine...I am assuming the States will be exchanged in Event msgs
      
          
?

Since everything is an LFB, then its per LFB event - in this case i
would guess the states will belong to the FE Object LFB? 

[HK] Yes they would, I have no objection to FE Object or everything
being a LFB. The FE States would be part of the FE object sent in Event
msgs.

    
        
Sounds reasonable.

  
      
6.7 -> remains the same (I assume)
      
          
I missed that one, sorry.
Again my take is this is gone. I would think this would per FE
heartebats belong to the FE Protocol LFB.
[HK] No, this doesn't need to go, its just a header anyways, it doesn't
have any TLVs...its a very light weight msg, remember? I think you are
confusing this with the FE Protocol Object, that doesn't have any effect
on this msg.
    
        
But who is the target for this message now?
Remember, there MUST be an LFB as the end target.

  
      
I think that the two FE LFBs deserve speacial attention now.
We need to describe what they are expected to do in more detail. We also
need to sync on them with the model people.
[HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead
on defining this

    
        
We may all have to be involved in these two. I think they are very
important that we all need to be involved.

BTW, Heres a suggestions:

If we dont hear from anybody by Tuesday(I know Weiming mentioned
something about being back Monday), lets start assuming noone will
and move towards updating the draft to beat the deadline.
I dont think people will mind if they are busy.

cheers,
jamal




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


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



  

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------060306080605040008050000-- --===============0480624954== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0480624954==-- From forces-protocol-bounces@ietf.org Wed Oct 20 08:53:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29144 for ; Wed, 20 Oct 2004 08:53:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKG9s-0008Cp-LK for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 09:05:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKF48-0008O1-BT; Wed, 20 Oct 2004 07:55:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKELu-0007Kh-Ha for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 07:09:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22198 for ; Wed, 20 Oct 2004 07:09:50 -0400 (EDT) Received: from [64.254.114.114] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKEXx-00062f-Lm for forces-protocol@ietf.org; Wed, 20 Oct 2004 07:22:42 -0400 Received: from JLaptop.megisto.com ([192.168.20.235]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 20 Oct 2004 07:09:11 -0400 Message-Id: <5.1.0.14.0.20041020070534.0240c390@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Oct 2004 07:08:57 -0400 To: "Wang,Weiming" , From: "Joel M. Halpern" Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? In-Reply-To: <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Oct 2004 11:09:11.0513 (UTC) FILETIME=[3A256C90:01C4B695] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, zsolt@nc.rr.com, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Allow me to be a bit pedantic and repetitive please, because apparently my main point got lost. Even when there are large numbers of LFB instances of a given class in an FE that need to be set, I have trouble envisioning that they will need to be set to the identical values. Some of the values will be the same. But some will be different. If at least one value differs, then you need an operation directed at each individual LFB Instance. If this is infeasible, then we have a basic problem that multicast at this level will not help. If this is feasible, then multicast at this level seems a refinement that can wait until we know if we need it. Yours, Joel PS: We are talking here about multicasting to LFB instances within an FE. Although I am still doubtful about the multi-FE case, I can understand that rather better. At 01:56 PM 10/20/2004 +0800, Wang,Weiming wrote: > > Given that there are distinct values in each LFB instance, there must be an > > operation against each LFB instance. >I don't think multicast will loose operation individuality. > > > > The marginal gain from having a single transaction to update the identical > > fields, and then individual transactions for the distinct fields is very > > small. It does not reduce the number of IOs or the core transaction rate. >[Weiming]At least it saves bits greatly and makes protocol practical. Remember >the capability between CE and FE are quite limited, especially in muli-hop >ForCES application. > > > > If it is desired to optimize for this case, we may want to introduce (in a > > future version of the protocol) some kind of block checkpoint / restart > > mechanism. The CE would record its full state about the FE, and then ask > > the FE for a dump suitable for restoral of the FE state. Upon restart, the > > CE would rebuild its state from its stored representation, and would ship > > the dump back to the FE to enable efficient rebuilding there. I can see > > significant value in such a mechanism. I do not however see a need to > > include this in the first deliverable of the protocol. >[Weiming]I suppose this is only for restart case, I can see many cases where >multiple addressing can apply, such as delete, change of LFB parameter, >load and >unload of LFBs, etc. And also I think the scheme above is much more >complex than >multiple addressing. So, my conclusion is, with a little bit expansion, we can >gain much, then why not we adpot it? _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 20 09:31:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02249 for ; Wed, 20 Oct 2004 09:31:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKGlB-0000aL-8t for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 09:44:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKFuZ-0002FU-4r; Wed, 20 Oct 2004 08:49:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKF2Y-00088D-5M for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 07:54:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25116 for ; Wed, 20 Oct 2004 07:53:55 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKFEr-00071I-CK for forces-protocol@ietf.org; Wed, 20 Oct 2004 08:06:46 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9KBrOxD086132 for ; Wed, 20 Oct 2004 11:53:24 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9KBrOwo223542 for ; Wed, 20 Oct 2004 13:53:24 +0200 Received: from [9.145.128.47] (sig-9-145-128-47.de.ibm.com [9.145.128.47]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA69704 for ; Wed, 20 Oct 2004 13:53:23 +0200 Message-ID: <417651A7.3090808@zurich.ibm.com> Date: Wed, 20 Oct 2004 13:53:11 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: forces-protocol@ietf.org Subject: [Fwd: [Forces-protocol] action item: NFS compound commands] X-Spam-Score: 0.6 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0866752903==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 This is a multi-part message in MIME format. --===============0866752903== Content-Type: multipart/alternative; boundary="------------050109020202070603060307" This is a multi-part message in MIME format. --------------050109020202070603060307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate2.de.ibm.com id i9KBrOxD086132 Content-Transfer-Encoding: quoted-printable -------- Original Message -------- Subject: [Forces-protocol] action item: NFS compound commands Date: Sat, 15 May 2004 00:04:42 +0200 From: Robert Haas Organization: IBM Research Lab To: forces-protocol@ietf.org Here are some clarifications about NFSv4 compound commands. NFSv4 introduces the notion of a compound command that groups a serie of=20 operations not executed atomically. Execution stops at the first failed=20 operation. Status report is returned up to (and including) the failed=20 operation. Most interestingly, compound commands allow results of intermediate=20 operations to be stored and reused on subsequent operations in the same=20 compound. In ForCES, you could imagine using this feature for instance to do the=20 following in one shot (a compound commands composed of 2 operations): operation 1: read the rate r at which flow x is currently sending. operation 2: set the same rate r for the policing of a new flow y. (the=20 result of the first operation is reused here) We can debate whether this is desirable in ForCES or not. This feature=20 was introduced in NFSv4 for performance reasons. CHeers, -Robert Below are excerpts of the NFSv4 paper on the justification for compound=20 commands: Another structural difference between NFS Version 4 and its predecessors is the introduction of a COMPOUND RPC procedure that allows the client to group traditional file operations into a single request to send to the server. In NFS Versions 2 and 3, all actions were RPC procedures. NFS Version 4 is no longer a "simple" RPC-based distributed application. In NFS Version 4, work is accomplished via operations. An operation is a file system action that forms part of a COMPOUND procedure. NFS Version 4 operations correspond functionally to RPC procedures in former versions of NFS. The server in turn groups the operation replies into a single response. Error handling is simple on the server - evaluation proceeds until the first error or last operation whereupon the server returns a reply for all evaluated operations. We introduced the COMPOUND procedure to reduce network round trip latency for related operations, which can be costly over a WAN (for example, the Internet). [...] 4.1. An example The following denotations represent NFS transactions in this paper. We represent a simple client RPC request in NFS Versions 2 and 3 by: -> LOOKUP We represent a simple server RPC response by: <- LOOKUP OK We represent a COMPOUND client RPC request in NFS Version 4, which contains one or more operations, by: -> PUTROOTFH LOOKUP GETFH We represent a COMPOUND server RPC response in NFS Version 4, which contains one or more replies to previous operations, by: <- PUTROOTFH OK LOOKUP OK GETFH OK Note the direction of the arrows in each example. [...] The set of operations in a COMPOUND procedure is not atomic. That is, no assumptions can be made as to whether conflicting operations occurred to file system objects referenced in a COMPOUND procedure between successive operations. Error handling is simple on the server. If an operation fails in a COMPOUND procedure, evaluation halts and the remaining operations are not processed. Replies are returned to the client up to and including the error reply for the failed operation. The full paper is at: http://www.nluug.nl/events/sane2000/papers/pawlowski.pdf --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------050109020202070603060307 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

-------- Original Message --------
Subject: [Forces-protocol] action item: NFS compound commands
Date: Sat, 15 May 2004 00:04:42 +0200
From: Robert Haas <rha@zurich.ibm.com>
Organization: IBM Research Lab
To: forces-protocol@ietf.org 


Here are some clarifications about NFSv4 compound commands.

NFSv4 introduces the notion of a compound command that groups a serie of 
operations not executed atomically. Execution stops at the first failed 
operation. Status report is returned up to (and including) the failed 
operation.
Most interestingly, compound commands allow results of intermediate 
operations to be stored and reused on subsequent operations in the same 
compound.

In ForCES, you could imagine using this feature for instance to do the 
following in one shot (a compound commands composed of 2 operations):

operation 1: read the rate r at which flow x is currently sending.
operation 2: set the same rate r for the policing of a new flow y. (the 
result of the first operation is reused here)

We can debate whether this is desirable in ForCES or not. This feature 
was introduced in NFSv4 for performance reasons.

CHeers,
-Robert


Below are excerpts of the NFSv4 paper on the justification for compound 
commands:

Another structural difference between NFS
Version 4 and its predecessors is the introduction
of a COMPOUND RPC procedure that allows the
client to group traditional file operations into a
single request to send to the server. In NFS
Versions 2 and 3, all actions were RPC procedures.
NFS Version 4 is no longer a “simple” RPC-based
distributed application. In NFS Version 4, work is
accomplished via operations. An operation is a file
system action that forms part of a COMPOUND
procedure. NFS Version 4 operations correspond
functionally to RPC procedures in former versions
of NFS. The server in turn groups the operation
replies into a single response. Error handling is
simple on the server – evaluation proceeds until
the first error or last operation whereupon the
server returns a reply for all evaluated operations.
We introduced the COMPOUND procedure to
reduce network round trip latency for related
operations, which can be costly over a WAN (for
example, the Internet).

[...]

4.1. An example
The following denotations represent NFS
transactions in this paper. We represent a simple
client RPC request in NFS Versions 2 and 3 by:
-> LOOKUP
We represent a simple server RPC response by:
<- LOOKUP OK
We represent a COMPOUND client RPC request
in NFS Version 4, which contains one or more
operations, by:
-> PUTROOTFH
LOOKUP
GETFH
We represent a COMPOUND server RPC
response in NFS Version 4, which contains one or
more replies to previous operations, by:
<- PUTROOTFH OK
LOOKUP OK
GETFH OK
Note the direction of the arrows in each
example.

[...]

The set of operations in a COMPOUND procedure is
not atomic. That is, no assumptions can be made
as to whether conflicting operations occurred to
file system objects referenced in a COMPOUND
procedure between successive operations.
Error handling is simple on the server. If an
operation fails in a COMPOUND procedure,
evaluation halts and the remaining operations are
not processed. Replies are returned to the client up
to and including the error reply for the failed
operation.


The full paper is at:
http://www.nluug.nl/events/sane2000/papers/pawlowski.pdf


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



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




-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------050109020202070603060307-- --===============0866752903== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0866752903==-- From forces-protocol-bounces@ietf.org Wed Oct 20 09:31:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02281 for ; Wed, 20 Oct 2004 09:31:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKGlI-0000aY-QI for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 09:44:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKFuZ-0002Fe-B4; Wed, 20 Oct 2004 08:49:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKF2Y-00088E-P9 for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 07:54:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25119 for ; Wed, 20 Oct 2004 07:53:55 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKFEr-00071H-CO for forces-protocol@ietf.org; Wed, 20 Oct 2004 08:06:46 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9KBrKxX040668; Wed, 20 Oct 2004 11:53:20 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9KBrJwo211358; Wed, 20 Oct 2004 13:53:20 +0200 Received: from [9.145.128.47] (sig-9-145-128-47.de.ibm.com [9.145.128.47]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA49214; Wed, 20 Oct 2004 13:53:18 +0200 Message-ID: <417651A1.5030600@zurich.ibm.com> Date: Wed, 20 Oct 2004 13:53:05 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram.gopal@nokia.com Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model folks References: In-Reply-To: X-Spam-Score: 1.1 (+) X-Scan-Signature: ca81a19b939ce054f98c8f830c2d7742 Cc: hormuzd.m.khosravi@intel.com, hadi@znyx.com, forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0115394936==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: c96e11e58076fc8e92061fb6cbdfae15 This is a multi-part message in MIME format. --===============0115394936== Content-Type: multipart/alternative; boundary="------------020903000308080500000003" This is a multi-part message in MIME format. --------------020903000308080500000003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate4.de.ibm.com id i9KBrKxX040668 Content-Transfer-Encoding: quoted-printable Ram, Not sure what you mean by "automatic" ? Bundling of GETs and SETs in the same message is somehow similar to=20 command compounds in NFSv4. I am forwarding the note again FYI. But at this point I don't think the group is willing to support this=20 kind of compound commands. Regards, -Robert ram.gopal@nokia.com wrote: > Hello, > =20 > Agree. Keeping config and query makes simpler. > =20 > But another point is forces is mostly going to be used as=20 > configuration protocol, in may case GET/(and SET) as automatic > may be ideal one.(SET operation is optional). Are we are not going to=20 > accommodate command bundling, this discussion thread is converging=20 > well, may its a correct place to > resolve that also. > =20 > =20 > =20 > If if I recollect correctly, in one of the teleconference - the issue=20 > of command this issue was popped and was didn't got time to resolve. > =20 > =20 > regards > ramg > -----Original Message----- > From: forces-protocol-bounces@ietf.org=20 > [mailto:forces-protocol-bounces@ietf.org]On Behalf Of ext Robert Haas > Sent: Tuesday, October 19, 2004 4:08 PM > To: hadi@znyx.com > Cc: Khosravi, Hormuzd M; forces-protocol@ietf.org > Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with=20 > model folks > > I hope my note makes it before Jamal's noon ... Finally I got a 3=20 > hours slot on a train ride (with phone off and no email access) to=20 > read the threads ... > > In summary: > > - I think it is good to keep the query separate from config. Reasons=20 > given by Steve/Zsolt sound very valid to me. > > - I am glad to see the "consolidation" into FE Protocol LFB operations=20 > of FE attributes config, FE events, and association maintenance message= s. > > - The heartbeat message is currently not "targeted" at the FE protocol=20 > LFB. It is an exception to the rule. The reasoning was to keep such=20 > messages as short and simple as possible. Basically, you have the=20 > choice between a heartbeat to look like this: > >main hdr (eg type =3D heartbeat) > | > | > +--- T =3D LFBselect > | > +-- LFBCLASSID =3D FE Protocol LFB Class (=3D0x01) > | > | > +-- LFBInstance =3D FE Protocol LFB Instance(=3D0x01) > > or like this: > >main hdr (eg type =3D heartbeat) > > > The difference is only 6-8 bytes (I don't remember what was the final=20 > consensus for the T in the TLV). But as the values in the LFBSelect=20 > TLV must ALWAYS be 0x01 and 0x01 (we have statically defined the class=20 > and instance ID of the FE protocol LFB), it is a waste to transmit=20 > them. And if you do, then someone might use wrong values and then you=20 > have to decide how to deal with such cases. > > Regards, > -Robert > > Jamal Hadi Salim wrote: > >>On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote: >> >> =20 >> >>>Is there a reason you want to keep that type=3Dquery? >>>[HK] The responses will be more involved for query,=20 >>>also the request might be more involved.=20 >>> =20 >>> >> >>This is true. But i dont know how you escape it with any scheme. >>If you ask to get, you must specify a path whether you use query or=20 >>config. I would think the response will also have a path and the >>requested data for that path. >> >> =20 >> >>>The other reason is that=20 >>>I have never seen query bundled with SET/DEL in practice... >>> =20 >>> >> >>I dont either; dont wanna rule it - but the more i think about it the >>more i am concluding its just about sending bundled commands. I think >>you can not possibly make it any simpler by introducing type=3Dquery. >> >> =20 >> >>>Is this a requirement from >>>Joel or the Model team ? I didn't get that impression, but I might hav= e >>>missed it. >>> >>> =20 >>> >> >>I cant remember where it came or where the discussion took place. >>However, it does make logical sense given now that "everything is an >>LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes t= o >>the same way: FE->LFBclass->LFBinstance->path >>Other than the operator, the operand to a GET is _exactly_ the same >>as a DEL. ADD has one extra operand. >>So its not really an issue of requirements; but one of a natural fit (a= s >>in the case of SNMP for example) >>If you can show that you can get an object easier with type=3Dquery i >>think that would help. Otherwise we would have an additional unneeded >>message. >> >> =20 >> >>>>6.3 -> looks good...we might still need the Flags, also the Event Typ= e >>>>is needed since Event Subscribe, UnSubscribe are currently part of >>>> =20 >>>> >>>this >>> =20 >>> >>>>message. >>>> =20 >>>> >>>Probably makes sense to keep event subscription under config. Sorry >>>I missed that in my quick scan and thought it belonged to type=3Devent= in >>>6.4. >>>Do we then need operation =3D Event_un/subscribe [HK] Yes >>>I suspect that events will end up being defined in the LFB XML >>>definition and therefore will have a path to them (eg link event in po= rt >>>LFB being path 1.2.3 etc). >>>In which case, the value of the Event_un/subscribe will be to the >>>event. >>>Thoughts? [HK] We could simplify this for generic events, but what >>>you're suggesting seems reasonable. >>> =20 >>> >> >>I think its safer to have the XML define what those events are. I sent = a >>query to Joel who will forward it to the model team. He seems to be in >>agreement. Note this will be equivalent to SNMP traps (which is defined >>in the mib together with other attributes). >>As far as i can see, the event is another attribute. So it would look >>like: >>Operation =3D subscribe; operand =3D eventpath >>In our case we should go ahead and choose events that are necessary for >>the protocol to function and put them in eitehr the FE object or FE >>protocol LFB. The model team can them adapt from them >> =20 >> =20 >> >>>>6.6 -> Fine...I am assuming the States will be exchanged in Event msg= s >>>> =20 >>>> >>>? >>> >>>Since everything is an LFB, then its per LFB event - in this case i >>>would guess the states will belong to the FE Object LFB?=20 >>> >>>[HK] Yes they would, I have no objection to FE Object or everything >>>being a LFB. The FE States would be part of the FE object sent in Even= t >>>msgs. >>> >>> =20 >>> >> >>Sounds reasonable. >> >> =20 >> >>>>6.7 -> remains the same (I assume) >>>> =20 >>>> >>>I missed that one, sorry. >>>Again my take is this is gone. I would think this would per FE >>>heartebats belong to the FE Protocol LFB. >>>[HK] No, this doesn't need to go, its just a header anyways, it doesn'= t >>>have any TLVs...its a very light weight msg, remember? I think you are >>>confusing this with the FE Protocol Object, that doesn't have any effe= ct >>>on this msg. >>> =20 >>> >> >>But who is the target for this message now? >>Remember, there MUST be an LFB as the end target. >> >> =20 >> >>>I think that the two FE LFBs deserve speacial attention now. >>>We need to describe what they are expected to do in more detail. We al= so >>>need to sync on them with the model people. >>>[HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead >>>on defining this >>> >>> =20 >>> >> >>We may all have to be involved in these two. I think they are very >>important that we all need to be involved. >> >>BTW, Heres a suggestions: >> >>If we dont hear from anybody by Tuesday(I know Weiming mentioned >>something about being back Monday), lets start assuming noone will >>and move towards updating the draft to beat the deadline. >>I dont think people will mind if they are busy. >> >>cheers, >>jamal >> >> >> >> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> >> =20 >> > >--=20 >Robert Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------020903000308080500000003 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ram,
Not sure what you mean by "automatic" ?
Bundling of GETs and SETs in the same message is somehow similar to command compounds in NFSv4. I am forwarding the note again FYI.
But at this point I don't think the group is willing to support this kind of compound commands.

Regards,
-Robert

ram.gopal@nokia.com wrote:
Hello,
 
Agree. Keeping config and query makes simpler.
 
But another point is forces is mostly going to be used as configuration protocol, in may case GET/(and SET) as automatic
may be ideal one.(SET operation is optional). Are we are not going to accommodate command bundling, this discussion thread is converging well, may its a correct place to
resolve that also.
 
 
 
If if I recollect correctly, in one of the teleconference - the issue of command this issue was popped and was didn't got time to resolve.
 
 
regards
ramg
-----Original Message-----
From: forces-protocol-bounces@ietf.org [mailto:forces-protocol-bounces@ietf.org]On Behalf Of ext Robert Haas
Sent: Tuesday, October 19, 2004 4:08 PM
To: hadi@znyx.com
Cc: Khosravi, Hormuzd M; forces-protocol@ietf.org
Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model folks

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

In summary:

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

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

- The heartbeat message is currently not "targeted" at the FE protocol LFB. It is an exception to the rule. The reasoning was to keep such messages as short and simple as possible. Basically, you have the choice between a heartbeat to look like this:
main hdr (eg type = heartbeat)
      |
      |
      +--- T = LFBselect
               |
               +-- LFBCLASSID = FE Protocol LFB Class (=0x01)
               |
               |
               +-- LFBInstance = FE Protocol LFB Instance(=0x01)
or like this:
main hdr (eg type = heartbeat)

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

Regards,
-Robert

Jamal Hadi Salim wrote: 
On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote:

  
Is there a reason you want to keep that type=query?
[HK] The responses will be more involved for query, 
also the request <path> might be more involved. 
    

This is true. But i dont know how you escape it with any scheme.
If you ask to get, you must specify a path whether you use query or 
config. I would think the response will also have a path and the
requested data for that path.

  
The other reason is that 
I have never seen query bundled with SET/DEL in practice...
    

I dont either; dont wanna rule it - but the more i think about it the
more i am concluding its just about sending bundled commands. I think
you can not possibly make it any simpler by introducing type=query.

  
Is this a requirement from
Joel or the Model team ? I didn't get that impression, but I might have
missed it.

    

I cant remember where it came or where the discussion took place.
However, it does make logical sense given now that "everything is an
LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to
the same way: FE->LFBclass->LFBinstance->path
Other than the operator, the operand to a GET is _exactly_ the same
as a DEL. ADD has one extra operand.
So its not really an issue of requirements; but one of a natural fit (as
in the case of SNMP for example)
If you can show that you can get an object easier with type=query i
think that would help. Otherwise we would have an additional unneeded
message.

  
6.3 -> looks good...we might still need the Flags, also the Event Type
is needed since Event Subscribe, UnSubscribe are currently part of
      
this
    
message.
      
Probably makes sense to keep event subscription under config. Sorry
I missed that in my quick scan and thought it belonged to type=event in
6.4.
Do we then need operation = Event_un/subscribe [HK] Yes
I suspect that events will end up being defined in the LFB XML
definition and therefore will have a path to them (eg link event in port
LFB being path 1.2.3 etc).
In which case, the value of the Event_un/subscribe will be to the
event.
Thoughts? [HK] We could simplify this for generic events, but what
you're suggesting seems reasonable.
    

I think its safer to have the XML define what those events are. I sent a
query to Joel who will forward it to the model team. He seems to be in
agreement. Note this will be equivalent to SNMP traps (which is defined
in the mib together with other attributes).
As far as i can see, the event is another attribute. So it would look
like:
Operation = subscribe; operand = eventpath
In our case we should go ahead and choose events that are necessary for
the protocol to function and put them in eitehr the FE object or FE
protocol LFB. The model team can them adapt from them
  
  
6.6 -> Fine...I am assuming the States will be exchanged in Event msgs
      
?

Since everything is an LFB, then its per LFB event - in this case i
would guess the states will belong to the FE Object LFB? 

[HK] Yes they would, I have no objection to FE Object or everything
being a LFB. The FE States would be part of the FE object sent in Event
msgs.

    

Sounds reasonable.

  
6.7 -> remains the same (I assume)
      
I missed that one, sorry.
Again my take is this is gone. I would think this would per FE
heartebats belong to the FE Protocol LFB.
[HK] No, this doesn't need to go, its just a header anyways, it doesn't
have any TLVs...its a very light weight msg, remember? I think you are
confusing this with the FE Protocol Object, that doesn't have any effect
on this msg.
    

But who is the target for this message now?
Remember, there MUST be an LFB as the end target.

  
I think that the two FE LFBs deserve speacial attention now.
We need to describe what they are expected to do in more detail. We also
need to sync on them with the model people.
[HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead
on defining this

    

We may all have to be involved in these two. I think they are very
important that we all need to be involved.

BTW, Heres a suggestions:

If we dont hear from anybody by Tuesday(I know Weiming mentioned
something about being back Monday), lets start assuming noone will
and move towards updating the draft to beat the deadline.
I dont think people will mind if they are busy.

cheers,
jamal




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


  

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

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------020903000308080500000003-- --===============0115394936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0115394936==-- From forces-protocol-bounces@ietf.org Wed Oct 20 09:58:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04180 for ; Wed, 20 Oct 2004 09:58:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHB2-00016y-Ce for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 10:10:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGPN-0001ZX-4t; Wed, 20 Oct 2004 09:21:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKFgs-0007DB-3Z for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 08:35:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27682 for ; Wed, 20 Oct 2004 08:35:35 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKFtB-0007oN-GA for forces-protocol@ietf.org; Wed, 20 Oct 2004 08:48:26 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102005380650:34365 ; Wed, 20 Oct 2004 05:38:06 -0700 Subject: Re: [Forces-protocol] Re: protocol draft editing? From: Jamal Hadi Salim To: forces-protocol@ietf.org In-Reply-To: <1098228213.1044.56.camel@jzny.localdomain> References: <1098198457.1032.1.camel@jzny.localdomain> <1098228213.1044.56.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1098275730.1042.78.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Oct 2004 08:35:30 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/20/2004 05:38:06 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/20/2004 05:38:09 AM, Serialize complete at 10/20/2004 05:38:09 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Hormuzd M , ram.gopal@nokia.com, Ligang Dong , avri@psg.com, Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Avri must be on travel or tied up somewhere around the globe. The latest i could find is: http://psg.com/~avri/forces/draft/Archive-Forces-Protocol-02.zip Does anyone know if theres something newer or should we start here? Hormuzd can you post that todo distribution? cheers, jamal On Tue, 2004-10-19 at 19:23, Jamal Hadi Salim wrote: > On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote: > > Now that we seem to have made progress on the basics.. > > Avri, > > Could you post a URL to the xml docs that we could start editing? > > We could start with the TODO action items as posted by Hormuzd. > > > > cheers, > > jamal > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 20 10:34:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09744 for ; Wed, 20 Oct 2004 10:34:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHkQ-0001wl-9s for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 10:47:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGlp-000736-To; Wed, 20 Oct 2004 09:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGCX-0004sH-JS for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 09:08:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00810 for ; Wed, 20 Oct 2004 09:08:18 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKGOr-00009L-8J for forces-protocol@ietf.org; Wed, 20 Oct 2004 09:21:10 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102006104372:34398 ; Wed, 20 Oct 2004 06:10:43 -0700 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: "Joel M. Halpern" In-Reply-To: <5.1.0.14.0.20041020070534.0240c390@mail.megisto.com> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <5.1.0.14.0.20041020070534.0240c390@mail.megisto.com> Organization: ZNYX Networks Message-Id: <1098277687.2072.9.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Oct 2004 09:08:07 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/20/2004 06:10:44 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/20/2004 06:10:52 AM, Serialize complete at 10/20/2004 06:10:52 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , forces-protocol@ietf.org, Alan DeKok , zsolt@nc.rr.com, "Steven Blake \(petri-meat\)" , Ellen M Deleganes , "Wang, Weiming" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit On Wed, 2004-10-20 at 07:08, Joel M. Halpern wrote: > Allow me to be a bit pedantic and repetitive please, because apparently my > main point got lost. > > Even when there are large numbers of LFB instances of a given class in an > FE that need to be set, I have trouble envisioning that they will need to > be set to the identical values. Some of the values will be the same. But > some will be different. In anglais: "route add 10.0.0.0/24 gw 10.0.0.50 on port 10 of FE2"; Consider my case where I have six routing table instances (not VR) (typically one per MAC) which i would typically want to in most cases to populate with the same value (and on rare occasions with different values). Note the above makes sense for multi-FE multicast as well but you dont seem to have issues with that. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 20 11:12:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13336 for ; Wed, 20 Oct 2004 11:12:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKIKw-0002jU-H6 for forces-protocol-web-archive@ietf.org; Wed, 20 Oct 2004 11:25:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKHNa-0004ds-HN; Wed, 20 Oct 2004 10:23:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGYT-0003kc-Cb for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 09:31:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02204 for ; Wed, 20 Oct 2004 09:30:58 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKGkl-0000Zf-FW for forces-protocol@ietf.org; Wed, 20 Oct 2004 09:43:50 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CKGYK-0000h6-Lf for forces-protocol@ietf.org; Wed, 20 Oct 2004 09:30:57 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Wed, 20 Oct 2004 21:49:36 +0800 (CST) Received: from wwm1 (unverified [219.82.183.212]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Wed, 20 Oct 2004 21:26:19 +0800 Message-ID: <00e901c4b6a9$892e55e0$020aa8c0@wwm1> From: "Weiming Wang" To: , "Joel M. Halpern" References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <5.1.0.14.0.20041020070534.0240c390@mail.megisto.com> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Wed, 20 Oct 2004 21:34:12 +0800 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, zsolt@nc.rr.com, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Joel, > Even when there are large numbers of LFB instances of a given class in an > FE that need to be set, I have trouble envisioning that they will need to > be set to the identical values. Some of the values will be the same. But > some will be different. > If at least one value differs, then you need an operation directed at each > individual LFB Instance. If this is infeasible, then we have a basic > problem that multicast at this level will not help. If this is feasible, > then multicast at this level seems a refinement that can wait until we know > if we need it. I agree your mean of 'Even when' here, therefore the 'unpractical' I mean may not exist. I actually don't think the extremity is a good prove for the benifits of multiple addressing. I just can see the great benifits even when there are 100 instances. I think it may be much helpful if you could present some drawback for such approach. What I can see it is only a very little bit of complexity added to the instance select field. May be I'm too pedantic :) Anyway, I don't think we need to wait more if we find it valuble. Thank you. Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 07:35:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04608 for ; Thu, 21 Oct 2004 07:35:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbQM-0005C3-NW for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 07:48:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUHs-0005aZ-IV; Thu, 21 Oct 2004 00:10:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKJ9P-0006e7-07 for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 12:17:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19945 for ; Wed, 20 Oct 2004 12:17:14 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKJLk-0004AM-3l for forces-protocol@ietf.org; Wed, 20 Oct 2004 12:30:09 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9KFr4ep023348; Wed, 20 Oct 2004 17:53:06 +0200 In-Reply-To: <1098228213.1044.56.camel@jzny.localdomain> References: <1098198457.1032.1.camel@jzny.localdomain> <1098228213.1044.56.camel@jzny.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <744804BA-22B3-11D9-A3E1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Re: protocol draft editing? Date: Wed, 20 Oct 2004 12:16:52 -0400 To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Jamal Hadi Salim X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit hi, you will find a zip, a tar and a tgz in http://psg.com/~avri/forces/draft/ Please let this list know when you are working on a file. And for simplicity sake it is easier if it is one person per file at a time. cheers a. On 19 okt 2004, at 19.23, Jamal Hadi Salim wrote: > > On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote: >> Now that we seem to have made progress on the basics.. >> Avri, >> Could you post a URL to the xml docs that we could start editing? >> We could start with the TODO action items as posted by Hormuzd. >> >> cheers, >> jamal > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 07:45:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06535 for ; Thu, 21 Oct 2004 07:45:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbaX-0005gW-WA for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 07:58:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKalQ-0004hN-Ug; Thu, 21 Oct 2004 07:05:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKKiK-0000Tl-4d for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 13:57:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02666 for ; Wed, 20 Oct 2004 13:57:16 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKKuU-0007So-Qx for forces-protocol@ietf.org; Wed, 20 Oct 2004 14:10:09 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9KHvBUX026898; Wed, 20 Oct 2004 17:57:11 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9KHxiUL016931; Wed, 20 Oct 2004 18:00:12 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102010562213837 ; Wed, 20 Oct 2004 10:56:22 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 10:56:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Forces-protocol] RE: sync with BNF as discussed with model folks Date: Wed, 20 Oct 2004 10:56:22 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02F5D236@orsmsx408> Thread-Topic: [Forces-protocol] RE: sync with BNF as discussed with model folks Thread-Index: AcS2WPf61RxZ3ee/TxeLe07+fv7PuAALY7dQABHWdTA= From: "Khosravi, Hormuzd M" To: , , X-OriginalArrivalTime: 20 Oct 2004 17:56:22.0640 (UTC) FILETIME=[1C3B8F00:01C4B6CE] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 1.1 (+) X-Scan-Signature: 8104b3fcabb4d2dfaed548848b9dc80f Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0026628730==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 3b3673afe71d94a7551c8fbc5adb8948 This is a multi-part message in MIME format. --===============0026628730== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B6CE.1BC78291" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B6CE.1BC78291 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ram, =20 I don't think this is related to command bundling...we will still = support cmd bundling especially for Config (Add/Del/Update, etc...) Pls refer to all the emails posted on this topic and it will be clear. =20 Thanks Hormuzd ________________________________ From: forces-protocol-bounces@ietf.org = [mailto:forces-protocol-bounces@ietf.org] On Behalf Of = ram.gopal@nokia.com Sent: Wednesday, October 20, 2004 2:30 AM To: rha@zurich.ibm.com; hadi@znyx.com; Khosravi, Hormuzd M Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] RE: sync with BNF as discussed with model = folks Hello, =20 Agree. Keeping config and query makes simpler. =20 But another point is forces is mostly going to be used as configuration = protocol, in may case GET/(and SET) as automatic=20 may be ideal one.(SET operation is optional). Are we are not going to = accommodate command bundling, this discussion thread is converging well, = may its a correct place to=20 resolve that also. =20 =20 =20 If if I recollect correctly, in one of the teleconference - the issue of = command this issue was popped and was didn't got time to resolve. =20 =20 regards ramg -----Original Message----- From: forces-protocol-bounces@ietf.org = [mailto:forces-protocol-bounces@ietf.org]On Behalf Of ext Robert Haas Sent: Tuesday, October 19, 2004 4:08 PM To: hadi@znyx.com Cc: Khosravi, Hormuzd M; forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model = folks I hope my note makes it before Jamal's noon ... Finally I got a 3 hours = slot on a train ride (with phone off and no email access) to read the = threads ... In summary: - I think it is good to keep the query separate from config. Reasons = given by Steve/Zsolt sound very valid to me. - I am glad to see the "consolidation" into FE Protocol LFB operations = of FE attributes config, FE events, and association maintenance = messages. - The heartbeat message is currently not "targeted" at the FE protocol = LFB. It is an exception to the rule. The reasoning was to keep such = messages as short and simple as possible. Basically, you have the choice = between a heartbeat to look like this: main hdr (eg type =3D heartbeat) | | +--- T =3D LFBselect | +-- LFBCLASSID =3D FE Protocol LFB Class (=3D0x01) | | +-- LFBInstance =3D FE Protocol LFB Instance(=3D0x01) or like this: main hdr (eg type =3D heartbeat) The difference is only 6-8 bytes (I don't remember what was the final = consensus for the T in the TLV). But as the values in the LFBSelect TLV = must ALWAYS be 0x01 and 0x01 (we have statically defined the class and = instance ID of the FE protocol LFB), it is a waste to transmit them. And = if you do, then someone might use wrong values and then you have to = decide how to deal with such cases. Regards, -Robert Jamal Hadi Salim wrote:=20 On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote: =09 =20 Is there a reason you want to keep that type=3Dquery? [HK] The responses will be more involved for query,=20 also the request might be more involved.=20 =20 =09 This is true. But i dont know how you escape it with any scheme. If you ask to get, you must specify a path whether you use query or=20 config. I would think the response will also have a path and the requested data for that path. =09 =20 The other reason is that=20 I have never seen query bundled with SET/DEL in practice... =20 =09 I dont either; dont wanna rule it - but the more i think about it the more i am concluding its just about sending bundled commands. I think you can not possibly make it any simpler by introducing type=3Dquery. =09 =20 Is this a requirement from Joel or the Model team ? I didn't get that impression, but I might = have missed it. =09 =20 =09 I cant remember where it came or where the discussion took place. However, it does make logical sense given now that "everything is an LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes = to the same way: FE->LFBclass->LFBinstance->path Other than the operator, the operand to a GET is _exactly_ the same as a DEL. ADD has one extra operand. So its not really an issue of requirements; but one of a natural fit = (as in the case of SNMP for example) If you can show that you can get an object easier with type=3Dquery i think that would help. Otherwise we would have an additional unneeded message. =09 =20 6.3 -> looks good...we might still need the Flags, also the Event = Type is needed since Event Subscribe, UnSubscribe are currently part of =20 this =20 message. =20 Probably makes sense to keep event subscription under config. Sorry I missed that in my quick scan and thought it belonged to type=3Devent = in 6.4. Do we then need operation =3D Event_un/subscribe [HK] Yes I suspect that events will end up being defined in the LFB XML definition and therefore will have a path to them (eg link event in = port LFB being path 1.2.3 etc). In which case, the value of the Event_un/subscribe will be to the event. Thoughts? [HK] We could simplify this for generic events, but what you're suggesting seems reasonable. =20 =09 I think its safer to have the XML define what those events are. I sent = a query to Joel who will forward it to the model team. He seems to be in agreement. Note this will be equivalent to SNMP traps (which is defined in the mib together with other attributes). As far as i can see, the event is another attribute. So it would look like: Operation =3D subscribe; operand =3D eventpath In our case we should go ahead and choose events that are necessary for the protocol to function and put them in eitehr the FE object or FE protocol LFB. The model team can them adapt from them =20 =20 6.6 -> Fine...I am assuming the States will be exchanged in Event = msgs =20 ? =09 Since everything is an LFB, then its per LFB event - in this case i would guess the states will belong to the FE Object LFB?=20 =09 [HK] Yes they would, I have no objection to FE Object or everything being a LFB. The FE States would be part of the FE object sent in = Event msgs. =09 =20 =09 Sounds reasonable. =09 =20 6.7 -> remains the same (I assume) =20 I missed that one, sorry. Again my take is this is gone. I would think this would per FE heartebats belong to the FE Protocol LFB. [HK] No, this doesn't need to go, its just a header anyways, it = doesn't have any TLVs...its a very light weight msg, remember? I think you are confusing this with the FE Protocol Object, that doesn't have any = effect on this msg. =20 =09 But who is the target for this message now? Remember, there MUST be an LFB as the end target. =09 =20 I think that the two FE LFBs deserve speacial attention now. We need to describe what they are expected to do in more detail. We = also need to sync on them with the model people. [HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead on defining this =09 =20 =09 We may all have to be involved in these two. I think they are very important that we all need to be involved. =09 BTW, Heres a suggestions: =09 If we dont hear from anybody by Tuesday(I know Weiming mentioned something about being back Monday), lets start assuming noone will and move towards updating the draft to beat the deadline. I dont think people will mind if they are busy. =09 cheers, jamal =09 =09 =09 =09 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol =09 =09 =20 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha ------_=_NextPart_001_01C4B6CE.1BC78291 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Ram,
 
I don't think this is related to command = bundling...we will=20 still support cmd bundling especially for Config (Add/Del/Update,=20 etc...)
Pls refer to all the emails posted on this = topic and it=20 will be clear.
 
Thanks
Hormuzd

From: = forces-protocol-bounces@ietf.org=20 [mailto:forces-protocol-bounces@ietf.org] On Behalf Of=20 ram.gopal@nokia.com
Sent: Wednesday, October 20, 2004 2:30 = AM
To: rha@zurich.ibm.com; hadi@znyx.com; Khosravi, Hormuzd=20 M
Cc: forces-protocol@ietf.org
Subject: RE:=20 [Forces-protocol] RE: sync with BNF as discussed with model=20 folks

Hello,
 
Agree.=20 Keeping config and query makes simpler.
 
But=20 another point is forces is mostly going to be used as configuration = protocol, in=20 may case GET/(and SET) as automatic
may be=20 ideal one.(SET operation is optional). Are we are not going to = accommodate=20 command bundling, this discussion thread is converging well, may its a = correct=20 place to
resolve that also.
 
 
 
If if=20 I recollect correctly, in one of the teleconference - the issue of = command this=20 issue was popped and was didn't got time to resolve.
 
 
regards
ramg
-----Original Message-----
From:=20 forces-protocol-bounces@ietf.org = [mailto:forces-protocol-bounces@ietf.org]On=20 Behalf Of ext Robert Haas
Sent: Tuesday, October 19, 2004 = 4:08=20 PM
To: hadi@znyx.com
Cc: Khosravi, Hormuzd M;=20 forces-protocol@ietf.org
Subject: Re: [Forces-protocol] RE: = sync with=20 BNF as discussed with model folks

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

In = summary:

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

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

- The heartbeat = message is=20 currently not "targeted" at the FE protocol LFB. It is an exception to = the rule.=20 The reasoning was to keep such messages as short and simple as possible. = Basically, you have the choice between a heartbeat to look like = this:
main hdr (eg type =3D heartbeat)
      |
      |
      +--- T =3D LFBselect
               |
               +-- LFBCLASSID =3D =
FE Protocol LFB Class (=3D0x01)
               |
               |
               +-- LFBInstance =3D =
FE Protocol LFB Instance(=3D0x01)
or=20 like this:
main hdr (eg type =3D =
heartbeat)

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

Regards,
-Robert

Jamal Hadi Salim wrote:=20 
On Fri, 2004-10-15 at 01:33, Khosravi, =
Hormuzd M wrote:

  
Is there a reason you want to =
keep that type=3Dquery?
[HK] The responses will be more involved for query,=20
also the request <path> might be more involved.=20
    

This is true. But i dont know how you escape it with any scheme.
If you ask to get, you must specify a path whether you use query or=20
config. I would think the response will also have a path and the
requested data for that path.

  
The other reason is that=20
I have never seen query bundled with SET/DEL in practice...
    

I dont either; dont wanna rule it - but the more i think about it the
more i am concluding its just about sending bundled commands. I think
you can not possibly make it any simpler by introducing type=3Dquery.

  
Is this a requirement from
Joel or the Model team ? I didn't get that impression, but I might have
missed it.

    

I cant remember where it came or where the discussion took place.
However, it does make logical sense given now that "everything is an
LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to
the same way: FE->LFBclass->LFBinstance->path
Other than the operator, the operand to a GET is _exactly_ the same
as a DEL. ADD has one extra operand.
So its not really an issue of requirements; but one of a natural fit (as
in the case of SNMP for example)
If you can show that you can get an object easier with type=3Dquery i
think that would help. Otherwise we would have an additional unneeded
message.

  
6.3 -> looks good...we =
might still need the Flags, also the Event Type
is needed since Event Subscribe, UnSubscribe are currently part of
      
this
    
message.
      
Probably makes sense to keep =
event subscription under config. Sorry
I missed that in my quick scan and thought it belonged to type=3Devent =
in
6.4.
Do we then need operation =3D Event_un/subscribe [HK] Yes
I suspect that events will end up being defined in the LFB XML
definition and therefore will have a path to them (eg link event in port
LFB being path 1.2.3 etc).
In which case, the value of the Event_un/subscribe will be to the
event.
Thoughts? [HK] We could simplify this for generic events, but what
you're suggesting seems reasonable.
    

I think its safer to have the XML define what those events are. I sent a
query to Joel who will forward it to the model team. He seems to be in
agreement. Note this will be equivalent to SNMP traps (which is defined
in the mib together with other attributes).
As far as i can see, the event is another attribute. So it would look
like:
Operation =3D subscribe; operand =3D eventpath
In our case we should go ahead and choose events that are necessary for
the protocol to function and put them in eitehr the FE object or FE
protocol LFB. The model team can them adapt from them
 =20
  
6.6 -> Fine...I am =
assuming the States will be exchanged in Event msgs
      
?

Since everything is an LFB, then its per LFB event - in this case i
would guess the states will belong to the FE Object LFB?=20

[HK] Yes they would, I have no objection to FE Object or everything
being a LFB. The FE States would be part of the FE object sent in Event
msgs.

    

Sounds reasonable.

  
6.7 -> remains the same =
(I assume)
      
I missed that one, sorry.
Again my take is this is gone. I would think this would per FE
heartebats belong to the FE Protocol LFB.
[HK] No, this doesn't need to go, its just a header anyways, it doesn't
have any TLVs...its a very light weight msg, remember? I think you are
confusing this with the FE Protocol Object, that doesn't have any effect
on this msg.
    

But who is the target for this message now?
Remember, there MUST be an LFB as the end target.

  
I think that the two FE LFBs =
deserve speacial attention now.
We need to describe what they are expected to do in more detail. We also
need to sync on them with the model people.
[HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead
on defining this

    

We may all have to be involved in these two. I think they are very
important that we all need to be involved.

BTW, Heres a suggestions:

If we dont hear from anybody by Tuesday(I know Weiming mentioned
something about being back Monday), lets start assuming noone will
and move towards updating the draft to beat the deadline.
I dont think people will mind if they are busy.

cheers,
jamal




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


  

--=20
Robert Haas
IBM Zurich Research Laboratory
S=E4umerstrasse 4
CH-8803 R=FCschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
------_=_NextPart_001_01C4B6CE.1BC78291-- --===============0026628730== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0026628730==-- From forces-protocol-bounces@ietf.org Thu Oct 21 08:05:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11767 for ; Thu, 21 Oct 2004 08:05:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbtM-00072U-Iq for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 08:18:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKaoP-0002fV-JU; Thu, 21 Oct 2004 07:08:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKM07-00072G-0b for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 15:19:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14562 for ; Wed, 20 Oct 2004 15:19:46 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKMCO-0002NY-Sw for forces-protocol@ietf.org; Wed, 20 Oct 2004 15:32:42 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9KJN5bh017096; Wed, 20 Oct 2004 19:23:05 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9KJBYLb015997; Wed, 20 Oct 2004 19:12:58 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102012191208763 ; Wed, 20 Oct 2004 12:19:12 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 12:19:12 -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 Subject: RE: [Forces-protocol] Re: protocol draft editing? Date: Wed, 20 Oct 2004 12:19:11 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02F5D468@orsmsx408> Thread-Topic: [Forces-protocol] Re: protocol draft editing? Thread-Index: AcS2oVDXlJWLNIA1TxuIMihRy7Oy9wALM7WQ From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 20 Oct 2004 19:19:12.0841 (UTC) FILETIME=[AEB40B90:01C4B6D9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: avri@psg.com, ram.gopal@nokia.com, Weiming Wang , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Here is the distribution list... Abstract - Avri 1. Introduction - Avri 2. Definitions - Weiming 3. Protocol Overview - Jamal 4. TML Requirements - Jamal 5. Common Header - Weiming, Ligang (Jamal/Robert) 6. Protocol Messages - Hormuzd, Weiming (I expect everyone to be involved with this one) 7. Protocol Scenarios - Hormuzd, Ram 8. High Availability - Hormuzd 9. Security Considerations - Ram 10. References - Avri 11. Acknowledgments - All Appendix A. Implementation Notes - All? I will directly modify the text for my particular section and send it out to the team/Avri on a per section or per-subsection basis. That was we can all work in parallel. regards Hormuzd=20 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Wednesday, October 20, 2004 5:35 AM To: forces-protocol@ietf.org Cc: avri@psg.com; Khosravi, Hormuzd M; ram.gopal@nokia.com; Ligang Dong; Weiming Wang; Robert Haas Subject: Re: [Forces-protocol] Re: protocol draft editing? Avri must be on travel or tied up somewhere around the globe. The latest i could find is: http://psg.com/~avri/forces/draft/Archive-Forces-Protocol-02.zip Does anyone know if theres something newer or should we start here? Hormuzd can you post that todo distribution? cheers, jamal On Tue, 2004-10-19 at 19:23, Jamal Hadi Salim wrote: > On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote: > > Now that we seem to have made progress on the basics.. > > Avri, > > Could you post a URL to the xml docs that we could start editing? > > We could start with the TODO action items as posted by Hormuzd. > >=20 > > cheers, > > jamal >=20 >=20 > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 08:06:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11987 for ; Thu, 21 Oct 2004 08:06:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbuc-00076V-UH for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 08:19:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKap4-0004BB-G6; Thu, 21 Oct 2004 07:09:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKMGn-0004TU-PY for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 15:37:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16598 for ; Wed, 20 Oct 2004 15:37:01 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKMT6-0002vS-4W for forces-protocol@ietf.org; Wed, 20 Oct 2004 15:49:57 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9KJb7UX016594; Wed, 20 Oct 2004 19:37:07 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9KJTcLD027344; Wed, 20 Oct 2004 19:30:15 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102012363012001 ; Wed, 20 Oct 2004 12:36:30 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 12:36:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Forces-protocol] RE: sync with BNF as discussed with model folks Date: Wed, 20 Oct 2004 12:36:28 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02F5D4B8@orsmsx408> Thread-Topic: [Forces-protocol] RE: sync with BNF as discussed with model folks Thread-Index: AcS2eoqQC8S+d+rgSZelopFRt78z7QAYQAHw From: "Khosravi, Hormuzd M" To: "Robert Haas" , X-OriginalArrivalTime: 20 Oct 2004 19:36:29.0878 (UTC) FILETIME=[18D35560:01C4B6DC] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.6 (/) X-Scan-Signature: 8353da2fde044920180672209f5bf8a0 Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1689846478==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: eee8f8a810071652260f5b6c3a710e46 This is a multi-part message in MIME format. --===============1689846478== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B6DC.186BEBFE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B6DC.186BEBFE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jamal, =20 I am not sure if you recall, but we had a ton of discussion on HBs = during the last protocol draft before we decided to support them as = minimal msgs (only header) with least possible overhead. Let me know if = you would like me to forward you some of the emails (I will do so = privately if needed), but I hope this issue doesn't take up a lot of our = bandwidth again. =20 regards Hormuzd ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Wednesday, October 20, 2004 12:55 AM To: hadi@znyx.com Cc: Khosravi, Hormuzd M; forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model = folks Jamal, I don't see the point of sending a heartbeat to any LFB other than the = FE Protocol LFB. Here is why: The PL-level heartbeat is really about saying: the sender (FE or CE) of = this hearbeat is alive. FEs will typically be sending this to their CE = (after the CE has configured in the FE Protocol LFB at what frequency it = wants to receive heartbeats). Note that in the current draft we have = explicitely asked to ignore any ACK flag that would be set in the = hearbeat message header. If what you want to have is a ECHO-REQUEST/ECHO-REPLY to a particular = LFB (to check its status, etc), what should be used instead is a Query = msg with GET(status of the particular LFB instance). Would this answer = your needs ? -Robert Jamal Hadi Salim wrote: Robert, Could someone not send a heartbeat to a specific LFB? In which case a heartbe to the FE object equates a heartbeat to the FE. =09 cheers, jamal =09 On Tue, 2004-10-19 at 16:07, Robert Haas wrote: =20 I hope my note makes it before Jamal's noon ... Finally I got a 3 hours slot on a train ride (with phone off and no email access) to read the threads ... =09 In summary: =09 - I think it is good to keep the query separate from config. Reasons given by Steve/Zsolt sound very valid to me. =09 - I am glad to see the "consolidation" into FE Protocol LFB operations of FE attributes config, FE events, and association maintenance messages. =09 - The heartbeat message is currently not "targeted" at the FE protocol LFB. It is an exception to the rule. The reasoning was to keep such messages as short and simple as possible. Basically, you have the choice between a heartbeat to look like this: =09 main hdr (eg type =3D heartbeat) | | +--- T =3D LFBselect | +-- LFBCLASSID =3D FE Protocol LFB Class (=3D0x01) | | +-- LFBInstance =3D FE Protocol LFB Instance(=3D0x01) or like this: =09 main hdr (eg type =3D heartbeat) The difference is only 6-8 bytes (I don't remember what was the final consensus for the T in the TLV). But as the values in the LFBSelect TLV must ALWAYS be 0x01 and 0x01 (we have statically defined the class and instance ID of the FE protocol LFB), it is a waste to transmit them. And if you do, then someone might use wrong values and then you have to decide how to deal with such cases. =09 Regards, -Robert =09 Jamal Hadi Salim wrote:=20 =20 On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote: =09 =20 =20 Is there a reason you want to keep that type=3Dquery? [HK] The responses will be more involved for query,=20 also the request might be more involved.=20 =20 =20 This is true. But i dont know how you escape it with any scheme. If you ask to get, you must specify a path whether you use query or=20 config. I would think the response will also have a path and the requested data for that path. =09 =20 =20 The other reason is that=20 I have never seen query bundled with SET/DEL in practice... =20 =20 I dont either; dont wanna rule it - but the more i think about it the more i am concluding its just about sending bundled commands. I think you can not possibly make it any simpler by introducing type=3Dquery. =09 =20 =20 Is this a requirement from Joel or the Model team ? I didn't get that impression, but I might = have missed it. =09 =20 =20 I cant remember where it came or where the discussion took place. However, it does make logical sense given now that "everything is an LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes = to the same way: FE->LFBclass->LFBinstance->path Other than the operator, the operand to a GET is _exactly_ the same as a DEL. ADD has one extra operand. So its not really an issue of requirements; but one of a natural fit = (as in the case of SNMP for example) If you can show that you can get an object easier with type=3Dquery i think that would help. Otherwise we would have an additional unneeded message. =09 =20 =20 6.3 -> looks good...we might still need the Flags, also the Event = Type is needed since Event Subscribe, UnSubscribe are currently part of =20 =20 this =20 =20 message. =20 =20 Probably makes sense to keep event subscription under config. Sorry I missed that in my quick scan and thought it belonged to = type=3Devent in 6.4. Do we then need operation =3D Event_un/subscribe [HK] Yes I suspect that events will end up being defined in the LFB XML definition and therefore will have a path to them (eg link event in = port LFB being path 1.2.3 etc). In which case, the value of the Event_un/subscribe will be to the event. Thoughts? [HK] We could simplify this for generic events, but what you're suggesting seems reasonable. =20 =20 I think its safer to have the XML define what those events are. I = sent a query to Joel who will forward it to the model team. He seems to be = in agreement. Note this will be equivalent to SNMP traps (which is = defined in the mib together with other attributes). As far as i can see, the event is another attribute. So it would look like: Operation =3D subscribe; operand =3D eventpath In our case we should go ahead and choose events that are necessary = for the protocol to function and put them in eitehr the FE object or FE protocol LFB. The model team can them adapt from them =20 =20 =20 6.6 -> Fine...I am assuming the States will be exchanged in Event = msgs =20 =20 ? =09 Since everything is an LFB, then its per LFB event - in this case i would guess the states will belong to the FE Object LFB?=20 =09 [HK] Yes they would, I have no objection to FE Object or everything being a LFB. The FE States would be part of the FE object sent in = Event msgs. =09 =20 =20 Sounds reasonable. =09 =20 =20 6.7 -> remains the same (I assume) =20 =20 I missed that one, sorry. Again my take is this is gone. I would think this would per FE heartebats belong to the FE Protocol LFB. [HK] No, this doesn't need to go, its just a header anyways, it = doesn't have any TLVs...its a very light weight msg, remember? I think you = are confusing this with the FE Protocol Object, that doesn't have any = effect on this msg. =20 =20 But who is the target for this message now? Remember, there MUST be an LFB as the end target. =09 =20 =20 I think that the two FE LFBs deserve speacial attention now. We need to describe what they are expected to do in more detail. We = also need to sync on them with the model people. [HK] Sure, agree on this..I was hoping Robert/Weiming will take a = lead on defining this =09 =20 =20 We may all have to be involved in these two. I think they are very important that we all need to be involved. =09 BTW, Heres a suggestions: =09 If we dont hear from anybody by Tuesday(I know Weiming mentioned something about being back Monday), lets start assuming noone will and move towards updating the draft to beat the deadline. I dont think people will mind if they are busy. =09 cheers, jamal =09 =09 =09 =09 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol =09 =09 =20 =20 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 = http://www.zurich.ibm.com/~rha =20 =09 =09 =09 =20 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha ------_=_NextPart_001_01C4B6DC.186BEBFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jamal,
 
I am not sure if you recall, but we had a ton = of discussion=20 on HBs during the last protocol draft before we decided to support them = as=20 minimal msgs (only header) with least possible overhead. Let me know if = you=20 would like me to forward you some of the emails (I will do so privately = if=20 needed), but I hope this issue doesn't take up a lot of our bandwidth=20 again.
 
regards
Hormuzd

From: Robert Haas = [mailto:rha@zurich.ibm.com]=20
Sent: Wednesday, October 20, 2004 12:55 AM
To:=20 hadi@znyx.com
Cc: Khosravi, Hormuzd M;=20 forces-protocol@ietf.org
Subject: Re: [Forces-protocol] RE: = sync with=20 BNF as discussed with model folks

Jamal,
I don't see the point of sending a heartbeat to any = LFB=20 other than the FE Protocol LFB. Here is why:

The PL-level = heartbeat is=20 really about saying: the sender (FE or CE) of this hearbeat is alive. = FEs will=20 typically be sending this to their CE (after the CE has configured in = the FE=20 Protocol LFB at what frequency it wants to receive heartbeats). Note = that in the=20 current draft we have explicitely asked to ignore any ACK flag that = would be set=20 in the hearbeat message header.

If what you want to have is a=20 ECHO-REQUEST/ECHO-REPLY to a particular LFB (to check its status, etc), = what=20 should be used instead is a Query msg with GET(status of the particular = LFB=20 instance). Would this answer your needs = ?

-Robert


Jamal Hadi=20 Salim wrote:
Robert,
Could someone not send a heartbeat to a specific LFB?
In which case a heartbe to the FE object equates a heartbeat to the FE.

cheers,
jamal

On Tue, 2004-10-19 at 16:07, Robert Haas wrote:
  
I hope my note makes it =
before Jamal's noon ... Finally I got a 3
hours slot on a train ride (with phone off and no email access) to
read the threads ...

In summary:

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

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

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

main hdr (eg type =3D heartbeat)
      |
      |
      +--- T =3D LFBselect
               |
               +-- LFBCLASSID =3D FE Protocol LFB Class (=3D0x01)
               |
               |
               +-- LFBInstance =3D FE Protocol LFB Instance(=3D0x01)
or like this:

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

Regards,
-Robert

Jamal Hadi Salim wrote:=20
    
On Fri, 2004-10-15 at =
01:33, Khosravi, Hormuzd M wrote:

 =20
      
Is there a reason you =
want to keep that type=3Dquery?
[HK] The responses will be more involved for query,=20
also the request <path> might be more involved.=20
   =20
        
This is true. But i dont know =
how you escape it with any scheme.
If you ask to get, you must specify a path whether you use query or=20
config. I would think the response will also have a path and the
requested data for that path.

 =20
      
The other reason is that=20
I have never seen query bundled with SET/DEL in practice...
   =20
        
I dont either; dont wanna rule =
it - but the more i think about it the
more i am concluding its just about sending bundled commands. I think
you can not possibly make it any simpler by introducing type=3Dquery.

 =20
      
Is this a requirement =
from
Joel or the Model team ? I didn't get that impression, but I might have
missed it.

   =20
        
I cant remember where it came =
or where the discussion took place.
However, it does make logical sense given now that "everything is an
LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to
the same way: FE->LFBclass->LFBinstance->path
Other than the operator, the operand to a GET is _exactly_ the same
as a DEL. ADD has one extra operand.
So its not really an issue of requirements; but one of a natural fit (as
in the case of SNMP for example)
If you can show that you can get an object easier with type=3Dquery i
think that would help. Otherwise we would have an additional unneeded
message.

 =20
      
6.3 -> looks =
good...we might still need the Flags, also the Event Type
is needed since Event Subscribe, UnSubscribe are currently part of
     =20
          
this
   =20
        
message.
     =20
          
Probably makes sense to keep =
event subscription under config. Sorry
I missed that in my quick scan and thought it belonged to type=3Devent =
in
6.4.
Do we then need operation =3D Event_un/subscribe [HK] Yes
I suspect that events will end up being defined in the LFB XML
definition and therefore will have a path to them (eg link event in port
LFB being path 1.2.3 etc).
In which case, the value of the Event_un/subscribe will be to the
event.
Thoughts? [HK] We could simplify this for generic events, but what
you're suggesting seems reasonable.
   =20
        
I think its safer to have the =
XML define what those events are. I sent a
query to Joel who will forward it to the model team. He seems to be in
agreement. Note this will be equivalent to SNMP traps (which is defined
in the mib together with other attributes).
As far as i can see, the event is another attribute. So it would look
like:
Operation =3D subscribe; operand =3D eventpath
In our case we should go ahead and choose events that are necessary for
the protocol to function and put them in eitehr the FE object or FE
protocol LFB. The model team can them adapt from them
 =20
 =20
      
6.6 -> Fine...I am =
assuming the States will be exchanged in Event msgs
     =20
          
?

Since everything is an LFB, then its per LFB event - in this case i
would guess the states will belong to the FE Object LFB?=20

[HK] Yes they would, I have no objection to FE Object or everything
being a LFB. The FE States would be part of the FE object sent in Event
msgs.

   =20
        
Sounds reasonable.

 =20
      
6.7 -> remains the =
same (I assume)
     =20
          
I missed that one, sorry.
Again my take is this is gone. I would think this would per FE
heartebats belong to the FE Protocol LFB.
[HK] No, this doesn't need to go, its just a header anyways, it doesn't
have any TLVs...its a very light weight msg, remember? I think you are
confusing this with the FE Protocol Object, that doesn't have any effect
on this msg.
   =20
        
But who is the target for this =
message now?
Remember, there MUST be an LFB as the end target.

 =20
      
I think that the two FE =
LFBs deserve speacial attention now.
We need to describe what they are expected to do in more detail. We also
need to sync on them with the model people.
[HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead
on defining this

   =20
        
We may all have to be involved =
in these two. I think they are very
important that we all need to be involved.

BTW, Heres a suggestions:

If we dont hear from anybody by Tuesday(I know Weiming mentioned
something about being back Monday), lets start assuming noone will
and move towards updating the draft to beat the deadline.
I dont think people will mind if they are busy.

cheers,
jamal




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


 =20
      
--=20
Robert Haas
IBM Zurich Research Laboratory
S=E4umerstrasse 4
CH-8803 R=FCschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
    



  

--=20
Robert Haas
IBM Zurich Research Laboratory
S=E4umerstrasse 4
CH-8803 R=FCschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
------_=_NextPart_001_01C4B6DC.186BEBFE-- --===============1689846478== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1689846478==-- From forces-protocol-bounces@ietf.org Thu Oct 21 08:31:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15650 for ; Thu, 21 Oct 2004 08:31:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcJG-000854-IS for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 08:44:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKb7V-0000XY-4g; Thu, 21 Oct 2004 07:28:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKSqR-00075s-Tw for forces-protocol@megatron.ietf.org; Wed, 20 Oct 2004 22:38:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14500 for ; Wed, 20 Oct 2004 22:38:15 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKT2m-0002wF-Ec for forces-protocol@ietf.org; Wed, 20 Oct 2004 22:51:15 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9L2cIUX029842; Thu, 21 Oct 2004 02:38:19 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9L2VHKx008442; Thu, 21 Oct 2004 02:31:24 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102019374003326 ; Wed, 20 Oct 2004 19:37:40 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 19:37:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4B716.EE6FB23F" Date: Wed, 20 Oct 2004 19:37:38 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02F5DD34@orsmsx408> X-MS-Has-Attach: yes Thread-Topic: Updated HA section Thread-Index: AcS2yC6Vme9DgLO8Tcm9zbsiVyf3RwATdqUA From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 21 Oct 2004 02:37:40.0210 (UTC) FILETIME=[EF1DFD20:01C4B716] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Weiming Wang , Ligang Dong , Robert Haas Subject: [Forces-protocol] Updated HA section X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B716.EE6FB23F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Team, Here is the updated HA section.=20 I removed the Editorial Note, added clarification regarding the fact that FE-FE is currently out of scope, incorporated comments that I received on the list (Furquan). Pls do let me know if there are any other suggestions/comments. regards Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 Sent: Wednesday, October 20, 2004 9:17 AM To: forces-protocol@ietf.org Cc: Jamal Hadi Salim; ram.gopal@nokia.com; Khosravi, Hormuzd M; Ligang Dong; Robert Haas; Weiming Wang Subject: Re: [Forces-protocol] Re: protocol draft editing? hi, you will find a zip, a tar and a tgz in=20 http://psg.com/~avri/forces/draft/ Please let this list know when you are working on a file. And for simplicity sake it is easier if it is one person per file at a=20 time. cheers a. ------_=_NextPart_001_01C4B716.EE6FB23F Content-Type: text/plain; name="HA-section-new.txt" Content-Description: HA-section-new.txt Content-Disposition: attachment; filename="HA-section-new.txt" Content-Transfer-Encoding: base64 OC4gSGlnaCBBdmFpbGFiaWxpdHkgU3VwcG9ydCAoQ0UgZmFpbG92ZXIgU3VwcG9ydCkNCg0KICAg VGhlIEZvckNFUyBwcm90b2NvbCBwcm92aWRlcyBtZWNoYW5pc21zIGZvciBDRSByZWR1bmRhbmN5 IGFuZA0KICAgZmFpbG92ZXIsIGluIG9yZGVyIHRvIHN1cHBvcnQgSGlnaCBBdmFpbGFiaWxpdHkg YXMgcGVyIFJlcXNbXS4gRkUgDQpyZWR1bmRhbmN5IGFuZCBGRSB0byBGRQ0KaW50ZXJhY3Rpb24g aXMgY3VycmVudGx5IG91dCBvZiBzY29wZSBvZiB0aGlzIGRyYWZ0LiBUaGVyZSBjYW4gYmUNCiAg IG11bHRpcGxlIHJlZHVuZGFudCBDRXMgYW5kIEZFcyBpbiBhIEZvckNFUyBORS4gIEhvd2V2ZXIs IGF0IGFueSB0aW1lDQogICB0aGVyZSBjYW4gb25seSBiZSBvbmUgUHJpbWFyeSBDRSBjb250cm9s bGluZyB0aGUgRkVzIGFuZCB0aGVyZSBjYW4gYmUNCiAgIG11bHRpcGxlIHNlY29uZGFyeSBDRXMu ICBUaGUgRkUgYW5kIHRoZSBDRSBQTCBhcmUgYXdhcmUgb2YgdGhlDQogICBwcmltYXJ5IGFuZCBz ZWNvbmRhcnkgQ0VzLiAgVGhpcyBpbmZvcm1hdGlvbiAocHJpbWFyeSwgc2Vjb25kYXJ5IENFcykN CiAgIGlzIGNvbmZpZ3VyZWQgaW4gdGhlIEZFLCBDRSBQTHMgZHVyaW5nIHByZS1hc3NvY2lhdGlv biBieSBGRU0sIENFTQ0KICAgcmVzcGVjdGl2ZWx5LiAgT25seSB0aGUgcHJpbWFyeSBDRSBzZW5k cyBDb250cm9sIG1lc3NhZ2VzIHRvIHRoZSBGRXMuDQogICBUaGUgRkUgbWF5IHNlbmQgaXRzIGV2 ZW50IHJlcG9ydHMsIHJlZGlyZWN0aW9uIHBhY2tldHMgdG8gb25seSB0aGUNCiAgIFByaW1hcnkg Q0UgKFJlcG9ydCBQcmltYXJ5IE1vZGUpIG9yIGl0IG1heSBzZW5kIHRoZXNlIHRvIGJvdGggcHJp bWFyeQ0KICAgYW5kIHNlY29uZGFyeSBDRXMgKFJlcG9ydCBBbGwgTW9kZSkuICAoVGhlIGxhdHRl ciBoZWxwcyB3aXRoIGtlZXBpbmcNCiAgIHN0YXRlIGJldHdlZW4gQ0VzIHN5bmNocm9uaXplZCwg YWx0aG91Z2ggaXQgZG9lcyBub3QgZ3VhcmFudGVlDQogICBzeW5jaHJvbml6YXRpb24uKSBUaGlz IGJlaGF2aW9yIG9yIEhBIE1vZGVzIGFyZSBjb25maWd1cmVkIGR1cmluZw0KICAgQXNzb2NpYXRp b24gc2V0dXAgcGhhc2UgYnV0IGNhbiBiZSBjaGFuZ2VkIGJ5IHRoZSBDRSBhbnl0aW1lIGR1cmlu Zw0KICAgcHJvdG9jb2wgb3BlcmF0aW9uLiAgQSBDRS10by1DRSBzeW5jaHJvbml6YXRpb24gcHJv dG9jb2wgd2lsbCBiZQ0KICAgbmVlZGVkIGluIG1vc3QgY2FzZXMgdG8gc3VwcG9ydCBmYXN0IGZh aWxvdmVyLCBob3dldmVyIHRoaXMgd2lsbCBub3QNCiAgIGJlIGRlZmluZWQgYnkgdGhlIEZvckNF UyBwcm90b2NvbC4NCg0KICAgRHVyaW5nIGEgY29tbXVuaWNhdGlvbiBmYWlsdXJlIGJldHdlZW4g dGhlIEZFIGFuZCBDRSAod2hpY2ggaXMgY2F1c2VkDQogICBkdWUgdG8gQ0Ugb3IgbGluayByZWFz b25zLCBpLmUuICBub3QgRkUgcmVsYXRlZCksIHRoZSBUTUwgb24gdGhlIEZFDQogICB3aWxsIHRy aWdnZXIgdGhlIEZFIFBMIHJlZ2FyZGluZyB0aGlzIGZhaWx1cmUuIFRoaXMgY2FuIGFsc28gYmUg ZGV0ZWN0ZWQgDQp1c2luZyB0aGUgSEIgbWVzc2FnZXMgYmV0d2VlbiBGRXMgYW5kIENFcy4gVGhl IEZFIFBMIHdpbGwgc2VuZCBhDQogICBtZXNzYWdlIChFdmVudCBSZXBvcnQpIHRvIHRoZSBTZWNv bmRhcnkgQ0VzIHRvIGluZGljYXRlIHRoaXMgZmFpbHVyZQ0KICAgb3IgdGhlIENFIFBMIHdpbGwg ZGV0ZWN0IHRoaXMgYW5kIG9uZSBvZiB0aGUgU2Vjb25kYXJ5IENFcyB0YWtlcyBvdmVyDQogICBh cyB0aGUgcHJpbWFyeSBDRSBmb3IgdGhlIEZFLiAgRHVyaW5nIHRoaXMgcGhhc2UsIGlmIHRoZSBv cmlnaW5hbCBwcmltYXJ5DQpDRSBjb21lcyBhbGl2ZSBhbmQgc3RhcnRzIHNlbmRpbmcgYW55IGNv bW1hbmRzIHRvIHRoZSBGRSwgdGhlIEZFIHNob3VsZCANCmlnbm9yZSB0aG9zZSBtZXNzYWdlcyBh bmQgc2VuZCBhbiBFdmVudCB0byBhbGwgQ0VzIGluZGljYXRpbmcgaXRzIGNoYW5nZSBpbg0KUHJp bWFyeSBDRS4gVGh1cyB0aGUgRkUgb25seSBoYXMgb25lIHByaW1hcnkgQ0UgYXQgYSB0aW1lLg0K DQpBbiBleHBsaWNpdCBtZXNzYWdlIChDb25maWcgbWVzc2FnZS0NCiAgIE1vdmUgY29tbWFuZCkg ZnJvbSB0aGUgcHJpbWFyeSBDRSwgY2FuIGFsc28gYmUgdXNlZCB0byBjaGFuZ2UgdGhlDQogICBQ cmltYXJ5IENFIGZvciBhbiBGRSBkdXJpbmcgbm9ybWFsIHByb3RvY29sIG9wZXJhdGlvbi4gIElu IG9yZGVyIHRvDQogICBzdXBwb3J0IGZhc3QgZmFpbG92ZXIsIHRoZSBGRSB3aWxsIGVzdGFibGlz aCBhc3NvY2lhdGlvbiAoc2V0dXAgbXNnKQ0KICAgYXMgd2VsbCBhcyBjb21wbGV0ZSB0aGUgY2Fw YWJpbGl0eSBleGNoYW5nZSB3aXRoIHRoZSBQcmltYXJ5IGFzIHdlbGwNCiAgIGFzIGFsbCB0aGUg U2Vjb25kYXJ5IENFcyAoaW4gYWxsIHNjZW5hcmlvcy9tb2RlcykuDQoNCiAgIFRoZXNlIHR3byBz Y2VuYXJpb3MgKFJlcG9ydCBBbGwsIFJlcG9ydCBQcmltYXJ5KSBoYXZlIGJlZW4NCiAgIGlsbHVz dHJhdGVkIGluIHRoZSBmaWd1cmVzIGJlbG93Lg0KDQoNCiAgICAgICAgICAgICAgICAgICAgIEZF ICAgICAgICAgICAgICAgICAgICAgIENFIFByaW1hcnkgICAgICAgICBDRSBTZWNvbmRhcnkNCiAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgQXNzbyBFc3RiLENhcHMgZXhj aGcgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAxIHw8LS0t LS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICBBc3NvIEVzdGIsQ2Fwc3xleGNoYW5n ZSAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAyIHw8LS0tLS0tLS0tLS0tLS0t LS0tLS0tLXwtLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgIEFsbCBtc2dzICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAzIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgcGFja2V0IHJlZGlyZWN0aW9uLHxldmVudHMsIEhCcyAgICAgICAgIHwNCiAgICAgICAg ICAgICAgICAgICAgICA0IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwtLS0tLS0tLS0tLS0tLS0t LS0tPnwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgRkFJTFVSRSAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgRXZlbnQgUmVwb3J0IChwcmkgQ0UgZG93 bikgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICA1IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICBBbGwgTXNncyAgICAgICAgICAgICAgICAgIHwNCiAg ICAgICAgICAgICAgICAgICAgICA2IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPnwNCg0KDQogICAgICAgICAgICAgICBGaWd1cmUgMzA6IENFIEZhaWxvdmVyIGZv ciBSZXBvcnQgQWxsIG1vZGUNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICBGRSAgICAgICAg ICAgICAgICAgICBDRSBQcmltYXJ5ICAgICAgICBDRSBTZWNvbmRhcnkNCiAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICAgICAgICAgICAgICAgICAgIHwgIEFzc28gRXN0YixDYXBzIGV4Y2hnIHwgICAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAxIHw8LS0tLS0tLS0tLS0tLS0t LS0tLS0tPnwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICBBc3NvIEVzdGIsQ2Fwc3xleGNoYW5nZSAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAyIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwtLS0t LS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgQWxsIG1zZ3MgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAg ICAgICAgICAgICAgICAzIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAoSGVhcnRCZWF0c3wgb25seSkgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAg ICA0IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwtLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgRkFJ TFVSRSAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgIEV2ZW50IFJlcG9ydCAocHJpIENFIGRvd24pICAgIHwNCiAg ICAgICAgICAgICAgICAgICAgICA1IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgQWxsIE1zZ3MgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgICA2IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwN Cg0KDQogICAgICAgICAgICAgRmlndXJlIDMxOiBDRSBGYWlsb3ZlciBmb3IgUmVwb3J0IFByaW1h cnkgTW9kZQ0KDQoNCjguMSAgUmVzcG9uc2liaWxpdGllcyBmb3IgSEENCg0KICAgVE1MIGxldmVs IC0gVHJhbnNwb3J0IGxldmVsOg0KICAgMS4gIFRoZSBUTUwgY29udHJvbHMgbG9naWNhbCBjb25u ZWN0aW9uIGF2YWlsYWJpbGl0eSBhbmQgZmFpbG92ZXIuDQogICAyLiAgVGhlIFRNTCBhbHNvIGNv bnRyb2xzIHBlZXIgSEEgbWFuYWdlbWVudHMuDQoNCiAgIEF0IHRoaXMgbGV2ZWwsIGNvbnRyb2wg b2YgYWxsIGxvd2VyIGxheWVycyBleGFtcGxlIHRyYW5zcG9ydCBsZXZlbA0KICAgKHN1Y2ggYXMg SVAgYWRkcmVzc2VzLCBNQUMgYWRkcmVzc2VzIGV0YykgYW5kIGFzc29jaWF0ZWQgbGlua3MgZ29p bmcNCiAgIGRvd24gYXJlIHRoZSByb2xlIG9mIHRoZSBUTUwuDQoNCiAgIFBMIExldmVsOg0KICAg QWxsIHRoZSBvdGhlciBmdW5jdGlvbmFsaXR5IGluY2x1ZGluZyBjb25maWd1cmluZyB0aGUgSEEg YmVoYXZpb3INCiAgIGR1cmluZyBzZXR1cCwgdGhlIENFSURzIGFyZSB1c2VkIHRvIGlkZW50aWZ5 IHByaW1hcnksIHNlY29uZGFyeSBDRXMsDQogICBwcm90b2NvbCBNZXNzYWdlcyB1c2VkIHRvIHJl cG9ydCBDRSBmYWlsdXJlIChFdmVudCBSZXBvcnQpLCBIZWFydGJlYXQNCiAgIG1lc3NhZ2VzIHVz ZWQgdG8gZGV0ZWN0IGFzc29jaWF0aW9uIGZhaWx1cmUsIG1lc3NhZ2VzIHRvIGNoYW5nZQ0KICAg cHJpbWFyeSBDRSAoQ29uZmlnIC0gbW92ZSksIGFuZCBvdGhlciBIQSByZWxhdGVkIG9wZXJhdGlv bnMNCiAgIGRlc2NyaWJlZCBiZWZvcmUgYXJlIHRoZSBQTCByZXNwb25zaWJpbGl0eS4NCg0KICAg VG8gcHV0IHRoZSB0d28gdG9nZXRoZXIsIGlmIGEgcGF0aCB0byBhIHByaW1hcnkgQ0UgaXMgZG93 biwgdGhlIFRNTA0KICAgd291bGQgdGFrZSBjYXJlIG9mIGZhaWxpbmcgb3ZlciB0byBhIGJhY2t1 cCBwYXRoLCBpZiBvbmUgaXMNCiAgIGF2YWlsYWJsZS4gIElmIHRoZSBDRSBpcyB0b3RhbGx5IHVu cmVhY2hhYmxlIHRoZW4gdGhlIFBMIHdvdWxkIGJlDQogICBpbmZvcm1lZCBhbmQgaXQgd2lsbCB0 YWtlIHRoZSBhcHByb3ByaWF0ZSBhY3Rpb25zIGRlc2NyaWJlZCBiZWZvcmUuDQoNCg== ------_=_NextPart_001_01C4B716.EE6FB23F Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol ------_=_NextPart_001_01C4B716.EE6FB23F-- From forces-protocol-bounces@ietf.org Thu Oct 21 08:39:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18045 for ; Thu, 21 Oct 2004 08:39:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcQq-0000DD-8d for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 08:52:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbLb-0000sM-NW; Thu, 21 Oct 2004 07:43:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUu0-0002XN-Nl for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 00:50:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24974 for ; Thu, 21 Oct 2004 00:50:08 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKV6P-00063O-6c for forces-protocol@ietf.org; Thu, 21 Oct 2004 01:03:09 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CKUto-0007dM-VI for forces-protocol@ietf.org; Thu, 21 Oct 2004 00:50:05 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Thu, 21 Oct 2004 13:09:25 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Thu, 21 Oct 2004 12:46:00 +0800 Message-ID: <06c101c4b729$290c4a70$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408><002d01c4b50b$1ecc9c10$020aa8c0@wwm1><1098102734.1042.134.camel@jzny.localdomain><013101c4b51d$a50761e0$020aa8c0@wwm1><1098134060.1077.446.camel@jzny.localdomain><5.1.0.14.0.20041019093826.0232d418@mail.megisto.com><5.1.0.14.0.20041020070534.0240c390@mail.megisto.com> <1098277687.2072.9.camel@jzny.localdomain> Date: Thu, 21 Oct 2004 12:48:07 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, zsolt@nc.rr.com, "Joel M. Halpern" , "Steven Blake \(petri-meat\)" , hadi@znyx.com, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" Subject: [Forces-protocol] Instance Select X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi Jamal, Hormuzd, etc, To summarize the discussions on multiple instances, I try to propose following scheme for instance selection, which follows Robert's idea and Jamal's format, as: PL level PDU : = MAINHDR+ LFBselect := LFBCLASSID InsSelect + InsSelect := InstanceID + RangeMark := '0xFFFFFFFF'; the value is the same as Broadcast Instance address, no worry of ambiguity here. The InsSelect is a TLV, whose structure is shown as: main hdr (eg type = config) | | +-- T = LFBselect | | | +- LFBCLASSID = target LFB class | | | | | +- T = InsSelect | | | | | V = InstanceID + | | | +- T = operation { ADD, DEL, GET, etc} ... Best Regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 08:44:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19037 for ; Thu, 21 Oct 2004 08:44:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcVz-0000UX-M2 for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 08:58:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbLr-0001Co-53; Thu, 21 Oct 2004 07:43:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKVHv-0003hf-TB for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 01:15:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26127 for ; Thu, 21 Oct 2004 01:14:53 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKVUO-0006PE-5G for forces-protocol@ietf.org; Thu, 21 Oct 2004 01:27:53 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9L4ojep023945; Thu, 21 Oct 2004 06:50:46 +0200 In-Reply-To: <1098228213.1044.56.camel@jzny.localdomain> References: <1098198457.1032.1.camel@jzny.localdomain> <1098228213.1044.56.camel@jzny.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2014EB24-2320-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Re: protocol draft editing? - resend Date: Thu, 21 Oct 2004 01:14:46 -0400 To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Jamal Hadi Salim X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit i sent this out yesterday but it appears you all have not seen it yet. a. hi, you will find a zip, a tar and a tgz in http://psg.com/~avri/forces/draft/ Please let this list know when you are working on a file. And for simplicity sake it is easier if it is one person per file at a time. cheers a. On 19 okt 2004, at 19.23, Jamal Hadi Salim wrote: > > On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote: >> Now that we seem to have made progress on the basics.. >> Avri, >> Could you post a URL to the xml docs that we could start editing? >> We could start with the TODO action items as posted by Hormuzd. >> >> cheers, >> jamal > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 08:45:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19135 for ; Thu, 21 Oct 2004 08:45:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcWd-0000Vr-F3 for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 08:58:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbM1-0001P4-QN; Thu, 21 Oct 2004 07:43:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKVqQ-0004Qu-EC for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 01:50:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28000 for ; Thu, 21 Oct 2004 01:50:26 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKW2o-0006v5-TF for forces-protocol@ietf.org; Thu, 21 Oct 2004 02:03:27 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9L5oXmW002404; Thu, 21 Oct 2004 05:50:33 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9L5rCYf009553; Thu, 21 Oct 2004 05:53:26 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102022494821845 ; Wed, 20 Oct 2004 22:49:48 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 22:49:48 -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 Subject: RE: [Forces-protocol] Re: protocol draft editing? - resend Date: Wed, 20 Oct 2004 22:49:20 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E025791F7@orsmsx408> Thread-Topic: [Forces-protocol] Re: protocol draft editing? - resend Thread-Index: AcS3LOwILnFjNo6JQBCi7enxjGXTRQABJEHQ From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 21 Oct 2004 05:49:48.0365 (UTC) FILETIME=[C66ED7D0:01C4B731] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Weiming Wang , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Avri, I did see your post...the mailing list is giving us problems again so I suggest we copy everyone on all emails going forward (atleast till be submit this draft) regards Hormuzd p.s. did you guys get my emails today ?? -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 Sent: Wednesday, October 20, 2004 10:15 PM To: forces-protocol@ietf.org Cc: Jamal Hadi Salim; ram.gopal@nokia.com; Khosravi, Hormuzd M; Ligang Dong; Robert Haas; Weiming Wang Subject: Re: [Forces-protocol] Re: protocol draft editing? - resend i sent this out yesterday but it appears you all have not seen it yet. a. hi, you will find a zip, a tar and a tgz in=20 http://psg.com/~avri/forces/draft/ Please let this list know when you are working on a file. And for simplicity sake it is easier if it is one person per file at a=20 time. cheers a. On 19 okt 2004, at 19.23, Jamal Hadi Salim wrote: > > On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote: >> Now that we seem to have made progress on the basics.. >> Avri, >> Could you post a URL to the xml docs that we could start editing? >> We could start with the TODO action items as posted by Hormuzd. >> >> cheers, >> jamal > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 09:29:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27718 for ; Thu, 21 Oct 2004 09:29:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdD1-0002ei-H8 for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 09:42:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKckp-0006V9-9H; Thu, 21 Oct 2004 09:13:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcBD-0005hM-Ek for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 08:36:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17093 for ; Thu, 21 Oct 2004 08:36:29 -0400 (EDT) Received: from [64.254.114.117] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcNY-0008JH-PK for forces-protocol@ietf.org; Thu, 21 Oct 2004 08:49:33 -0400 Received: from JLaptop.megisto.com ([192.168.20.234]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Oct 2004 08:35:36 -0400 Message-Id: <5.1.0.14.0.20041021083344.031453b8@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Oct 2004 08:35:22 -0400 To: "Wang,Weiming" , From: "Joel M. Halpern" In-Reply-To: <06c101c4b729$290c4a70$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <5.1.0.14.0.20041020070534.0240c390@mail.megisto.com> <1098277687.2072.9.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Oct 2004 12:35:37.0052 (UTC) FILETIME=[7761A1C0:01C4B76A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, zsolt@nc.rr.com, "Steven Blake \(petri-meat\)" , hadi@znyx.com, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" Subject: [Forces-protocol] Re: Instance Select X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 While I am concerned about feature creep in adding this multi-targetting, I will stop objecting to it at this point. If we want to add such, there is no need to use a TLV to represent it. Simply define the instance ID encoding so we can tell ranges from individual instances. Using a TLV for information whose presence and position is mandatory does not add much, and can in fact cause problems. Yours, Joel At 12:48 PM 10/21/2004 +0800, Wang,Weiming wrote: >Hi Jamal, Hormuzd, etc, > >To summarize the discussions on multiple instances, I try to propose following >scheme for instance selection, which follows Robert's idea and Jamal's format, >as: > >PL level PDU : = MAINHDR+ >LFBselect := LFBCLASSID InsSelect + >InsSelect := InstanceID + >RangeMark := '0xFFFFFFFF'; the value is the same as Broadcast Instance >address, >no worry of ambiguity here. > >The InsSelect is a TLV, whose structure is shown as: > >main hdr (eg type = config) > | > | > +-- T = LFBselect > | | > | +- LFBCLASSID = target LFB class > | | > | | > | +- T = InsSelect > | | | > | | V = InstanceID + > | | > | +- T = operation { ADD, DEL, GET, etc} > ... > >Best Regards, >Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 09:34:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28193 for ; Thu, 21 Oct 2004 09:34:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdHv-0002nH-Gm for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 09:47:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcpL-0000Xk-Bw; Thu, 21 Oct 2004 09:17:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcEK-0007bc-TN for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 08:39:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18088 for ; Thu, 21 Oct 2004 08:39:43 -0400 (EDT) From: ram.gopal@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcQv-0000DY-TW for forces-protocol@ietf.org; Thu, 21 Oct 2004 08:52:47 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LCdVo28470; Thu, 21 Oct 2004 15:39:31 +0300 (EET DST) X-Scanned: Thu, 21 Oct 2004 15:36:36 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9LCaak9012500; Thu, 21 Oct 2004 15:36:36 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00W6cVoW; Thu, 21 Oct 2004 15:35:51 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9LCJTS10011; Thu, 21 Oct 2004 15:19:29 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 21 Oct 2004 07:18:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Forces-protocol] RE: sync with BNF as discussed with model folks Date: Thu, 21 Oct 2004 08:18:26 -0400 Message-ID: Thread-Topic: [Forces-protocol] RE: sync with BNF as discussed with model folks thread-index: AcS2eoqQC8S+d+rgSZelopFRt78z7QAYQAHwACMPgsA= To: , , X-OriginalArrivalTime: 21 Oct 2004 12:18:29.0073 (UTC) FILETIME=[12A87C10:01C4B768] X-Spam-Score: 0.9 (/) X-Scan-Signature: d1330b60dd48fa5cb1958a0aa669d18b Cc: forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0981581640==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 86914b0033efd24523ee4a427c36d849 This is a multi-part message in MIME format. --===============0981581640== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B768.115B803B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B768.115B803B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Jamal, =20 I agree to Robert statement, I though we had an agreement on that. As = far as ForCES protocol goes the FE and CE are ForCES endpoints, if we = limit our HB interactio to these two endpoints that should be fine. LFB = interaction with FE is internal to FE and it may be propriety also.=20 Robert also pointed out that query can be an alternative approach to do = for each LFB. =20 Regards Ramg -----Original Message----- From: forces-protocol-bounces@ietf.org = [mailto:forces-protocol-bounces@ietf.org]On Behalf Of ext Khosravi, = Hormuzd M Sent: Wednesday, October 20, 2004 3:36 PM To: Robert Haas; hadi@znyx.com Cc: forces-protocol@ietf.org Subject: RE: [Forces-protocol] RE: sync with BNF as discussed with model = folks Jamal, =20 I am not sure if you recall, but we had a ton of discussion on HBs = during the last protocol draft before we decided to support them as = minimal msgs (only header) with least possible overhead. Let me know if = you would like me to forward you some of the emails (I will do so = privately if needed), but I hope this issue doesn't take up a lot of our = bandwidth again. =20 regards Hormuzd _____ =20 From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Wednesday, October 20, 2004 12:55 AM To: hadi@znyx.com Cc: Khosravi, Hormuzd M; forces-protocol@ietf.org Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model = folks Jamal, I don't see the point of sending a heartbeat to any LFB other than the = FE Protocol LFB. Here is why: The PL-level heartbeat is really about saying: the sender (FE or CE) of = this hearbeat is alive. FEs will typically be sending this to their CE = (after the CE has configured in the FE Protocol LFB at what frequency it = wants to receive heartbeats). Note that in the current draft we have = explicitely asked to ignore any ACK flag that would be set in the = hearbeat message header. If what you want to have is a ECHO-REQUEST/ECHO-REPLY to a particular = LFB (to check its status, etc), what should be used instead is a Query = msg with GET(status of the particular LFB instance). Would this answer = your needs ? -Robert Jamal Hadi Salim wrote: Robert, Could someone not send a heartbeat to a specific LFB? In which case a heartbe to the FE object equates a heartbeat to the FE. cheers, jamal On Tue, 2004-10-19 at 16:07, Robert Haas wrote: =20 I hope my note makes it before Jamal's noon ... Finally I got a 3 hours slot on a train ride (with phone off and no email access) to read the threads ... In summary: - I think it is good to keep the query separate from config. Reasons given by Steve/Zsolt sound very valid to me. - I am glad to see the "consolidation" into FE Protocol LFB operations of FE attributes config, FE events, and association maintenance messages. - The heartbeat message is currently not "targeted" at the FE protocol LFB. It is an exception to the rule. The reasoning was to keep such messages as short and simple as possible. Basically, you have the choice between a heartbeat to look like this: main hdr (eg type =3D heartbeat) | | +--- T =3D LFBselect | +-- LFBCLASSID =3D FE Protocol LFB Class (=3D0x01) | | +-- LFBInstance =3D FE Protocol LFB Instance(=3D0x01) or like this: main hdr (eg type =3D heartbeat) The difference is only 6-8 bytes (I don't remember what was the final consensus for the T in the TLV). But as the values in the LFBSelect TLV must ALWAYS be 0x01 and 0x01 (we have statically defined the class and instance ID of the FE protocol LFB), it is a waste to transmit them. And if you do, then someone might use wrong values and then you have to decide how to deal with such cases. Regards, -Robert Jamal Hadi Salim wrote:=20 =20 On Fri, 2004-10-15 at 01:33, Khosravi, Hormuzd M wrote: =20 =20 Is there a reason you want to keep that type=3Dquery? [HK] The responses will be more involved for query,=20 also the request might be more involved.=20 =20 =20 This is true. But i dont know how you escape it with any scheme. If you ask to get, you must specify a path whether you use query or=20 config. I would think the response will also have a path and the requested data for that path. =20 =20 The other reason is that=20 I have never seen query bundled with SET/DEL in practice... =20 =20 I dont either; dont wanna rule it - but the more i think about it the more i am concluding its just about sending bundled commands. I think you can not possibly make it any simpler by introducing type=3Dquery. =20 =20 Is this a requirement from Joel or the Model team ? I didn't get that impression, but I might have missed it. =20 =20 I cant remember where it came or where the discussion took place. However, it does make logical sense given now that "everything is an LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to the same way: FE->LFBclass->LFBinstance->path Other than the operator, the operand to a GET is _exactly_ the same as a DEL. ADD has one extra operand. So its not really an issue of requirements; but one of a natural fit (as in the case of SNMP for example) If you can show that you can get an object easier with type=3Dquery i think that would help. Otherwise we would have an additional unneeded message. =20 =20 6.3 -> looks good...we might still need the Flags, also the Event Type is needed since Event Subscribe, UnSubscribe are currently part of =20 =20 this =20 =20 message. =20 =20 Probably makes sense to keep event subscription under config. Sorry I missed that in my quick scan and thought it belonged to type=3Devent = in 6.4. Do we then need operation =3D Event_un/subscribe [HK] Yes I suspect that events will end up being defined in the LFB XML definition and therefore will have a path to them (eg link event in port LFB being path 1.2.3 etc). In which case, the value of the Event_un/subscribe will be to the event. Thoughts? [HK] We could simplify this for generic events, but what you're suggesting seems reasonable. =20 =20 I think its safer to have the XML define what those events are. I sent a query to Joel who will forward it to the model team. He seems to be in agreement. Note this will be equivalent to SNMP traps (which is defined in the mib together with other attributes). As far as i can see, the event is another attribute. So it would look like: Operation =3D subscribe; operand =3D eventpath In our case we should go ahead and choose events that are necessary for the protocol to function and put them in eitehr the FE object or FE protocol LFB. The model team can them adapt from them =20 =20 =20 6.6 -> Fine...I am assuming the States will be exchanged in Event msgs =20 =20 ? Since everything is an LFB, then its per LFB event - in this case i would guess the states will belong to the FE Object LFB?=20 [HK] Yes they would, I have no objection to FE Object or everything being a LFB. The FE States would be part of the FE object sent in Event msgs. =20 =20 Sounds reasonable. =20 =20 6.7 -> remains the same (I assume) =20 =20 I missed that one, sorry. Again my take is this is gone. I would think this would per FE heartebats belong to the FE Protocol LFB. [HK] No, this doesn't need to go, its just a header anyways, it doesn't have any TLVs...its a very light weight msg, remember? I think you are confusing this with the FE Protocol Object, that doesn't have any effect on this msg. =20 =20 But who is the target for this message now? Remember, there MUST be an LFB as the end target. =20 =20 I think that the two FE LFBs deserve speacial attention now. We need to describe what they are expected to do in more detail. We also need to sync on them with the model people. [HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead on defining this =20 =20 We may all have to be involved in these two. I think they are very important that we all need to be involved. BTW, Heres a suggestions: If we dont hear from anybody by Tuesday(I know Weiming mentioned something about being back Monday), lets start assuming noone will and move towards updating the draft to beat the deadline. I dont think people will mind if they are busy. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol =20 =20 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 = http://www.zurich.ibm.com/~rha =20 =20 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 = http://www.zurich.ibm.com/~rha ------_=_NextPart_001_01C4B768.115B803B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello=20 Jamal,
 
I=20 agree to Robert statement, I though we had an agreement on that. As far = as=20 ForCES protocol goes the FE and CE are ForCES endpoints, if we limit our = HB=20 interactio to these two endpoints that should  be fine. LFB = interaction=20 with FE is internal to FE and it may be propriety also.=20

Robert also pointed out that query can be an alternative = approach to do=20 for each LFB.
 
Regards
Ramg
-----Original Message-----
From:=20 forces-protocol-bounces@ietf.org = [mailto:forces-protocol-bounces@ietf.org]On=20 Behalf Of ext Khosravi, Hormuzd M
Sent: Wednesday, October = 20,=20 2004 3:36 PM
To: Robert Haas; hadi@znyx.com
Cc:=20 forces-protocol@ietf.org
Subject: RE: [Forces-protocol] RE: = sync with=20 BNF as discussed with model folks

Jamal,
 
I am not sure if you recall, but we had a ton = of discussion=20 on HBs during the last protocol draft before we decided to support them = as=20 minimal msgs (only header) with least possible overhead. Let me know if = you=20 would like me to forward you some of the emails (I will do so privately = if=20 needed), but I hope this issue doesn't take up a lot of our bandwidth=20 again.
 
regards
Hormuzd

From: Robert Haas = [mailto:rha@zurich.ibm.com]=20
Sent: Wednesday, October 20, 2004 12:55 AM
To:=20 hadi@znyx.com
Cc: Khosravi, Hormuzd M;=20 forces-protocol@ietf.org
Subject: Re: [Forces-protocol] RE: = sync with=20 BNF as discussed with model folks

Jamal,
I don't see the point of sending a heartbeat to any = LFB=20 other than the FE Protocol LFB. Here is why:

The PL-level = heartbeat is=20 really about saying: the sender (FE or CE) of this hearbeat is alive. = FEs will=20 typically be sending this to their CE (after the CE has configured in = the FE=20 Protocol LFB at what frequency it wants to receive heartbeats). Note = that in the=20 current draft we have explicitely asked to ignore any ACK flag that = would be set=20 in the hearbeat message header.

If what you want to have is a=20 ECHO-REQUEST/ECHO-REPLY to a particular LFB (to check its status, etc), = what=20 should be used instead is a Query msg with GET(status of the particular = LFB=20 instance). Would this answer your needs = ?

-Robert


Jamal Hadi=20 Salim wrote:
Robert,
Could someone not send a heartbeat to a specific LFB?
In which case a heartbe to the FE object equates a heartbeat to the FE.

cheers,
jamal

On Tue, 2004-10-19 at 16:07, Robert Haas wrote:
  
I hope my note makes it =
before Jamal's noon ... Finally I got a 3
hours slot on a train ride (with phone off and no email access) to
read the threads ...

In summary:

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

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

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

main hdr (eg type =3D heartbeat)
      |
      |
      +--- T =3D LFBselect
               |
               +-- LFBCLASSID =3D FE Protocol LFB Class (=3D0x01)
               |
               |
               +-- LFBInstance =3D FE Protocol LFB Instance(=3D0x01)
or like this:

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

Regards,
-Robert

Jamal Hadi Salim wrote:=20
    
On Fri, 2004-10-15 at =
01:33, Khosravi, Hormuzd M wrote:

 =20
      
Is there a reason you =
want to keep that type=3Dquery?
[HK] The responses will be more involved for query,=20
also the request <path> might be more involved.=20
   =20
        
This is true. But i dont know =
how you escape it with any scheme.
If you ask to get, you must specify a path whether you use query or=20
config. I would think the response will also have a path and the
requested data for that path.

 =20
      
The other reason is that=20
I have never seen query bundled with SET/DEL in practice...
   =20
        
I dont either; dont wanna rule =
it - but the more i think about it the
more i am concluding its just about sending bundled commands. I think
you can not possibly make it any simpler by introducing type=3Dquery.

 =20
      
Is this a requirement =
from
Joel or the Model team ? I didn't get that impression, but I might have
missed it.

   =20
        
I cant remember where it came =
or where the discussion took place.
However, it does make logical sense given now that "everything is an
LFB" and we have paths to get to objects; i.e an ADD, DEL or GET goes to
the same way: FE->LFBclass->LFBinstance->path
Other than the operator, the operand to a GET is _exactly_ the same
as a DEL. ADD has one extra operand.
So its not really an issue of requirements; but one of a natural fit (as
in the case of SNMP for example)
If you can show that you can get an object easier with type=3Dquery i
think that would help. Otherwise we would have an additional unneeded
message.

 =20
      
6.3 -> looks =
good...we might still need the Flags, also the Event Type
is needed since Event Subscribe, UnSubscribe are currently part of
     =20
          
this
   =20
        
message.
     =20
          
Probably makes sense to keep =
event subscription under config. Sorry
I missed that in my quick scan and thought it belonged to type=3Devent =
in
6.4.
Do we then need operation =3D Event_un/subscribe [HK] Yes
I suspect that events will end up being defined in the LFB XML
definition and therefore will have a path to them (eg link event in port
LFB being path 1.2.3 etc).
In which case, the value of the Event_un/subscribe will be to the
event.
Thoughts? [HK] We could simplify this for generic events, but what
you're suggesting seems reasonable.
   =20
        
I think its safer to have the =
XML define what those events are. I sent a
query to Joel who will forward it to the model team. He seems to be in
agreement. Note this will be equivalent to SNMP traps (which is defined
in the mib together with other attributes).
As far as i can see, the event is another attribute. So it would look
like:
Operation =3D subscribe; operand =3D eventpath
In our case we should go ahead and choose events that are necessary for
the protocol to function and put them in eitehr the FE object or FE
protocol LFB. The model team can them adapt from them
 =20
 =20
      
6.6 -> Fine...I am =
assuming the States will be exchanged in Event msgs
     =20
          
?

Since everything is an LFB, then its per LFB event - in this case i
would guess the states will belong to the FE Object LFB?=20

[HK] Yes they would, I have no objection to FE Object or everything
being a LFB. The FE States would be part of the FE object sent in Event
msgs.

   =20
        
Sounds reasonable.

 =20
      
6.7 -> remains the =
same (I assume)
     =20
          
I missed that one, sorry.
Again my take is this is gone. I would think this would per FE
heartebats belong to the FE Protocol LFB.
[HK] No, this doesn't need to go, its just a header anyways, it doesn't
have any TLVs...its a very light weight msg, remember? I think you are
confusing this with the FE Protocol Object, that doesn't have any effect
on this msg.
   =20
        
But who is the target for this =
message now?
Remember, there MUST be an LFB as the end target.

 =20
      
I think that the two FE =
LFBs deserve speacial attention now.
We need to describe what they are expected to do in more detail. We also
need to sync on them with the model people.
[HK] Sure, agree on this..I was hoping Robert/Weiming will take a lead
on defining this

   =20
        
We may all have to be involved =
in these two. I think they are very
important that we all need to be involved.

BTW, Heres a suggestions:

If we dont hear from anybody by Tuesday(I know Weiming mentioned
something about being back Monday), lets start assuming noone will
and move towards updating the draft to beat the deadline.
I dont think people will mind if they are busy.

cheers,
jamal




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


 =20
      
--=20
Robert Haas
IBM Zurich Research Laboratory
S=E4umerstrasse 4
CH-8803 R=FCschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
    



  

--=20
Robert Haas
IBM Zurich Research Laboratory
S=E4umerstrasse 4
CH-8803 R=FCschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
------_=_NextPart_001_01C4B768.115B803B-- --===============0981581640== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0981581640==-- From forces-protocol-bounces@ietf.org Thu Oct 21 10:00:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00439 for ; Thu, 21 Oct 2004 10:00:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdgv-0003PV-8r for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 10:13:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdIg-0001vv-9t; Thu, 21 Oct 2004 09:48:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdDA-0006ej-VX for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 09:42:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29004 for ; Thu, 21 Oct 2004 09:42:34 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdPa-0002zA-OY for forces-protocol@ietf.org; Thu, 21 Oct 2004 09:55:40 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CKdCv-0007EY-7B for forces-protocol@ietf.org; Thu, 21 Oct 2004 09:42:22 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Thu, 21 Oct 2004 22:01:32 +0800 (CST) Received: from wwm1 (unverified [219.82.183.229]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Thu, 21 Oct 2004 21:38:02 +0800 Message-ID: <015901c4b774$56538520$020aa8c0@wwm1> From: "Weiming Wang" To: , "Joel M. Halpern" References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <5.1.0.14.0.20041020070534.0240c390@mail.megisto.com> <1098277687.2072.9.camel@jzny.localdomain> <5.1.0.14.0.20041021083344.031453b8@mail.megisto.com> Date: Thu, 21 Oct 2004 21:46:03 +0800 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, zsolt@nc.rr.com, "Steven Blake \(petri-meat\)" , hadi@znyx.com, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" Subject: [Forces-protocol] Re: Instance Select X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Hi Joel, ----- Original Message ----- From: "Joel M. Halpern" Subject: Re: Instance Select > While I am concerned about feature creep in adding this multi-targetting, I > will stop objecting to it at this point. Could you show why and what's the benifits to defer it. What I see the issue is it is more a basic one than a value-added one, for it is quite like a printer which can only print one page at a time if without multiple selecting. > If we want to add such, there is no need to use a TLV to represent > it. Simply define the instance ID encoding so we can tell ranges from > individual instances. Does it mean the coding as: LFBCLASSID InstanceID + + ? If is, I'm afraid there is a size problem for it, for the InstanceID number changes and we can not tell an InstanceID with the OPER TLV type field. If it means using some tag in InstanceID field to indicate the InstanceID and the Range mark, then I think it will still limit the OPER TLV type definition. Could you show more on this? >Using a TLV for information whose presence The presense is definite, for we at least need one Instance ID. >and > position is mandatory does not add much, and can in fact cause problems. Joel, I know you are quite experienced and I'm really very much interested in what you think of the problems here. From my limited experience, I think TLV followed by TLV approach is a very common PDU scheme for protocol design, and will lead to no problems that I can think of. Actually, in our current scheme, I think we have already used LFBselectTLV followed by many other LFBselectTLV format. And I also see we will use Path-Data TLV quene inevitably. Maybe I'v missed something. Thank you. Weiming > > Yours, > Joel > > At 12:48 PM 10/21/2004 +0800, Wang,Weiming wrote: > >Hi Jamal, Hormuzd, etc, > > > >To summarize the discussions on multiple instances, I try to propose following > >scheme for instance selection, which follows Robert's idea and Jamal's format, > >as: > > > >PL level PDU : = MAINHDR+ > >LFBselect := LFBCLASSID InsSelect + > >InsSelect := InstanceID + > >RangeMark := '0xFFFFFFFF'; the value is the same as Broadcast Instance > >address, > >no worry of ambiguity here. > > > >The InsSelect is a TLV, whose structure is shown as: > > > >main hdr (eg type = config) > > | > > | > > +-- T = LFBselect > > | | > > | +- LFBCLASSID = target LFB class > > | | > > | | > > | +- T = InsSelect > > | | | > > | | V = InstanceID + > > | | > > | +- T = operation { ADD, DEL, GET, etc} > > ... > > > >Best Regards, > >Weiming > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 10:21:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04322 for ; Thu, 21 Oct 2004 10:21:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKe18-0004AT-CD for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 10:34:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdi6-0004RI-RQ; Thu, 21 Oct 2004 10:14:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdXg-0000te-RG for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 10:03:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00863 for ; Thu, 21 Oct 2004 10:03:46 -0400 (EDT) Received: from [64.254.114.117] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdk8-0003TZ-0l for forces-protocol@ietf.org; Thu, 21 Oct 2004 10:16:51 -0400 Received: from JLaptop.megisto.com ([192.168.20.234]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Oct 2004 10:02:42 -0400 Message-Id: <5.1.0.14.0.20041021100215.0244e7c8@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Oct 2004 10:02:26 -0400 To: "Weiming Wang" , From: "Joel M. Halpern" In-Reply-To: <015901c4b774$56538520$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <5.1.0.14.0.20041020070534.0240c390@mail.megisto.com> <1098277687.2072.9.camel@jzny.localdomain> <5.1.0.14.0.20041021083344.031453b8@mail.megisto.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Oct 2004 14:02:42.0266 (UTC) FILETIME=[A1DA03A0:01C4B776] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, zsolt@nc.rr.com, "Steven Blake \(petri-meat\)" , hadi@znyx.com, Alan DeKok , Ellen M Deleganes , "Yang, Lily L" Subject: [Forces-protocol] Re: Instance Select X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb I think I was wrong in this case. There are really two different kinds of instance targets, and you are right that a TLV is the best way to encode that. Sorry. Joel At 09:46 PM 10/21/2004 +0800, Weiming Wang wrote: > > If we want to add such, there is no need to use a TLV to represent > > it. Simply define the instance ID encoding so we can tell ranges from > > individual instances. >Does it mean the coding as: > >LFBCLASSID InstanceID + + ? > >If is, I'm afraid there is a size problem for it, for the InstanceID number >changes and we can not tell an InstanceID with the OPER TLV type field. >If it means using some tag in InstanceID field to indicate the InstanceID and >the Range mark, then I think it will still limit the OPER TLV type definition. >Could you show more on this? > > >Using a TLV for information whose presence >The presense is definite, for we at least need one Instance ID. > > >and > > position is mandatory does not add much, and can in fact cause problems. >Joel, I know you are quite experienced and I'm really very much interested in >what you think of the problems here. From my limited experience, I think TLV >followed by TLV approach is a very common PDU scheme for protocol design, and >will lead to no problems that I can think of. Actually, in our current >scheme, I >think we have already used LFBselectTLV followed by many other LFBselectTLV >format. And I also see we will use Path-Data TLV quene inevitably. Maybe I'v >missed something. > >Thank you. >Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 10:27:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05514 for ; Thu, 21 Oct 2004 10:27:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKe7k-0004NF-Q3 for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 10:41:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdmt-0006mF-3L; Thu, 21 Oct 2004 10:19:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdbE-0003AF-E9 for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 10:07:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01620 for ; Thu, 21 Oct 2004 10:07:26 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdnq-0003ff-FV for forces-protocol@ietf.org; Thu, 21 Oct 2004 10:20:31 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i9LE6UD7357980; Thu, 21 Oct 2004 10:06:30 -0400 Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9LE7IS8083302; Thu, 21 Oct 2004 10:07:20 -0400 Received: from [9.145.135.33] (sig-9-145-135-33.de.ibm.com [9.145.135.33]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA42100; Thu, 21 Oct 2004 16:05:30 +0200 Message-ID: <4177C1E2.4080506@zurich.ibm.com> Date: Thu, 21 Oct 2004 16:04:18 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" Subject: Re: [Forces-protocol] Re: protocol draft editing? References: <468F3FDA28AA87429AD807992E22D07E02F5D468@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02F5D468@orsmsx408> X-Spam-Score: 0.5 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Weiming Wang X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1194296153==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af This is a multi-part message in MIME format. --===============1194296153== Content-Type: multipart/alternative; boundary="------------040304020102020203010200" This is a multi-part message in MIME format. --------------040304020102020203010200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e1.ny.us.ibm.com id i9LE6UD7357980 Content-Transfer-Encoding: quoted-printable Hormuzd, Section 6 is heavily impacted by the shift to "everything is an LFB".=20 Many sections and figures require complete re-editing. To ensure=20 consistency, we need one person to do one editing pass on the entire=20 section first. But your list says "everybody". What if I do this first pass before tomorrow ? Or has anyone started=20 already ? It also means that our description of the FE Protocol LFB must be=20 enhanced, possibly including the multicast table that Zsolt started=20 specifying. Regards, -Robert Khosravi, Hormuzd M wrote: >Here is the distribution list... > >Abstract - Avri >1. Introduction - Avri >2. Definitions - Weiming >3. Protocol Overview - Jamal >4. TML Requirements - Jamal >5. Common Header - Weiming, Ligang (Jamal/Robert) >6. Protocol Messages - Hormuzd, Weiming (I expect everyone to be >involved with this one) >7. Protocol Scenarios - Hormuzd, Ram >8. High Availability - Hormuzd >9. Security Considerations - Ram >10. References - Avri >11. Acknowledgments - All >Appendix >A. Implementation Notes - All? > >I will directly modify the text for my particular section and send it >out to the team/Avri on a per section or per-subsection basis. That was >we can all work in parallel. > >regards >Hormuzd=20 > >-----Original Message----- >From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >Sent: Wednesday, October 20, 2004 5:35 AM >To: forces-protocol@ietf.org >Cc: avri@psg.com; Khosravi, Hormuzd M; ram.gopal@nokia.com; Ligang Dong; >Weiming Wang; Robert Haas >Subject: Re: [Forces-protocol] Re: protocol draft editing? > >Avri must be on travel or tied up somewhere around the globe. >The latest i could find is: >http://psg.com/~avri/forces/draft/Archive-Forces-Protocol-02.zip > >Does anyone know if theres something newer or should we start here? >Hormuzd can you post that todo distribution? > >cheers, >jamal > >On Tue, 2004-10-19 at 19:23, Jamal Hadi Salim wrote: > =20 > >>On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote: >> =20 >> >>>Now that we seem to have made progress on the basics.. >>>Avri, >>>Could you post a URL to the xml docs that we could start editing? >>>We could start with the TODO action items as posted by Hormuzd. >>> >>>cheers, >>>jamal >>> =20 >>> >>_______________________________________________ >>Forces-protocol mailing list >>Forces-protocol@ietf.org >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> =20 >> > > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------040304020102020203010200 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hormuzd,
Section 6 is heavily impacted by the shift to "everything is an LFB". Many sections and figures require complete re-editing. To ensure consistency, we need one person to do one editing pass on the entire section first. But your list says "everybody".

What if I do this first pass before tomorrow ? Or has anyone started already ?

It also means that our description of the FE Protocol LFB must be enhanced, possibly including the multicast table that Zsolt started specifying.

Regards,
-Robert

Khosravi, Hormuzd M wrote:
Here is the distribution list...

Abstract - Avri
1. Introduction - Avri
2. Definitions - Weiming
3. Protocol Overview - Jamal
4. TML Requirements - Jamal
5. Common Header - Weiming, Ligang (Jamal/Robert)
6. Protocol Messages - Hormuzd, Weiming (I expect everyone to be
involved with this one)
7. Protocol Scenarios - Hormuzd, Ram
8. High Availability - Hormuzd
9. Security Considerations - Ram
10. References - Avri
11. Acknowledgments - All
Appendix
A. Implementation Notes - All?

I will directly modify the text for my particular section and send it
out to the team/Avri on a per section or per-subsection basis. That was
we can all work in parallel.

regards
Hormuzd 

-----Original Message-----
From: Jamal Hadi Salim [mailto:hadi@znyx.com] 
Sent: Wednesday, October 20, 2004 5:35 AM
To: forces-protocol@ietf.org
Cc: avri@psg.com; Khosravi, Hormuzd M; ram.gopal@nokia.com; Ligang Dong;
Weiming Wang; Robert Haas
Subject: Re: [Forces-protocol] Re: protocol draft editing?

Avri must be on travel or tied up somewhere around the globe.
The latest i could find is:
http://psg.com/~avri/forces/draft/Archive-Forces-Protocol-02.zip

Does anyone know if theres something newer or should we start here?
Hormuzd can you post that todo distribution?

cheers,
jamal

On Tue, 2004-10-19 at 19:23, Jamal Hadi Salim wrote:
  
On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote:
    
Now that we seem to have made progress on the basics..
Avri,
Could you post a URL to the xml docs that we could start editing?
We could start with the TODO action items as posted by Hormuzd.

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



  

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------040304020102020203010200-- --===============1194296153== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1194296153==-- From forces-protocol-bounces@ietf.org Thu Oct 21 10:40:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07691 for ; Thu, 21 Oct 2004 10:40:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKeJv-0004l9-Um for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 10:53:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdv5-0004ZB-8P; Thu, 21 Oct 2004 10:27:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKdmn-0006gf-60 for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 10:19:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04027 for ; Thu, 21 Oct 2004 10:19:22 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKdzF-00045q-7A for forces-protocol@ietf.org; Thu, 21 Oct 2004 10:32:28 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Thu, 21 Oct 2004 22:38:15 +0800 (CST) Received: from dlg (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with SMTP id ; Thu, 21 Oct 2004 22:14:45 +0800 Message-ID: <000d01c4b778$a015d380$8401a8c0@dlg> From: "Ligang Dong" To: "Robert Haas" , "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E02F5D468@orsmsx408> <4177C1E2.4080506@zurich.ibm.com> Subject: Re: [Forces-protocol] Re: protocol draft editing? Date: Thu, 21 Oct 2004 22:16:58 +0800 MIME-Version: 1.0 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 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: ram.gopal@nokia.com, avri@psg.com, hadi@znyx.com, Weiming Wang , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0157152716==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 3.6 (+++) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e This is a multi-part message in MIME format. --===============0157152716== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C4B7BB.AE1C8AD0" This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C4B7BB.AE1C8AD0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 aGksDQpZZXMuIEkgdGhpbmsgT05FIHBlcnNvbiB3cml0ZXMgb25lIHNlY3Rpb24gZmlyc3QsIHNv IHRoYXQgdGhlIHdyaXRpbmcgY29udGVudCBhbmQgc3R5bGUgYXJlIGNvbnNpc3RlbnQgdGhyb3Vn aG91dCB0aGUgc2VjdGlvbi4gT3RoZXJzIGdpdmUgdGhlIGNvbW1lbnRzIGFuZCBoZWxwIHRoZSBt YWluIGVkaXRvciBpbXByb3ZlIGl0LiANCk5vdyBsZXQncyB2b2x1bnRlZXIgdG8gYmVjb21lIHRo ZSBtYWluIGVkaXRvciBvZiBlYWNoIHNlY3Rpb24uDQpCZXN0IHJlZ2FyZHMNCkxpZ2FuZw0KICAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBSb2JlcnQgSGFhcyANCiAgVG86 IEtob3NyYXZpLCBIb3JtdXpkIE0gDQogIENjOiBoYWRpQHpueXguY29tIDsgZm9yY2VzLXByb3Rv Y29sQGlldGYub3JnIDsgYXZyaUBwc2cuY29tIDsgcmFtLmdvcGFsQG5va2lhLmNvbSA7IExpZ2Fu ZyBEb25nIDsgV2VpbWluZyBXYW5nIA0KICBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyMSwgMjAw NCAxMDowNCBQTQ0KICBTdWJqZWN0OiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gUmU6IHByb3RvY29s IGRyYWZ0IGVkaXRpbmc/DQoNCg0KICBIb3JtdXpkLA0KICBTZWN0aW9uIDYgaXMgaGVhdmlseSBp bXBhY3RlZCBieSB0aGUgc2hpZnQgdG8gImV2ZXJ5dGhpbmcgaXMgYW4gTEZCIi4gTWFueSBzZWN0 aW9ucyBhbmQgZmlndXJlcyByZXF1aXJlIGNvbXBsZXRlIHJlLWVkaXRpbmcuIFRvIGVuc3VyZSBj b25zaXN0ZW5jeSwgd2UgbmVlZCBvbmUgcGVyc29uIHRvIGRvIG9uZSBlZGl0aW5nIHBhc3Mgb24g dGhlIGVudGlyZSBzZWN0aW9uIGZpcnN0LiBCdXQgeW91ciBsaXN0IHNheXMgImV2ZXJ5Ym9keSIu IA0KDQogIFdoYXQgaWYgSSBkbyB0aGlzIGZpcnN0IHBhc3MgYmVmb3JlIHRvbW9ycm93ID8gT3Ig aGFzIGFueW9uZSBzdGFydGVkIGFscmVhZHkgPw0KDQogIEl0IGFsc28gbWVhbnMgdGhhdCBvdXIg ZGVzY3JpcHRpb24gb2YgdGhlIEZFIFByb3RvY29sIExGQiBtdXN0IGJlIGVuaGFuY2VkLCBwb3Nz aWJseSBpbmNsdWRpbmcgdGhlIG11bHRpY2FzdCB0YWJsZSB0aGF0IFpzb2x0IHN0YXJ0ZWQgc3Bl Y2lmeWluZy4NCg0KICBSZWdhcmRzLA0KICAtUm9iZXJ0DQoNCiAgS2hvc3JhdmksIEhvcm11emQg TSB3cm90ZToNCg0KSGVyZSBpcyB0aGUgZGlzdHJpYnV0aW9uIGxpc3QuLi4NCg0KQWJzdHJhY3Qg LSBBdnJpDQoxLiBJbnRyb2R1Y3Rpb24gLSBBdnJpDQoyLiBEZWZpbml0aW9ucyAtIFdlaW1pbmcN CjMuIFByb3RvY29sIE92ZXJ2aWV3IC0gSmFtYWwNCjQuIFRNTCBSZXF1aXJlbWVudHMgLSBKYW1h bA0KNS4gQ29tbW9uIEhlYWRlciAtIFdlaW1pbmcsIExpZ2FuZyAoSmFtYWwvUm9iZXJ0KQ0KNi4g UHJvdG9jb2wgTWVzc2FnZXMgLSBIb3JtdXpkLCBXZWltaW5nIChJIGV4cGVjdCBldmVyeW9uZSB0 byBiZQ0KaW52b2x2ZWQgd2l0aCB0aGlzIG9uZSkNCjcuIFByb3RvY29sIFNjZW5hcmlvcyAtIEhv cm11emQsIFJhbQ0KOC4gSGlnaCBBdmFpbGFiaWxpdHkgLSBIb3JtdXpkDQo5LiBTZWN1cml0eSBD b25zaWRlcmF0aW9ucyAtIFJhbQ0KMTAuIFJlZmVyZW5jZXMgLSBBdnJpDQoxMS4gQWNrbm93bGVk Z21lbnRzIC0gQWxsDQpBcHBlbmRpeA0KQS4gSW1wbGVtZW50YXRpb24gTm90ZXMgLSBBbGw/DQoN Ckkgd2lsbCBkaXJlY3RseSBtb2RpZnkgdGhlIHRleHQgZm9yIG15IHBhcnRpY3VsYXIgc2VjdGlv biBhbmQgc2VuZCBpdA0Kb3V0IHRvIHRoZSB0ZWFtL0F2cmkgb24gYSBwZXIgc2VjdGlvbiBvciBw ZXItc3Vic2VjdGlvbiBiYXNpcy4gVGhhdCB3YXMNCndlIGNhbiBhbGwgd29yayBpbiBwYXJhbGxl bC4NCg0KcmVnYXJkcw0KSG9ybXV6ZCANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IEphbWFsIEhhZGkgU2FsaW0gW21haWx0bzpoYWRpQHpueXguY29tXSANClNlbnQ6IFdlZG5l c2RheSwgT2N0b2JlciAyMCwgMjAwNCA1OjM1IEFNDQpUbzogZm9yY2VzLXByb3RvY29sQGlldGYu b3JnDQpDYzogYXZyaUBwc2cuY29tOyBLaG9zcmF2aSwgSG9ybXV6ZCBNOyByYW0uZ29wYWxAbm9r aWEuY29tOyBMaWdhbmcgRG9uZzsNCldlaW1pbmcgV2FuZzsgUm9iZXJ0IEhhYXMNClN1YmplY3Q6 IFJlOiBbRm9yY2VzLXByb3RvY29sXSBSZTogcHJvdG9jb2wgZHJhZnQgZWRpdGluZz8NCg0KQXZy aSBtdXN0IGJlIG9uIHRyYXZlbCBvciB0aWVkIHVwIHNvbWV3aGVyZSBhcm91bmQgdGhlIGdsb2Jl Lg0KVGhlIGxhdGVzdCBpIGNvdWxkIGZpbmQgaXM6DQpodHRwOi8vcHNnLmNvbS9+YXZyaS9mb3Jj ZXMvZHJhZnQvQXJjaGl2ZS1Gb3JjZXMtUHJvdG9jb2wtMDIuemlwDQoNCkRvZXMgYW55b25lIGtu b3cgaWYgdGhlcmVzIHNvbWV0aGluZyBuZXdlciBvciBzaG91bGQgd2Ugc3RhcnQgaGVyZT8NCkhv cm11emQgY2FuIHlvdSBwb3N0IHRoYXQgdG9kbyBkaXN0cmlidXRpb24/DQoNCmNoZWVycywNCmph bWFsDQoNCk9uIFR1ZSwgMjAwNC0xMC0xOSBhdCAxOToyMywgSmFtYWwgSGFkaSBTYWxpbSB3cm90 ZToNCiAgT24gVHVlLCAyMDA0LTEwLTE5IGF0IDExOjA3LCBKYW1hbCBIYWRpIFNhbGltIHdyb3Rl Og0KICAgIE5vdyB0aGF0IHdlIHNlZW0gdG8gaGF2ZSBtYWRlIHByb2dyZXNzIG9uIHRoZSBiYXNp Y3MuLg0KQXZyaSwNCkNvdWxkIHlvdSBwb3N0IGEgVVJMIHRvIHRoZSB4bWwgZG9jcyB0aGF0IHdl IGNvdWxkIHN0YXJ0IGVkaXRpbmc/DQpXZSBjb3VsZCBzdGFydCB3aXRoIHRoZSBUT0RPIGFjdGlv biBpdGVtcyBhcyBwb3N0ZWQgYnkgSG9ybXV6ZC4NCg0KY2hlZXJzLA0KamFtYWwNCiAgICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGb3JjZXMtcHJv dG9jb2wgbWFpbGluZyBsaXN0DQpGb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcy1wcm90b2NvbA0KICAgIA0KDQoNCiAg DQoNCi0tIA0KUm9iZXJ0IEhhYXMNCklCTSBadXJpY2ggUmVzZWFyY2ggTGFib3JhdG9yeQ0KU+R1 bWVyc3RyYXNzZSA0DQpDSC04ODAzIFL8c2NobGlrb24vU3dpdHplcmxhbmQNCnBob25lICs0MS0x LTcyNC04Njk4ICBmYXggKzQxLTEtNzI0LTg1NzggIGh0dHA6Ly93d3cuenVyaWNoLmlibS5jb20v fnJoYQ== ------=_NextPart_000_000A_01C4B7BB.AE1C8AD0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD10ZXh0L2h0bWw7Y2hhcnNldD1JU08tODg1OS0xPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjgwMC4xMTA2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NU WUxFPg0KPC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+ PEZPTlQgc2l6ZT0yPmhpLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlllcy4gSSB0 aGluayBPTkUgcGVyc29uJm5ic3A7d3JpdGVzIG9uZSBzZWN0aW9uIGZpcnN0LCBzbyB0aGF0IA0K dGhlIHdyaXRpbmcgY29udGVudCBhbmQgc3R5bGUgYXJlIGNvbnNpc3RlbnQgdGhyb3VnaG91dCB0 aGUgc2VjdGlvbi4gDQpPdGhlcnMmbmJzcDtnaXZlIHRoZSBjb21tZW50cyBhbmQgaGVscCB0aGUg bWFpbiBlZGl0b3IgaW1wcm92ZSANCml0LiZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPk5vdyBsZXQncyB2b2x1bnRlZXIgdG8gYmVjb21lIHRoZSBtYWluIGVkaXRvciBvZiBl YWNoIA0Kc2VjdGlvbi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5CZXN0IHJlZ2Fy ZHM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5MaWdhbmc8L0ZPTlQ+PC9ESVY+DQo8 QkxPQ0tRVU9URSBkaXI9bHRyIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1M RUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xp ZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsm IzIwMzA3OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBzdHls ZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7IGZvbnQt Y29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPXJoYUB6dXJpY2guaWJtLmNv bSBocmVmPSJtYWlsdG86cmhhQHp1cmljaC5pYm0uY29tIj5Sb2JlcnQgSGFhczwvQT4gDQogIDwv RElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9C PiA8QSB0aXRsZT1ob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tIA0KICBocmVmPSJtYWlsdG86 aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbSI+S2hvc3JhdmksIEhvcm11emQgTTwvQT4gPC9E SVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5DYzo8L0I+ IDxBIHRpdGxlPWhhZGlAem55eC5jb20gDQogIGhyZWY9Im1haWx0bzpoYWRpQHpueXguY29tIj5o YWRpQHpueXguY29tPC9BPiA7IDxBIA0KICB0aXRsZT1mb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcg DQogIGhyZWY9Im1haWx0bzpmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmciPmZvcmNlcy1wcm90b2Nv bEBpZXRmLm9yZzwvQT4gOyA8QSANCiAgdGl0bGU9YXZyaUBwc2cuY29tIGhyZWY9Im1haWx0bzph dnJpQHBzZy5jb20iPmF2cmlAcHNnLmNvbTwvQT4gOyA8QSANCiAgdGl0bGU9cmFtLmdvcGFsQG5v a2lhLmNvbSANCiAgaHJlZj0ibWFpbHRvOnJhbS5nb3BhbEBub2tpYS5jb20iPnJhbS5nb3BhbEBu b2tpYS5jb208L0E+IDsgPEEgDQogIHRpdGxlPWRvbmdsZ0BtYWlsLmh6aWMuZWR1LmNuIGhyZWY9 Im1haWx0bzpkb25nbGdAbWFpbC5oemljLmVkdS5jbiI+TGlnYW5nIA0KICBEb25nPC9BPiA7IDxB IHRpdGxlPXdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuIA0KICBocmVmPSJtYWlsdG86d213YW5nQG1h aWwuaHppYy5lZHUuY24iPldlaW1pbmcgV2FuZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZP TlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50OjwvQj4gVGh1cnNkYXksIE9jdG9iZXIg MjEsIDIwMDQgMTA6MDQgDQogIFBNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIz NDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUmU6IFtGb3JjZXMtcHJvdG9jb2xdIFJlOiBw cm90b2NvbCANCiAgZHJhZnQgZWRpdGluZz88L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+SG9ybXV6 ZCw8QlI+U2VjdGlvbiA2IGlzIGhlYXZpbHkgaW1wYWN0ZWQgYnkgdGhlIHNoaWZ0IHRvIA0KICAi ZXZlcnl0aGluZyBpcyBhbiBMRkIiLiBNYW55IHNlY3Rpb25zIGFuZCBmaWd1cmVzIHJlcXVpcmUg Y29tcGxldGUgcmUtZWRpdGluZy4gDQogIFRvIGVuc3VyZSBjb25zaXN0ZW5jeSwgd2UgbmVlZCBv bmUgcGVyc29uIHRvIGRvIG9uZSBlZGl0aW5nIHBhc3Mgb24gdGhlIGVudGlyZSANCiAgc2VjdGlv biBmaXJzdC4gQnV0IHlvdXIgbGlzdCBzYXlzICJldmVyeWJvZHkiLiA8QlI+PEJSPldoYXQgaWYg SSBkbyB0aGlzIGZpcnN0IA0KICBwYXNzIGJlZm9yZSB0b21vcnJvdyA/IE9yIGhhcyBhbnlvbmUg c3RhcnRlZCBhbHJlYWR5ID88QlI+PEJSPkl0IGFsc28gbWVhbnMgDQogIHRoYXQgb3VyIGRlc2Ny aXB0aW9uIG9mIHRoZSBGRSBQcm90b2NvbCBMRkIgbXVzdCBiZSBlbmhhbmNlZCwgcG9zc2libHkg DQogIGluY2x1ZGluZyB0aGUgbXVsdGljYXN0IHRhYmxlIHRoYXQgWnNvbHQgc3RhcnRlZCANCiAg c3BlY2lmeWluZy48QlI+PEJSPlJlZ2FyZHMsPEJSPi1Sb2JlcnQ8QlI+PEJSPktob3NyYXZpLCBI b3JtdXpkIE0gd3JvdGU6PEJSPg0KICA8QkxPQ0tRVU9URSBjaXRlPW1pZDQ2OEYzRkRBMjhBQTg3 NDI5QUQ4MDc5OTJFMjJEMDdFMDJGNUQ0NjhAb3JzbXN4NDA4IA0KICB0eXBlPSJjaXRlIj48UFJF IHdyYXA9IiI+SGVyZSBpcyB0aGUgZGlzdHJpYnV0aW9uIGxpc3QuLi4NCg0KQWJzdHJhY3QgLSBB dnJpDQoxLiBJbnRyb2R1Y3Rpb24gLSBBdnJpDQoyLiBEZWZpbml0aW9ucyAtIFdlaW1pbmcNCjMu IFByb3RvY29sIE92ZXJ2aWV3IC0gSmFtYWwNCjQuIFRNTCBSZXF1aXJlbWVudHMgLSBKYW1hbA0K NS4gQ29tbW9uIEhlYWRlciAtIFdlaW1pbmcsIExpZ2FuZyAoSmFtYWwvUm9iZXJ0KQ0KNi4gUHJv dG9jb2wgTWVzc2FnZXMgLSBIb3JtdXpkLCBXZWltaW5nIChJIGV4cGVjdCBldmVyeW9uZSB0byBi ZQ0KaW52b2x2ZWQgd2l0aCB0aGlzIG9uZSkNCjcuIFByb3RvY29sIFNjZW5hcmlvcyAtIEhvcm11 emQsIFJhbQ0KOC4gSGlnaCBBdmFpbGFiaWxpdHkgLSBIb3JtdXpkDQo5LiBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyAtIFJhbQ0KMTAuIFJlZmVyZW5jZXMgLSBBdnJpDQoxMS4gQWNrbm93bGVkZ21l bnRzIC0gQWxsDQpBcHBlbmRpeA0KQS4gSW1wbGVtZW50YXRpb24gTm90ZXMgLSBBbGw/DQoNCkkg d2lsbCBkaXJlY3RseSBtb2RpZnkgdGhlIHRleHQgZm9yIG15IHBhcnRpY3VsYXIgc2VjdGlvbiBh bmQgc2VuZCBpdA0Kb3V0IHRvIHRoZSB0ZWFtL0F2cmkgb24gYSBwZXIgc2VjdGlvbiBvciBwZXIt c3Vic2VjdGlvbiBiYXNpcy4gVGhhdCB3YXMNCndlIGNhbiBhbGwgd29yayBpbiBwYXJhbGxlbC4N Cg0KcmVnYXJkcw0KSG9ybXV6ZCANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEphbWFsIEhhZGkgU2FsaW0gWzxBIGNsYXNzPW1vei10eHQtbGluay1mcmVldGV4dCBocmVmPSJt YWlsdG86aGFkaUB6bnl4LmNvbSI+bWFpbHRvOmhhZGlAem55eC5jb208L0E+XSANClNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAyMCwgMjAwNCA1OjM1IEFNDQpUbzogPEEgY2xhc3M9bW96LXR4dC1s aW5rLWFiYnJldmlhdGVkIGhyZWY9Im1haWx0bzpmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmciPmZv cmNlcy1wcm90b2NvbEBpZXRmLm9yZzwvQT4NCkNjOiA8QSBjbGFzcz1tb3otdHh0LWxpbmstYWJi cmV2aWF0ZWQgaHJlZj0ibWFpbHRvOmF2cmlAcHNnLmNvbSI+YXZyaUBwc2cuY29tPC9BPjsgS2hv c3JhdmksIEhvcm11emQgTTsgPEEgY2xhc3M9bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIGhyZWY9 Im1haWx0bzpyYW0uZ29wYWxAbm9raWEuY29tIj5yYW0uZ29wYWxAbm9raWEuY29tPC9BPjsgTGln YW5nIERvbmc7DQpXZWltaW5nIFdhbmc7IFJvYmVydCBIYWFzDQpTdWJqZWN0OiBSZTogW0ZvcmNl cy1wcm90b2NvbF0gUmU6IHByb3RvY29sIGRyYWZ0IGVkaXRpbmc/DQoNCkF2cmkgbXVzdCBiZSBv biB0cmF2ZWwgb3IgdGllZCB1cCBzb21ld2hlcmUgYXJvdW5kIHRoZSBnbG9iZS4NClRoZSBsYXRl c3QgaSBjb3VsZCBmaW5kIGlzOg0KPEEgY2xhc3M9bW96LXR4dC1saW5rLWZyZWV0ZXh0IGhyZWY9 Imh0dHA6Ly9wc2cuY29tL35hdnJpL2ZvcmNlcy9kcmFmdC9BcmNoaXZlLUZvcmNlcy1Qcm90b2Nv bC0wMi56aXAiPmh0dHA6Ly9wc2cuY29tL35hdnJpL2ZvcmNlcy9kcmFmdC9BcmNoaXZlLUZvcmNl cy1Qcm90b2NvbC0wMi56aXA8L0E+DQoNCkRvZXMgYW55b25lIGtub3cgaWYgdGhlcmVzIHNvbWV0 aGluZyBuZXdlciBvciBzaG91bGQgd2Ugc3RhcnQgaGVyZT8NCkhvcm11emQgY2FuIHlvdSBwb3N0 IHRoYXQgdG9kbyBkaXN0cmlidXRpb24/DQoNCmNoZWVycywNCmphbWFsDQoNCk9uIFR1ZSwgMjAw NC0xMC0xOSBhdCAxOToyMywgSmFtYWwgSGFkaSBTYWxpbSB3cm90ZToNCiAgPC9QUkU+DQogICAg PEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPk9uIFR1ZSwgMjAwNC0xMC0xOSBh dCAxMTowNywgSmFtYWwgSGFkaSBTYWxpbSB3cm90ZToNCiAgICA8L1BSRT4NCiAgICAgIDxCTE9D S1FVT1RFIHR5cGU9ImNpdGUiPjxQUkUgd3JhcD0iIj5Ob3cgdGhhdCB3ZSBzZWVtIHRvIGhhdmUg bWFkZSBwcm9ncmVzcyBvbiB0aGUgYmFzaWNzLi4NCkF2cmksDQpDb3VsZCB5b3UgcG9zdCBhIFVS TCB0byB0aGUgeG1sIGRvY3MgdGhhdCB3ZSBjb3VsZCBzdGFydCBlZGl0aW5nPw0KV2UgY291bGQg c3RhcnQgd2l0aCB0aGUgVE9ETyBhY3Rpb24gaXRlbXMgYXMgcG9zdGVkIGJ5IEhvcm11emQuDQoN CmNoZWVycywNCmphbWFsDQogICAgICA8L1BSRT48L0JMT0NLUVVPVEU+PFBSRSB3cmFwPSIiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGb3JjZXMtcHJv dG9jb2wgbWFpbGluZyBsaXN0DQo8QSBjbGFzcz1tb3otdHh0LWxpbmstYWJicmV2aWF0ZWQgaHJl Zj0ibWFpbHRvOkZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyI+Rm9yY2VzLXByb3RvY29sQGlldGYu b3JnPC9BPg0KPEEgY2xhc3M9bW96LXR4dC1saW5rLWZyZWV0ZXh0IGhyZWY9Imh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcy1wcm90b2NvbCI+aHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzLXByb3RvY29sPC9BPg0KICAgIDwvUFJF PjwvQkxPQ0tRVU9URT48UFJFIHdyYXA9IiI+PCEtLS0tPg0KDQoNCiAgPC9QUkU+PC9CTE9DS1FV T1RFPjxCUj48UFJFIGNsYXNzPW1vei1zaWduYXR1cmUgY29scz0iNzIiPi0tIA0KUm9iZXJ0IEhh YXMNCklCTSBadXJpY2ggUmVzZWFyY2ggTGFib3JhdG9yeQ0KU+R1bWVyc3RyYXNzZSA0DQpDSC04 ODAzIFL8c2NobGlrb24vU3dpdHplcmxhbmQNCnBob25lICs0MS0xLTcyNC04Njk4ICBmYXggKzQx LTEtNzI0LTg1NzggIDxBIGNsYXNzPW1vei10eHQtbGluay1mcmVldGV4dCBocmVmPSJodHRwOi8v d3d3Lnp1cmljaC5pYm0uY29tL35yaGEiPmh0dHA6Ly93d3cuenVyaWNoLmlibS5jb20vfnJoYTwv QT48L1BSRT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_000A_01C4B7BB.AE1C8AD0-- --===============0157152716== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0157152716==-- From forces-protocol-bounces@ietf.org Thu Oct 21 14:06:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00364 for ; Thu, 21 Oct 2004 14:06:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhWu-0001nk-BW for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 14:19:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKh09-00067D-Sw; Thu, 21 Oct 2004 13:45:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgsA-00007L-KF for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 13:37:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26612 for ; Thu, 21 Oct 2004 13:37:08 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.104]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKh4o-0000jW-WA for forces-protocol@ietf.org; Thu, 21 Oct 2004 13:50:15 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9LHaHCE835134; Thu, 21 Oct 2004 13:36:17 -0400 Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9LHbcFD067928; Thu, 21 Oct 2004 13:37:38 -0400 Received: from [9.145.135.33] (sig-9-145-135-33.de.ibm.com [9.145.135.33]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA50550; Thu, 21 Oct 2004 19:36:13 +0200 Message-ID: <4177F37E.9050205@zurich.ibm.com> Date: Thu, 21 Oct 2004 19:35:59 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ligang Dong , "Khosravi, Hormuzd M" , hadi@znyx.com, avri@psg.com, ram.gopal@nokia.com, Weiming Wang References: <468F3FDA28AA87429AD807992E22D07E02F5D468@orsmsx408> <4177C1E2.4080506@zurich.ibm.com> <000d01c4b778$a015d380$8401a8c0@dlg> In-Reply-To: <000d01c4b778$a015d380$8401a8c0@dlg> X-Spam-Score: 1.5 (+) X-Scan-Signature: 442d80051e0361a34f3560325c4a7092 Cc: forces-protocol@ietf.org Subject: [Forces-protocol] Applying changes to Section 6 (Protocol Messages) X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0406163630==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: e3ebaaff3b3539efaf29ef65eea2aded This is a multi-part message in MIME format. --===============0406163630== Content-Type: multipart/alternative; boundary="------------090807010005020104000902" This is a multi-part message in MIME format. --------------090807010005020104000902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id i9LHaHCE835134 Content-Transfer-Encoding: quoted-printable Jamal: could you please send your potential-protocol-changes.txt file=20 again ? I can take care of transfering the changes into section 6 unless=20 someone else wants to do it. All: below is a rough list of changes and pending issues regarding=20 section 6. Please review. 6.1.1 Association: The CE could obtain the HBI with a=20 Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg=20 strcutrue, we have to remove HBI from the Assoc Setup msg. 6.1.2 How has the srcID=3D0 case been handled in the interop tests ? Is=20 this really feasible ? 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into the=20 FEProtocolLFB. 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note=20 that for the sake of symmetry, we should introduce a CEProtocolLFB. 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become settable=20 attributes in the FEProtocolLFB. 6.7 HB remains as is. In summary, we have the following operations defined for each message=20 type ( I broke the table into 3 parts): OPERATION APPLICABLE MESSAGE TYPES Assoc-Setup Assoc-Setup-Resp Assoc-Teardown Heartbeat no operations defined Query Query-Resp Config Config-Resp SET, DEL, UPDATE x x GET x x EV_S, EV_U x x (for event subscribe/unsubscribe) Packet-Redir PAYLOAD x Event-Notif Event-Notif-Resp EVENT x x Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we=20 have each time only one operation. Looks a bit redundant. Ideas ? Regards, -Robert Ligang Dong wrote: > hi, > Yes. I think ONE person writes one section first, so that the writing=20 > content and style are consistent throughout the section. Others give=20 > the comments and help the main editor improve it.=20 > Now let's volunteer to become the main editor of each section. > Best regards > Ligang > > ----- Original Message ----- > From: Robert Haas > To: Khosravi, Hormuzd M > Cc: hadi@znyx.com ; > forces-protocol@ietf.org ; > avri@psg.com ; ram.gopal@nokia.com > ; Ligang Dong > ; Weiming Wang > > Sent: Thursday, October 21, 2004 10:04 PM > Subject: Re: [Forces-protocol] Re: protocol draft editing? > > Hormuzd, > Section 6 is heavily impacted by the shift to "everything is an > LFB". Many sections and figures require complete re-editing. To > ensure consistency, we need one person to do one editing pass on > the entire section first. But your list says "everybody". > > What if I do this first pass before tomorrow ? Or has anyone > started already ? > > It also means that our description of the FE Protocol LFB must be > enhanced, possibly including the multicast table that Zsolt > started specifying. > > Regards, > -Robert > > Khosravi, Hormuzd M wrote: > >>Here is the distribution list... >> >>Abstract - Avri >>1. Introduction - Avri >>2. Definitions - Weiming >>3. Protocol Overview - Jamal >>4. TML Requirements - Jamal >>5. Common Header - Weiming, Ligang (Jamal/Robert) >>6. Protocol Messages - Hormuzd, Weiming (I expect everyone to be >>involved with this one) >>7. Protocol Scenarios - Hormuzd, Ram >>8. High Availability - Hormuzd >>9. Security Considerations - Ram >>10. References - Avri >>11. Acknowledgments - All >>Appendix >>A. Implementation Notes - All? >> >>I will directly modify the text for my particular section and send it >>out to the team/Avri on a per section or per-subsection basis. That was >>we can all work in parallel. >> >>regards >>Hormuzd=20 >> >>-----Original Message----- >>From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 >>Sent: Wednesday, October 20, 2004 5:35 AM >>To: forces-protocol@ietf.org >>Cc: avri@psg.com; Khosravi, Hormuzd M; ram.gopal@nokia.com; Ligang Dong= ; >>Weiming Wang; Robert Haas >>Subject: Re: [Forces-protocol] Re: protocol draft editing? >> >>Avri must be on travel or tied up somewhere around the globe. >>The latest i could find is: >>http://psg.com/~avri/forces/draft/Archive-Forces-Protocol-02.zip >> >>Does anyone know if theres something newer or should we start here? >>Hormuzd can you post that todo distribution? >> >>cheers, >>jamal >> >>On Tue, 2004-10-19 at 19:23, Jamal Hadi Salim wrote: >> =20 >> >>>On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote: >>> =20 >>> >>>>Now that we seem to have made progress on the basics.. >>>>Avri, >>>>Could you post a URL to the xml docs that we could start editing? >>>>We could start with the TODO action items as posted by Hormuzd. >>>> >>>>cheers, >>>>jamal >>>> =20 >>>> >>>_______________________________________________ >>>Forces-protocol mailing list >>>Forces-protocol@ietf.org >>>https://www1.ietf.org/mailman/listinfo/forces-protocol >>> =20 >>> >> >> >> >> =20 >> > >--=20 >Robert Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------090807010005020104000902 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jamal: could you please send your potential-protocol-changes.txt file again ? I can take care of transfering the changes into section 6 unless someone else wants to do it.

All: below is a rough list of changes and pending issues regarding section 6. Please review.

 6.1.1 Association: The CE could obtain the HBI with a Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg strcutrue, we have to remove HBI from the Assoc Setup msg.

 6.1.2 How has the srcID=0 case been handled in the interop tests ? Is this really feasible ?

 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into the FEProtocolLFB.

 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note that for the sake of symmetry, we should introduce a CEProtocolLFB.

 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become settable attributes in the FEProtocolLFB.

 6.7 HB remains as is.

In summary, we have the following operations defined for each message type ( I broke the table into 3 parts):

OPERATION       APPLICABLE MESSAGE TYPES

                Assoc-Setup  Assoc-Setup-Resp Assoc-Teardown Heartbeat

no operations
defined


                Query  Query-Resp  Config  Config-Resp
SET, DEL, UPDATE                     x          x
GET               x         x
EV_S, EV_U                           x          x

(for event subscribe/unsubscribe)


                Packet-Redir

PAYLOAD            x


                Event-Notif  Event-Notif-Resp
EVENT              x                x

Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we have each time only one operation. Looks a bit redundant. Ideas ?

Regards,
-Robert

Ligang Dong wrote:
hi,
Yes. I think ONE person writes one section first, so that the writing content and style are consistent throughout the section. Others give the comments and help the main editor improve it. 
Now let's volunteer to become the main editor of each section.
Best regards
Ligang
----- Original Message -----
Sent: Thursday, October 21, 2004 10:04 PM
Subject: Re: [Forces-protocol] Re: protocol draft editing?

Hormuzd,
Section 6 is heavily impacted by the shift to "everything is an LFB". Many sections and figures require complete re-editing. To ensure consistency, we need one person to do one editing pass on the entire section first. But your list says "everybody".

What if I do this first pass before tomorrow ? Or has anyone started already ?

It also means that our description of the FE Protocol LFB must be enhanced, possibly including the multicast table that Zsolt started specifying.

Regards,
-Robert

Khosravi, Hormuzd M wrote:
Here is the distribution list...

Abstract - Avri
1. Introduction - Avri
2. Definitions - Weiming
3. Protocol Overview - Jamal
4. TML Requirements - Jamal
5. Common Header - Weiming, Ligang (Jamal/Robert)
6. Protocol Messages - Hormuzd, Weiming (I expect everyone to be
involved with this one)
7. Protocol Scenarios - Hormuzd, Ram
8. High Availability - Hormuzd
9. Security Considerations - Ram
10. References - Avri
11. Acknowledgments - All
Appendix
A. Implementation Notes - All?

I will directly modify the text for my particular section and send it
out to the team/Avri on a per section or per-subsection basis. That was
we can all work in parallel.

regards
Hormuzd 

-----Original Message-----
From: Jamal Hadi Salim [mailto:hadi@znyx.com] 
Sent: Wednesday, October 20, 2004 5:35 AM
To: forces-protocol@ietf.org
Cc: avri@psg.com; Khosravi, Hormuzd M; ram.gopal@nokia.com; Ligang Dong;
Weiming Wang; Robert Haas
Subject: Re: [Forces-protocol] Re: protocol draft editing?

Avri must be on travel or tied up somewhere around the globe.
The latest i could find is:
http://psg.com/~avri/forces/draft/Archive-Forces-Protocol-02.zip

Does anyone know if theres something newer or should we start here?
Hormuzd can you post that todo distribution?

cheers,
jamal

On Tue, 2004-10-19 at 19:23, Jamal Hadi Salim wrote:
  
On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote:
    
Now that we seem to have made progress on the basics..
Avri,
Could you post a URL to the xml docs that we could start editing?
We could start with the TODO action items as posted by Hormuzd.

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



  

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

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------090807010005020104000902-- --===============0406163630== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0406163630==-- From forces-protocol-bounces@ietf.org Thu Oct 21 14:37:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04096 for ; Thu, 21 Oct 2004 14:37:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKi0p-0002rm-62 for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 14:50:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhkE-0003pO-Ra; Thu, 21 Oct 2004 14:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhOu-0002pd-M0 for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 14:11:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00762 for ; Thu, 21 Oct 2004 14:10:55 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhbT-0001uV-HO for forces-protocol@ietf.org; Thu, 21 Oct 2004 14:24:02 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102111130982:36158 ; Thu, 21 Oct 2004 11:13:09 -0700 Subject: Re: [Forces-protocol] Applying changes to Section 6 (Protocol Messages) From: Jamal Hadi Salim To: Robert Haas In-Reply-To: <4177F37E.9050205@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E02F5D468@orsmsx408> <4177C1E2.4080506@zurich.ibm.com> <000d01c4b778$a015d380$8401a8c0@dlg> <4177F37E.9050205@zurich.ibm.com> Organization: Znyx Networks Message-Id: <1098382235.1029.93.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Oct 2004 14:10:35 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/21/2004 11:13:10 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/21/2004 11:13:26 AM, Serialize complete at 10/21/2004 11:13:26 AM Content-Type: multipart/mixed; boundary="=-fFBDd39PN+ddZEwSivEa" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Weiming Wang X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 --=-fFBDd39PN+ddZEwSivEa Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 2004-10-21 at 13:35, Robert Haas wrote: > Jamal: could you please send your potential-protocol-changes.txt file > again ? I can take care of transfering the changes into section 6 > unless someone else wants to do it. > Sorry I am tied up for the next few hours hence my lack of immediate response. Attached: cheers, jamal --=-fFBDd39PN+ddZEwSivEa Content-Disposition: attachment; filename=potential-protocol-changes.txt Content-Type: text/plain; name=potential-protocol-changes.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Assumptions: ------------ a) Start by assuming BNF as discussed with model team (posted earlier). b) When no value is added by BNF discussed restore old scheme and fix associated BNF piece. c) Everything is a LFB. In other words you cant send a message to an entity "FE" or "CE" - you have to target an LFB class and instance. Main header ----------- No changes imposed by BNF 6.1 Association Messages ------------------------ 6.1.1 Association setup Message ------------------------------- Stays same, exception: No need for HB registration. That is now targeted to the FE protocol LFB. A suggestion is that perhaps a name TLV may need to be passed. Same level as LFB Select example main hdr (eg type = Association setup) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = FENAME | +-- "myname" 6.1.2 Association setup Response -------------------------------- Use a result TLV since as is now main hdr (eg type = Association setup response) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = FEResult | +-- resultvalue 6.1.3 Association Teardown message ----------------------------------- main hdr (eg type = Association tear) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = FEReason | +-- "myreason" 6.2 Query Messages ------------------- 6.2.1 Query message ------------------- main hdr (eg type = Query) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance | | | | | +-- T = GET | | | | | +-- // one or more path targets | | // under discussion | | The LFB is targeted. So if you need to find a route from an LPM you target that LFB. If you need to find neighbors of an FE you target the FE object LFB. The response is exactly the same as above with type = Query-response. 6.3 Configuration Message -------------------------- 6.3.1 Config request ---------------------- main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = target LFB class | | | | | +-- LFBInstance = target LFB instance | | | | | +-- T = operation { ADD, DEL, etc} | | | | | +-- // one or more path targets | | // under discussion | | | +-- T = operation { ADD, DEL, etc} | | | | | +-- // one or more path targets | | // under discussion | | | +-- T = operation { ADD, DEL, etc} | | | | | +-- // one or more path targets | | // under discussion | | In other words: Very similar to the way we have it already except the naming has changed and we can target multiple operations and multiple paths in an LFB instance Event-subscribe and unsubscribe are also seen as possible operations. 6.3.2 Config Response --------------------- IMO the same as above except direction is from FE->CE except type is config-response. We need to introduce a new TLV called result. Sender will need to request a summary or message in totality echoed back. 6.4 Events ---------- I thought we said we will have a Event subscription message, I dont see it anywhere. NOTE: Added to config-request config-response 1) Given the concept of "everything is an LFB" it is my opinion that subscriptions should happen at per LFB level. i.e the model (xml file) will have to define what events a LFB class throws. Added some new text on subscription as being part of config-response/request above to show this. 2) Given you can map _any_ attribute to a path ID, then I see the event notifications and responses message layout being very much like the config messages excpet the type will be one of those two (Eventnotify and Eventnotify-response) 6.5 Packet redirect ------------------- One suggestion: main hdr (eg type = Packet Redirect) | | +--- T = LFBselect | | | +-- LFBCLASSID = target class | | | | | +-- LFBInstance = target instance | | | +-- T = PACKET_REDIR_OPER | | | | | +-- // one or more packets 6.6 State Maintanance --------------------- Gone. This should target the FE protocol object LFB . 6.7 Heartbeats -------------- My opinion is that this is gone or needs to target some LFB. Hormuzd so far is of mindest to maintain old approach. $Log: potential-protocol-changes.txt,v $ Revision 1.3 2004/10/18 12:29:22 hadi updated config/get to be query/get Revision 1.2 2004/10/16 14:58:04 hadi some minor changes based on input from Hormuzd one outstanding issue seems to be the query Revision 1.1 2004/10/14 18:53:40 hadi Initial revision --=-fFBDd39PN+ddZEwSivEa Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=-fFBDd39PN+ddZEwSivEa-- From forces-protocol-bounces@ietf.org Thu Oct 21 14:57:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05854 for ; Thu, 21 Oct 2004 14:57:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiKR-0003Ns-Br for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 15:10:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhmK-0005F0-TJ; Thu, 21 Oct 2004 14:35:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhg4-0001h3-2F for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 14:28:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02769 for ; Thu, 21 Oct 2004 14:28:42 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhsi-0002TP-6R for forces-protocol@ietf.org; Thu, 21 Oct 2004 14:41:49 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9LIVeed016152; Thu, 21 Oct 2004 18:31:54 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9LIUYYx001294; Thu, 21 Oct 2004 18:31:25 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102111274028484 ; Thu, 21 Oct 2004 11:27:40 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 11:27:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Forces-protocol] Re: protocol draft editing? Date: Thu, 21 Oct 2004 11:26:06 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579200@orsmsx408> Thread-Topic: [Forces-protocol] Re: protocol draft editing? Thread-Index: AcS3dy0BfFhdemFoTB+pTt3zO89A2wAI/z+Q From: "Khosravi, Hormuzd M" To: "Robert Haas" X-OriginalArrivalTime: 21 Oct 2004 18:27:40.0903 (UTC) FILETIME=[A62D7F70:01C4B79B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.2 (/) X-Scan-Signature: c07eeb7900970a16fe4056cc74ae9ce2 Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Weiming Wang X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0004201873==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff This is a multi-part message in MIME format. --===============0004201873== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B79B.A5364BCC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B79B.A5364BCC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Robert, =20 Weiming and myself are already working on this section...I will send out = what I have shortly. Some of the changes are pretty straightforward, e.g. remove section 6.6 = :-) =20 Anyways we could definitely use help in the draft, there is lots of = stuff that needs to be done I will send out a list of other todo items shortly.. =20 regards Hormuzd =20 ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Thursday, October 21, 2004 7:04 AM To: Khosravi, Hormuzd M Cc: hadi@znyx.com; forces-protocol@ietf.org; avri@psg.com; = ram.gopal@nokia.com; Ligang Dong; Weiming Wang Subject: Re: [Forces-protocol] Re: protocol draft editing? =20 Hormuzd, Section 6 is heavily impacted by the shift to "everything is an LFB". = Many sections and figures require complete re-editing. To ensure = consistency, we need one person to do one editing pass on the entire = section first. But your list says "everybody".=20 What if I do this first pass before tomorrow ? Or has anyone started = already ? It also means that our description of the FE Protocol LFB must be = enhanced, possibly including the multicast table that Zsolt started = specifying. Regards, -Robert Khosravi, Hormuzd M wrote: Here is the distribution list... =20 Abstract - Avri 1. Introduction - Avri 2. Definitions - Weiming 3. Protocol Overview - Jamal 4. TML Requirements - Jamal 5. Common Header - Weiming, Ligang (Jamal/Robert) 6. Protocol Messages - Hormuzd, Weiming (I expect everyone to be involved with this one) 7. Protocol Scenarios - Hormuzd, Ram 8. High Availability - Hormuzd 9. Security Considerations - Ram 10. References - Avri 11. Acknowledgments - All Appendix A. Implementation Notes - All? =20 I will directly modify the text for my particular section and send it out to the team/Avri on a per section or per-subsection basis. That was we can all work in parallel. =20 regards Hormuzd=20 =20 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Wednesday, October 20, 2004 5:35 AM To: forces-protocol@ietf.org Cc: avri@psg.com; Khosravi, Hormuzd M; ram.gopal@nokia.com; Ligang Dong; Weiming Wang; Robert Haas Subject: Re: [Forces-protocol] Re: protocol draft editing? =20 Avri must be on travel or tied up somewhere around the globe. The latest i could find is: http://psg.com/~avri/forces/draft/Archive-Forces-Protocol-02.zip =20 Does anyone know if theres something newer or should we start here? Hormuzd can you post that todo distribution? =20 cheers, jamal =20 On Tue, 2004-10-19 at 19:23, Jamal Hadi Salim wrote: =20 On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote: =20 Now that we seem to have made progress on the basics.. Avri, Could you post a URL to the xml docs that we could start editing? We could start with the TODO action items as posted by Hormuzd. =20 cheers, jamal =20 =20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol =20 =20 =20 =20 =20 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha ------_=_NextPart_001_01C4B79B.A5364BCC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Robert,

 

Weiming and myself are already = working on this section…I will send out what I have = shortly.

Some of the changes are pretty straightforward, e.g. remove section 6.6 J

 

Anyways we could definitely use = help in the draft, there is lots of stuff that needs to be = done

I will send out a list of other = todo items shortly..

 

regards

Hormuzd

 

From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Thursday, October = 21, 2004 7:04 AM
To: Khosravi, Hormuzd = M
Cc: hadi@znyx.com; forces-protocol@ietf.org; avri@psg.com; ram.gopal@nokia.com; Ligang = Dong; Weiming Wang
Subject: Re: = [Forces-protocol] Re: protocol draft editing?

 

Hormuzd,
Section 6 is heavily impacted by the shift to "everything is an = LFB". Many sections and figures require complete re-editing. To ensure = consistency, we need one person to do one editing pass on the entire section first. = But your list says "everybody".

What if I do this first pass before tomorrow ? Or has anyone started = already ?

It also means that our description of the FE Protocol LFB must be = enhanced, possibly including the multicast table that Zsolt started = specifying.

Regards,
-Robert

Khosravi, Hormuzd M wrote:

Here is the distribution =
list...
 
Abstract - Avri
1. Introduction - =
Avri
2. Definitions - =
Weiming
3. Protocol Overview - =
Jamal
4. TML Requirements - =
Jamal
5. Common Header - Weiming, Ligang =
(Jamal/Robert)
6. Protocol Messages - Hormuzd, Weiming (I =
expect everyone to be
involved with this =
one)
7. Protocol Scenarios - Hormuzd, =
Ram
8. High Availability - =
Hormuzd
9. Security Considerations - =
Ram
10. References - =
Avri
11. Acknowledgments - =
All
Appendix
A. Implementation Notes - =
All?
 
I will directly modify the text for my =
particular section and send it
out to the team/Avri on a per section or =
per-subsection basis. That was
we can all work in =
parallel.
 
regards
Hormuzd 
 
-----Original =
Message-----
From: Jamal Hadi Salim [mailto:hadi@znyx.com] =

Sent: Wednesday, October 20, 2004 5:35 =
AM
To: forces-protocol@ietf.org
Cc: avri@psg.com; Khosravi, Hormuzd M; ram.gopal@nokia.com; Ligang =
Dong;
Weiming Wang; Robert =
Haas
Subject: Re: [Forces-protocol] Re: protocol =
draft editing?
 
Avri must be on travel or tied up somewhere =
around the globe.
The latest i could find =
is:
http://psg.com/~avri/forces/draft/Archive-Forces-Protocol-02.zip
 
Does anyone know if theres something newer or =
should we start here?
Hormuzd can you post that todo =
distribution?
 
cheers,
jamal
 
On Tue, 2004-10-19 at 19:23, Jamal Hadi Salim =
wrote:
=A0 
On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim =
wrote:
=A0=A0=A0 
Now that we seem to have made progress on the =
basics..
Avri,
Could you post a URL to the xml docs that we =
could start editing?
We could start with the TODO action items as =
posted by Hormuzd.
 
cheers,
jamal
=A0=A0=A0=A0=A0 =

 
______________________________________________=
_
Forces-protocol mailing =
list
Forces-protocol@ietf.org
https://w=
ww1.ietf.org/mailman/listinfo/forces-protocol
=A0=A0=A0 
 
 
 
=A0 



-- 
Robert Haas
IBM Zurich Research =
Laboratory
S=E4umerstrasse =
4
CH-8803 =
R=FCschlikon/Switzerland
phone +41-1-724-8698=A0 fax +41-1-724-8578=A0 =
http://www.zurich.ibm.com/~rha
------_=_NextPart_001_01C4B79B.A5364BCC-- --===============0004201873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0004201873==-- From forces-protocol-bounces@ietf.org Thu Oct 21 14:57:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05915 for ; Thu, 21 Oct 2004 14:57:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiKk-0003OO-3b for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 15:10:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhmg-0005Or-70; Thu, 21 Oct 2004 14:35:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhhv-0002aJ-Ti for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 14:30:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02934 for ; Thu, 21 Oct 2004 14:30:37 -0400 (EDT) Received: from [204.85.2.226] (helo=mail.modnetinc.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKhua-0002WU-65 for forces-protocol@ietf.org; Thu, 21 Oct 2004 14:43:45 -0400 Received: (qmail 13686 invoked by uid 530); 21 Oct 2004 18:30:04 -0000 Received: from zsolt@modularnet.com by proteus-01.proteandevices.com by uid 527 with qmail-scanner-1.16 (clamscan: 0.54. Clear:. Processed in 0.630501 secs); 21 Oct 2004 18:30:04 -0000 Received: from proteus-02.proteandevices.com (HELO ?127.0.0.1?) (192.168.0.202) by 0 with SMTP; 21 Oct 2004 18:30:03 -0000 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Zsolt Haraszti To: "Wang,Weiming" In-Reply-To: <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> Content-Type: text/plain Organization: Modular Networks, Inc. Message-Id: <1098383190.2883.386.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 21 Oct 2004 14:26:42 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , "Joel M. Halpern" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , Alan DeKok , Jamal Hadi Salim , forces-protocol@ietf.org, Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit Weiming, I have a very hard time to resonate with your examples, and therefore with your reasoning. For one, if you end up needing 64k LFBs from the same class, I think you or we did something wrong with the model. Sure you mean it an extreme case, but I think it is a misleading one. I envision practical LFB models having up to a few hundred LFB instances, where multiple instances of the same class will be in very different roles (e.g., a Classifier LFB supporting Diffserv versus a Classifier LFB supporting IPsec, etc.), hence more often not sharing any config data than sharing some. For two, displacing the two parts of the LFB address (class ID and instance ID) in the protocol is a much bigger concern to me than to allow ad-hoc/state-less multicast addressing. It would be in some sense similar to if in the IP header the (sub-)network address and host-address part of the IP address were placed in distant offsets. For three, on state-less versus state-ful multicast: Your example below is based on the very extreme case when you have a SINGLE config message addressed to a VERY LARGE number of LFB instances of the same class. I have not yet seen a practical case for this scenario. I reiterate that multicast groups are not ad-hoc, and there will be typically a large number of config updates sent to a group after the group is formed. Regards, Zsolt On Wed, 2004-10-20 at 01:56, Wang,Weiming wrote: > Joel, > > ----- Original Message ----- > From: "Joel M. Halpern" > Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? > > > > I do think that there may be thousands of instances. > > I do not think that this requires multiple addressing. > > > > I think that there are some interesting cases prompted by the possibility > > of very large numbers of LFBs, but they do not drive multiple addressing. > > > > My reasoning is based on the following premise. > > Firstly, if there are many LFBinstances s of a class, then it is likely > > that many fields of the LFB instances will be the same, but it is extremely > > unlikely that all fields of the LFB instances will be the same. > [Weiming]That's just why explicit multipul addressing is needed. For the case of > fields of all LFBinsatnces are the same, we can simply use a broadcast to do so. > Let me try to show a scenario why multipul addressing is needed for different > fields case. > > Firstly, because we have assumed the 16bit insatnce Id is not enough, we can > reasonably assmue there is a case where there are 64k or more instances (say > 64k). Further, we suppose Id1 to Id32k need to config parameter 1, Id(32k+1) to > Id 64k to set parameter2. > > Then, by using single instance addressing, the protocol becomes horrible, either > using one message or using separate messages. I just show the one message case. > The message format would like like: > > Msghdr > LFBselect > LFBClassID > Instance ID1 > Parameter1 > Instance ID2 > Parameter1 > ... > ... > Instance ID 32k > Parameter1 > Insatnce ID (32k+1) > Parameter2 > .... > Instance ID 64k > Parameter 2 > > Remember we then have 64k pair of instance and parameter in the protocol text. > In some cases, I'm just worried this make protocol unpractical. > > By using multipul addressing, the only text is as: > Msghdr > LFBselect > LFBClassID > Instance ID1 to ID 32k > Parameter1 > Instance ID (32k+1) to ID 64k > Parameter2 > > By using multicast scheme supposed by Zsolt, I suppose we need following steps: > 1. send a FE attribute to FE object to setup a virtualID1 for Instance 1 to > Instance 32k > 2. send a FE attribute to FE object to setup a virtualID2 for Instance (32k+1) > to Instance 64k > 3. config: > Msghdr > LFBselect > LFBClassID > Virtual ID1 > Parameter1 > Virtual ID2 > Parameter2 > 4. send a message to release virtual ID1 > 5. send a message to release virtual ID2 > > I can see the advatage of above explicit multipul addressing scheme very > clearly. > > > The simplest case to understand when one would need to setup all those LFBs > > at once is in a power recovery situation (the FE lost power, then > > recovered to an empty state.) The CE needs to send the configuration > > information to the FE. > [Weiming]Yes, that's the one case but not the only. > > > Secondly, I believe that transaction count is much more important than data > > volume. The FE is going to have to set every field in every LFB. Encoding > > is not going to change that. > [Weiming]I'm not sure if you mean for every operation, we should maintain a > transaction count. If is, then I have to say our current one message with > multiple Operation definitions has already be against the requirement. My > opinion is transaction maintenance is moderate, while multicast and multiple > operation are more important. > > > Given that there are distinct values in each LFB instance, there must be an > > operation against each LFB instance. > I don't think multicast will loose operation individuality. > > > > The marginal gain from having a single transaction to update the identical > > fields, and then individual transactions for the distinct fields is very > > small. It does not reduce the number of IOs or the core transaction rate. > [Weiming]At least it saves bits greatly and makes protocol practical. Remember > the capability between CE and FE are quite limited, especially in muli-hop > ForCES application. > > > > If it is desired to optimize for this case, we may want to introduce (in a > > future version of the protocol) some kind of block checkpoint / restart > > mechanism. The CE would record its full state about the FE, and then ask > > the FE for a dump suitable for restoral of the FE state. Upon restart, the > > CE would rebuild its state from its stored representation, and would ship > > the dump back to the FE to enable efficient rebuilding there. I can see > > significant value in such a mechanism. I do not however see a need to > > include this in the first deliverable of the protocol. > [Weiming]I suppose this is only for restart case, I can see many cases where > multiple addressing can apply, such as delete, change of LFB parameter, load and > unload of LFBs, etc. And also I think the scheme above is much more complex than > multiple addressing. So, my conclusion is, with a little bit expansion, we can > gain much, then why not we adpot it? > > Best regards, > Weiming > > > > Yours, > > Joel M. Halpern > -- Zsolt Haraszti Phone: +1 919-765-0027/2017 Modular Networks Mobile: +1 919-522-2337 Email: zsolt@modularnet.com _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 15:24:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09994 for ; Thu, 21 Oct 2004 15:24:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKikg-00047i-4L for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 15:37:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiSe-0003zb-HR; Thu, 21 Oct 2004 15:18:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiGX-0002P9-0k for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 15:06:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07183 for ; Thu, 21 Oct 2004 15:06:23 -0400 (EDT) Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiTA-0003gU-Ev for forces-protocol@ietf.org; Thu, 21 Oct 2004 15:19:31 -0400 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.43) id 1CKiAj-0007Ue-9r; Thu, 21 Oct 2004 15:00:25 -0400 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Steven Blake To: Robert Haas In-Reply-To: <417573E8.7070502@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408> <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> <417573E8.7070502@zurich.ibm.com> Content-Type: text/plain Message-Id: <1098385216.2340.239.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 21 Oct 2004 15:00:17 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , Zsolt Haraszti , "Joel M. Halpern" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , "Wang, Weiming" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit On Tue, 2004-10-19 at 16:07, Robert Haas wrote: > I think Zsolt has specified the multicast at LFB Instance-level very > well. We had some discussions with Joel a while back and such a table > with pointers from a -virtualID- to a list of LFB Instances was > considered the way to go. Agreed. > But the subtle difference betwen Zsolt's proposal and the current > approach taken in the protocol draft is that the PL-message > destination ID is the -virtualID-, instead of introducing a new MIID. > See Section 5 point g in the protocol draft. > > I would favor the current approach for the following reasons (but I am > not religious and want to hear other opinions): > > 1) -virtualID- must be unique NE-wide. The PL-level addressing IDs > are by definition unique NE-wide. Agreed. > 2) Messages addressed to a group of LFBs that spans FE A and B should > not be delivered to FE C. So a PL-level multicasting is anyway needed > . Adding an additional MIID would then be redundant. Eliminating the MIID (or any LFB instance ID) from these messages would be a very bad layering violation. We need the PL-level multicast to scope the message delivery to FEs A & B, but not C (in fact, for efficiency, we need the multicast FEID to map to a TML "multicast" group). I wouldn't suggest mixing in any LFB class/instance ID semantics into the FEID beyond that. LFBclass/instance ID multicasting is still needed primarily for scoping messages to instances of a class on multiple FEs that need to share a configuration (e.g., global prefix/nexthop table updates). Since we have assumed that the FE assigns LFB instance IDs, the CE cannot normally coordinate LFB instance ID assignment between FEs such that a single PL message addressed to a FE multicast group will be accepted by multiple LFB instances. But if we introduce MIIDs which are assigned by the CE, then the CE can achieve the coordination. So for the canonical case of being able to multicast routing updates to multiple FEs, we would need both a PL-level multicast FEID, and a LFBselect TLV-level mulicast LFB instance ID (MIID). > To cover the case of a list of LFB Instances (reminds me of xcast ;-) > we can modify the LFBSelect TLV as follows: > main hdr (eg type = config)| > +--- T = LFBselect > | | > | +-- LFBCLASSID = target LFB class > | | > | | > | +-- one more LFBInstance(s) = target LFB instance(s). > [the size of this TLV tells how long the list is] I'm not sure this is needed. If we have multiple LFB instances of a certain class on an FE sharing configuration data, I would like to see that explicitly represented in the model (a todo from the August IETF that I haven't followed through on yet), rather than xcast'ing config messages. Regards, // Steve _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 15:48:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12859 for ; Thu, 21 Oct 2004 15:48:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKj7y-0004pk-2x for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 16:01:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKitq-0000Cn-Vn; Thu, 21 Oct 2004 15:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKifH-0005rj-EP for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 15:31:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10731 for ; Thu, 21 Oct 2004 15:31:57 -0400 (EDT) Received: from [64.254.114.117] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKirm-0004Ge-48 for forces-protocol@ietf.org; Thu, 21 Oct 2004 15:45:05 -0400 Received: from JLaptop.megisto.com ([192.168.20.234]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Oct 2004 15:30:55 -0400 Message-Id: <5.1.0.14.0.20041021152630.022f5218@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Oct 2004 15:30:38 -0400 To: Zsolt Haraszti , "Wang,Weiming" From: "Joel M. Halpern" Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? In-Reply-To: <1098383190.2883.386.camel@localhost.localdomain> References: <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 21 Oct 2004 19:30:56.0030 (UTC) FILETIME=[7C3FEBE0:01C4B7A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, Jamal Hadi Salim , Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a While I do not think it is common, I do think that some implementations without misusing the model will end up with that many or more LFB instances of a single class. The example I gave before is an FE serving an OC48 which can be subdivided for fixed rate ports down to DS0. You can argue that we should invent a multi-port LFB, but that does not seem an inevitable situation. The odd aspect of this is the if we implement sending the same update to multiple LFB instances, it will actually be easier to make some changes if the ports are separate LFBs than it will be if they are table entries in a single LFB. Or else we end up needing block selection syntax for SETs, with implicit element replication. Which suggests we are doing something wrong, since that would mean 3 levels of multicast replication inside the system. Yours, Joel At 02:26 PM 10/21/2004 -0400, Zsolt Haraszti wrote: >For one, if you end up needing 64k LFBs from the same class, I think >you or we did something wrong with the model. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 20:12:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08883 for ; Thu, 21 Oct 2004 20:12:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnFj-0004zz-W5 for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 20:25:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl6Y-0005Fa-Bn; Thu, 21 Oct 2004 18:08:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKj6D-00024t-Fi for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 15:59:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14047 for ; Thu, 21 Oct 2004 15:59:47 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjIq-00050o-1c for forces-protocol@ietf.org; Thu, 21 Oct 2004 16:12:56 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9LJwTw9029697; Thu, 21 Oct 2004 19:58:33 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9LJnqQw017255; Thu, 21 Oct 2004 19:52:27 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102112584402482 ; Thu, 21 Oct 2004 12:58:44 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 12:58:44 -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 Date: Thu, 21 Oct 2004 12:58:43 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02F99D71@orsmsx408> Thread-Topic: Instance Select Thread-Index: AcS3KWjvIyJRVxv/SXmJN4rdmHOGUgAflu8Q From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 21 Oct 2004 19:58:44.0408 (UTC) FILETIME=[5EAE3380:01C4B7A8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: "Joel M. Halpern" , ram.gopal@nokia.com, zsolt@nc.rr.com, "Steven Blake \(petri-meat\)" , hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , "Yang, Lily L" Subject: [Forces-protocol] RE: Instance Select X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Weiming, I haven't seen any compelling example (real NE) to need this kind of functionality in the protocol. Therefore, I don't think this complexity needs to be added...at most we need a Broadcast Instance ID definition (Send msgs to all LFBs of a particular Type). But I will be happy to hear what Jamal, others have to say on this ? I am not religious either way... regards Hormuzd=20 -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn]=20 Sent: Wednesday, October 20, 2004 9:48 PM To: forces-protocol@ietf.org Cc: Khosravi, Hormuzd M; hadi@znyx.com; Joel M. Halpern; ram.gopal@nokia.com; Yang, Lily L; Alan DeKok; zsolt@nc.rr.com; Steven Blake (petri-meat); Deleganes, Ellen M Subject: Instance Select Hi Jamal, Hormuzd, etc, To summarize the discussions on multiple instances, I try to propose following scheme for instance selection, which follows Robert's idea and Jamal's format, as: PL level PDU : =3D MAINHDR+ LFBselect :=3D LFBCLASSID InsSelect + InsSelect :=3D InstanceID + RangeMark :=3D '0xFFFFFFFF'; the value is the same as Broadcast Instance address, no worry of ambiguity here. The InsSelect is a TLV, whose structure is shown as: main hdr (eg type =3D config) | | +-- T =3D LFBselect | | | +- LFBCLASSID =3D target LFB class | | | | | +- T =3D InsSelect | | | | | V =3D InstanceID + | | | +- T =3D operation { ADD, DEL, GET, etc} ... Best Regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 20:59:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18003 for ; Thu, 21 Oct 2004 20:59:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnzO-0007yD-SR for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:13:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl9L-000055-Qd; Thu, 21 Oct 2004 18:11:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjLs-0001n4-SG for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 16:16:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16621 for ; Thu, 21 Oct 2004 16:15:58 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjYW-0005oB-A7 for forces-protocol@ietf.org; Thu, 21 Oct 2004 16:29:07 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102113182380:36377 ; Thu, 21 Oct 2004 13:18:23 -0700 Subject: RE: [Forces-protocol] Re: protocol draft editing? From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579200@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579200@orsmsx408> Organization: Znyx Networks Message-Id: <1098389749.1029.136.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Oct 2004 16:15:49 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/21/2004 01:18:24 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/21/2004 01:18:29 PM, Serialize complete at 10/21/2004 01:18:30 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/21/2004 01:18:30 PM Content-Type: multipart/mixed; boundary="=-TifZCLy0V+F98VFXKi/v" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 --=-TifZCLy0V+F98VFXKi/v Content-Type: text/plain Content-Transfer-Encoding: 7bit Avri, Are you compiling all the changes? For this iteration of the draft I will leave the TML section alone. The only change i am making on the overview is attached as a diff. Avri, if you cant handle diffs i will send you the xml. Robert,Weiming, Ligang: Are you taking care of the common header section or should i jump into that next? Not that i think there are any useful changes tomake for this version of draft. BTW, folks I would like to volunteer to present on the protocol this time if people are OK with it. cheers, jamal --=-TifZCLy0V+F98VFXKi/v Content-Disposition: attachment; filename=overview.patch Content-Type: text/plain; name=overview.patch; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit --- overview.xml 2004/10/21 20:02:55 1.1 +++ overview.xml 2004/10/21 20:12:39 @@ -442,6 +442,8 @@ Some TML capability description(s) + +
FE Protocol attributes: current version of the ForCES protocol @@ -519,7 +521,15 @@
-TBD + +There are several batching levels at different protocol hierachies. + + multiple PL PDUs can be aggregated under one TML message + multiple LFB classes and instances can be addressed within +one PL PDU +Multiple operations can be addressed to a single LFB class and +instance +
--=-TifZCLy0V+F98VFXKi/v Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=-TifZCLy0V+F98VFXKi/v-- From forces-protocol-bounces@ietf.org Thu Oct 21 21:00:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18043 for ; Thu, 21 Oct 2004 21:00:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnzZ-0007yV-RB for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:13:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl9Q-0000DJ-Ju; Thu, 21 Oct 2004 18:11:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjNB-0002W7-0J for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 16:17:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16867 for ; Thu, 21 Oct 2004 16:17:18 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjZq-0005sD-Qn for forces-protocol@ietf.org; Thu, 21 Oct 2004 16:30:27 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9LKGiJ8381662 for ; Thu, 21 Oct 2004 16:16:44 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9LKGiAm150162 for ; Thu, 21 Oct 2004 14:16:44 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9LKGhsd024817 for ; Thu, 21 Oct 2004 14:16:43 -0600 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9LKGeVF024697; Thu, 21 Oct 2004 14:16:41 -0600 Received: from [9.145.255.13] (sig-9-145-255-13.de.ibm.com [9.145.255.13]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA79856; Thu, 21 Oct 2004 22:16:33 +0200 Message-ID: <41781915.1030401@zurich.ibm.com> Date: Thu, 21 Oct 2004 22:16:21 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steven Blake Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408> <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> <417573E8.7070502@zurich.ibm.com> <1098385216.2340.239.camel@localhost.localdomain> In-Reply-To: <1098385216.2340.239.camel@localhost.localdomain> X-Spam-Score: 0.5 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , Zsolt Haraszti , "Joel M. Halpern" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , "Wang, Weiming" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0459089876==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 This is a multi-part message in MIME format. --===============0459089876== Content-Type: multipart/alternative; boundary="------------070207060807010307090303" This is a multi-part message in MIME format. --------------070207060807010307090303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id i9LKGiJ8381662 Content-Transfer-Encoding: quoted-printable Steve, Steven Blake wrote: >>2) Messages addressed to a group of LFBs that spans FE A and B should >>not be delivered to FE C. So a PL-level multicasting is anyway needed >>. Adding an additional MIID would then be redundant. >> =20 >> > >Eliminating the MIID (or any LFB instance ID) from these messages would >be a very bad layering violation. We need the PL-level multicast to >scope the message delivery to FEs A & B, but not C (in fact, for >efficiency, we need the multicast FEID to map to a TML "multicast" >group). I wouldn't suggest mixing in any LFB class/instance ID >semantics into the FEID beyond that. > >LFBclass/instance ID multicasting is still needed primarily for scoping >messages to instances of a class on multiple FEs that need to share a >configuration (e.g., global prefix/nexthop table updates). >Since we have assumed that the FE assigns LFB instance IDs, the CE >cannot normally coordinate LFB instance ID assignment between FEs such >that a single PL message addressed to a FE multicast group will be >accepted by multiple LFB instances. But if we introduce MIIDs which are >assigned by the CE, then the CE can achieve the coordination. > > =20 > Let me disuss this with a more detailed example. Suppose instances LFBx1=20 and LFBx2 in FE x and LFBy1 in FE y must be configured with the same valu= es. With the "layer-breaking" model, the CE assigns a mcast ID m to which FE=20 x and FE y listen. FE x has a table with an entry (m, {LFBx1, LFBx2}),=20 and FE y an entry (m, {LFBy1}). With Zsolt's model, the CE assigns a mcast ID m to which FE x and FE y=20 listen. The CE also defines an MIID M. FE x has a table with an entry=20 (m) and FE y an entry (m) (basically, the groups those FEs belong to).=20 Then FE x has another table (M, {LFBx1, LFBx2}), and FE y (M, {LFBy1}). I do agree that in your model, if you wanted to address another set of=20 LFBs, say LFBx3 in FE x and LFBy2 and LFBy3 in FE y, then the same mcast=20 id m could be used, and you would simply define another M'. The tables=20 would be in FE x (M', {LFBx3}) and in FE y (M',{LFBy2, LFBy3}). Now, even though we have way enough ~2^30 mcast IDs, I understand why=20 you favor your approach. Note that in the current draft, this was stated=20 as a possiblity (but instead of specifying a -virtualID-, I wrote VPN=20 ID, quite the same idea). Do you think we should explicitely forbid the "layer-breaking" option,=20 or could we use both ? Regards, --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------070207060807010307090303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Steve,

Steven Blake wrote:
2)  Messages addressed to a group of LFBs that spans FE A and B should
not be delivered to FE C. So a PL-level multicasting is anyway needed
. Adding an additional MIID would then be redundant.
    

Eliminating the MIID (or any LFB instance ID) from these messages would
be a very bad layering violation.  We need the PL-level multicast to
scope the message delivery to FEs A & B, but not C (in fact, for
efficiency, we need the multicast FEID to map to a TML "multicast"
group).  I wouldn't suggest mixing in any LFB class/instance ID
semantics into the FEID beyond that.

LFBclass/instance ID multicasting is still needed primarily for scoping
messages to instances of a class on multiple FEs that need to share a
configuration (e.g., global prefix/nexthop table updates).
Since we have assumed that the FE assigns LFB instance IDs, the CE
cannot normally coordinate LFB instance ID assignment between FEs such
that a single PL message addressed to a FE multicast group will be
accepted by multiple LFB instances.  But if we introduce MIIDs which are
assigned by the CE, then the CE can achieve the coordination.
Let me disuss this with a more detailed example. Suppose instances LFBx1 and LFBx2 in FE x and LFBy1 in FE y must be configured with the same values.

With the "layer-breaking" model, the CE assigns a mcast ID m to which FE x and FE y listen. FE x has a table with an entry (m, {LFBx1, LFBx2}), and FE y an entry (m, {LFBy1}).

With Zsolt's model, the CE assigns a mcast ID m to which FE x and FE y listen. The CE also defines an MIID M. FE x has a table with an entry (m) and FE y an entry (m) (basically, the groups those FEs belong to). Then FE x has another table (M, {LFBx1, LFBx2}), and FE y (M, {LFBy1}).

I do agree that in your model, if you wanted to address another set of LFBs, say LFBx3 in FE x and LFBy2 and LFBy3 in FE y, then the same mcast id m could be used, and you would simply define another M'. The tables would be in FE x (M', {LFBx3}) and in FE y (M',{LFBy2, LFBy3}).

Now, even though we have way enough ~2^30 mcast IDs, I understand why you favor your approach. Note that in the current draft, this was stated as a possiblity (but instead of specifying a -virtualID-, I wrote VPN ID, quite the same idea).

Do you think we should explicitely forbid the "layer-breaking" option, or could we use both ?

Regards,
-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------070207060807010307090303-- --===============0459089876== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0459089876==-- From forces-protocol-bounces@ietf.org Thu Oct 21 21:00:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18134 for ; Thu, 21 Oct 2004 21:00:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnzw-0007z7-BQ for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:13:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl9W-0000Li-4H; Thu, 21 Oct 2004 18:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjOp-0003pa-7b for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 16:19:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17162 for ; Thu, 21 Oct 2004 16:19:00 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjbV-0005xX-NM for forces-protocol@ietf.org; Thu, 21 Oct 2004 16:32:10 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102113213374:36381 ; Thu, 21 Oct 2004 13:21:33 -0700 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02F99D71@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02F99D71@orsmsx408> Organization: Znyx Networks Message-Id: <1098389939.1029.140.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Oct 2004 16:18:59 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/21/2004 01:21:33 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/21/2004 01:21:35 PM, Serialize complete at 10/21/2004 01:21:35 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, "Wang, Weiming" , "Joel M. Halpern" , "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, Alan DeKok , zsolt@nc.rr.com, "Yang, Lily L" , Ellen M Deleganes Subject: [Forces-protocol] RE: Instance Select X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit My opinion is this issue should be defered for this release of the protocol draft. If Weiming can be given a slot to present on the topic (I will also provide him with my data) then lets discuss at the meeting. If not a presentation then maybe over a meal and some good caffeine. cheers, jamal On Thu, 2004-10-21 at 15:58, Khosravi, Hormuzd M wrote: > Weiming, > > I haven't seen any compelling example (real NE) to need this kind of > functionality in the protocol. > Therefore, I don't think this complexity needs to be added...at most we > need a Broadcast Instance ID definition (Send msgs to all LFBs of a > particular Type). But I will be happy to hear what Jamal, others have to > say on this ? I am not religious either way... > > > regards > Hormuzd > > -----Original Message----- > From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn] > Sent: Wednesday, October 20, 2004 9:48 PM > To: forces-protocol@ietf.org > Cc: Khosravi, Hormuzd M; hadi@znyx.com; Joel M. Halpern; > ram.gopal@nokia.com; Yang, Lily L; Alan DeKok; zsolt@nc.rr.com; Steven > Blake (petri-meat); Deleganes, Ellen M > Subject: Instance Select > > Hi Jamal, Hormuzd, etc, > > To summarize the discussions on multiple instances, I try to propose > following > scheme for instance selection, which follows Robert's idea and Jamal's > format, > as: > > PL level PDU : = MAINHDR+ > LFBselect := LFBCLASSID InsSelect + > InsSelect := InstanceID + > RangeMark := '0xFFFFFFFF'; the value is the same as Broadcast Instance > address, > no worry of ambiguity here. > > The InsSelect is a TLV, whose structure is shown as: > > main hdr (eg type = config) > | > | > +-- T = LFBselect > | | > | +- LFBCLASSID = target LFB class > | | > | | > | +- T = InsSelect > | | | > | | V = InstanceID + > | | > | +- T = operation { ADD, DEL, GET, etc} > ... > > Best Regards, > Weiming > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 21:02:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18516 for ; Thu, 21 Oct 2004 21:02:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKo28-000845-Op for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:15:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlGX-0006aK-Kg; Thu, 21 Oct 2004 18:18:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjTr-0000JW-UV for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 16:24:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18618 for ; Thu, 21 Oct 2004 16:24:13 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjgX-0006Mx-Vw for forces-protocol@ietf.org; Thu, 21 Oct 2004 16:37:22 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9LKNRBF398952; Thu, 21 Oct 2004 16:23:27 -0400 Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9LKOmFD108466; Thu, 21 Oct 2004 16:24:48 -0400 Received: from [9.145.255.13] (sig-9-145-255-13.de.ibm.com [9.145.255.13]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA56660; Thu, 21 Oct 2004 22:23:13 +0200 Message-ID: <41781AA4.1020405@zurich.ibm.com> Date: Thu, 21 Oct 2004 22:23:00 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" Subject: Re: [Forces-protocol] Re: protocol draft editing? References: <468F3FDA28AA87429AD807992E22D07E02579200@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579200@orsmsx408> X-Spam-Score: 0.7 (/) X-Scan-Signature: b7b1e91f6d312d4248b994050b22d659 Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Weiming Wang X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1710171244==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 559439f19b20fd64c5cd872aef84c6f3 This is a multi-part message in MIME format. --===============1710171244== Content-Type: multipart/alternative; boundary="------------020809030002040302040906" This is a multi-part message in MIME format. --------------020809030002040302040906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e2.ny.us.ibm.com id i9LKNRBF398952 Content-Transfer-Encoding: quoted-printable Khosravi, Hormuzd M wrote: > Robert, > > =20 > > Weiming and myself are already working on this section...I will send=20 > out what I have shortly. > > Some of the changes are pretty straightforward, e.g. remove section 6.6= J > > =20 > > Anyways we could definitely use help in the draft, there is lots of=20 > stuff that needs to be done > You bet. I suppose I can help as a co-author of this draft ;-) > I will send out a list of other todo items shortly.. > > =20 > I'll start from your input tomorrow morning Europe time. Please take a=20 look at my previous note and review the pending issues I listed. This=20 way we avoid changing the text back and forth. Thanks, -Robert > regards > > Hormuzd > > =20 > > -----------------------------------------------------------------------= - > > From: Robert Haas [mailto:rha@zurich.ibm.com] > Sent: Thursday, October 21, 2004 7:04 AM > To: Khosravi, Hormuzd M > Cc: hadi@znyx.com; forces-protocol@ietf.org; avri@psg.com;=20 > ram.gopal@nokia.com; Ligang Dong; Weiming Wang > Subject: Re: [Forces-protocol] Re: protocol draft editing? > > =20 > > Hormuzd, > Section 6 is heavily impacted by the shift to "everything is an LFB".=20 > Many sections and figures require complete re-editing. To ensure=20 > consistency, we need one person to do one editing pass on the entire=20 > section first. But your list says "everybody". > > What if I do this first pass before tomorrow ? Or has anyone started=20 > already ? > > It also means that our description of the FE Protocol LFB must be=20 > enhanced, possibly including the multicast table that Zsolt started=20 > specifying. > > Regards, > -Robert > > Khosravi, Hormuzd M wrote: > >Here is the distribution list... > >=20 > >Abstract - Avri > >1. Introduction - Avri > >2. Definitions - Weiming > >3. Protocol Overview - Jamal > >4. TML Requirements - Jamal > >5. Common Header - Weiming, Ligang (Jamal/Robert) > >6. Protocol Messages - Hormuzd, Weiming (I expect everyone to be > >involved with this one) > >7. Protocol Scenarios - Hormuzd, Ram > >8. High Availability - Hormuzd > >9. Security Considerations - Ram > >10. References - Avri > >11. Acknowledgments - All > >Appendix > >A. Implementation Notes - All? > >=20 > >I will directly modify the text for my particular section and send it > >out to the team/Avri on a per section or per-subsection basis. That was > >we can all work in parallel. > >=20 > >regards > >Hormuzd=20 > >=20 > >-----Original Message----- > >From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 > >Sent: Wednesday, October 20, 2004 5:35 AM > >To: forces-protocol@ietf.org > >Cc: avri@psg.com ; Khosravi, Hormuzd M; ram.gopal@n= okia.com ; Ligang Dong; > >Weiming Wang; Robert Haas > >Subject: Re: [Forces-protocol] Re: protocol draft editing? > >=20 > >Avri must be on travel or tied up somewhere around the globe. > >The latest i could find is: > >http://psg.com/~avri/forces/draft/Archive-Forces-Protocol-02.zip > >=20 > >Does anyone know if theres something newer or should we start here? > >Hormuzd can you post that todo distribution? > >=20 > >cheers, > >jamal > >=20 > >On Tue, 2004-10-19 at 19:23, Jamal Hadi Salim wrote: > > =20 > >>On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote: >> >> =20 >> >>>Now that we seem to have made progress on the basics.. >>> >>>Avri, >>> >>>Could you post a URL to the xml docs that we could start editing? >>> >>>We could start with the TODO action items as posted by Hormuzd. >>> >>>=20 >>> >>>cheers, >>> >>>jamal >>> >>> =20 >>> >>=20 >> >>_______________________________________________ >> >>Forces-protocol mailing list >> >>Forces-protocol@ietf.org >> >>https://www1.ietf.org/mailman/listinfo/forces-protocol >> >> =20 >> >=20 > >=20 > >=20 > > =20 > > > >--=20 > >Robert Haas > >IBM Zurich Research Laboratory > >S=E4umerstrasse 4 > >CH-8803 R=FCschlikon/Switzerland > >phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha= > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------020809030002040302040906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Khosravi, Hormuzd M wrote:

Robert,

 

Weiming and myself are already working on this section…I will send out what I have shortly.

Some of the changes are pretty straightforward, e.g. remove section 6.6 J

 

Anyways we could definitely use help in the draft, there is lots of stuff that needs to be done

You bet. I suppose I can help as a co-author of this draft ;-)

I will send out a list of other todo items shortly..

 

I'll start from your input tomorrow morning Europe time. Please take a look at my previous note and review the pending issues I listed. This way we avoid changing the text back and forth.

Thanks,
-Robert

regards

Hormuzd

 

From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Thursday, October 21, 2004 7:04 AM
To: Khosravi, Hormuzd M
Cc: hadi@znyx.com; forces-protocol@ietf.org; avri@psg.com; ram.gopal@nokia.com; Ligang Dong; Weiming Wang
Subject: Re: [Forces-protocol] Re: protocol draft editing?

 

Hormuzd,
Section 6 is heavily impacted by the shift to "everything is an LFB". Many sections and figures require complete re-editing. To ensure consistency, we need one person to do one editing pass on the entire section first. But your list says "everybody".

What if I do this first pass before tomorrow ? Or has anyone started already ?

It also means that our description of the FE Protocol LFB must be enhanced, possibly including the multicast table that Zsolt started specifying.

Regards,
-Robert

Khosravi, Hormuzd M wrote:

Here is the distribution list...
 
Abstract - Avri
1. Introduction - Avri
2. Definitions - Weiming
3. Protocol Overview - Jamal
4. TML Requirements - Jamal
5. Common Header - Weiming, Ligang (Jamal/Robert)
6. Protocol Messages - Hormuzd, Weiming (I expect everyone to be
involved with this one)
7. Protocol Scenarios - Hormuzd, Ram
8. High Availability - Hormuzd
9. Security Considerations - Ram
10. References - Avri
11. Acknowledgments - All
Appendix
A. Implementation Notes - All?
 
I will directly modify the text for my particular section and send it
out to the team/Avri on a per section or per-subsection basis. That was
we can all work in parallel.
 
regards
Hormuzd 
 
-----Original Message-----
From: Jamal Hadi Salim [mailto:hadi@znyx.com] 
Sent: Wednesday, October 20, 2004 5:35 AM
To: forces-protocol@ietf.org
Cc: avri@psg.com; Khosravi, Hormuzd M; ram.gopal@nokia.com; Ligang Dong;
Weiming Wang; Robert Haas
Subject: Re: [Forces-protocol] Re: protocol draft editing?
 
Avri must be on travel or tied up somewhere around the globe.
The latest i could find is:
http://psg.com/~avri/forces/draft/Archive-Forces-Protocol-02.zip
 
Does anyone know if theres something newer or should we start here?
Hormuzd can you post that todo distribution?
 
cheers,
jamal
 
On Tue, 2004-10-19 at 19:23, Jamal Hadi Salim wrote:
  
On Tue, 2004-10-19 at 11:07, Jamal Hadi Salim wrote:
    
Now that we seem to have made progress on the basics..
Avri,
Could you post a URL to the xml docs that we could start editing?
We could start with the TODO action items as posted by Hormuzd.
 
cheers,
jamal
      
 
_______________________________________________
Forces-protocol mailing list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol
    
 
 
 
  



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

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------020809030002040302040906-- --===============1710171244== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1710171244==-- From forces-protocol-bounces@ietf.org Thu Oct 21 21:03:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18704 for ; Thu, 21 Oct 2004 21:03:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKo2p-00085n-Uo for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:16:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlHS-0007Ow-Rb; Thu, 21 Oct 2004 18:19:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjYK-0002lG-BN for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 16:28:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19802 for ; Thu, 21 Oct 2004 16:28:49 -0400 (EDT) Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjkz-0006kL-1h for forces-protocol@ietf.org; Thu, 21 Oct 2004 16:41:58 -0400 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.43) id 1CKjXV-00010Y-TW; Thu, 21 Oct 2004 16:28:01 -0400 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Steven Blake To: Robert Haas In-Reply-To: <41781915.1030401@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408> <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> <417573E8.7070502@zurich.ibm.com> <1098385216.2340.239.camel@localhost.localdomain> <41781915.1030401@zurich.ibm.com> Content-Type: text/plain Message-Id: <1098390473.2340.263.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 21 Oct 2004 16:27:53 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , Zsolt Haraszti , "Joel M. Halpern" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , "Wang, Weiming" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit On Thu, 2004-10-21 at 16:16, Robert Haas wrote: > Let me disuss this with a more detailed example. Suppose instances > LFBx1 and LFBx2 in FE x and LFBy1 in FE y must be configured with the > same values. > > With the "layer-breaking" model, the CE assigns a mcast ID m to which > FE x and FE y listen. FE x has a table with an entry (m, {LFBx1, > LFBx2}), and FE y an entry (m, {LFBy1}). > > With Zsolt's model, the CE assigns a mcast ID m to which FE x and FE y > listen. The CE also defines an MIID M. FE x has a table with an entry > (m) and FE y an entry (m) (basically, the groups those FEs belong to). > Then FE x has another table (M, {LFBx1, LFBx2}), and FE y (M, > {LFBy1}). Right. > I do agree that in your model, if you wanted to address another set of > LFBs, say LFBx3 in FE x and LFBy2 and LFBy3 in FE y, then the same > mcast id m could be used, and you would simply define another M'. The > tables would be in FE x (M', {LFBx3}) and in FE y (M',{LFBy2, LFBy3}). > > Now, even though we have way enough ~2^30 mcast IDs, I understand why > you favor your approach. Note that in the current draft, this was > stated as a possiblity (but instead of specifying a -virtualID-, I > wrote VPN ID, quite the same idea). > > Do you think we should explicitely forbid the "layer-breaking" option, > or could we use both ? Yes. I consider it analogous to mixing IP addresses and ports. It requires a special case in the message parser, and it just doesn't look clean. Note that I don't see much use in needing to map a single LFB instance ID (MIID) to multiple instance IDs on a single ID; i.e., I don't see the need for multicast within the FE. What is really needed is a CE-assigned LFB instance ID alias that can be used on many FEs to allow coordination of multicast table updates. Regards, // Steve _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 21:13:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20127 for ; Thu, 21 Oct 2004 21:13:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoCg-0008QG-C5 for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:26:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlJB-0001Ay-Gg; Thu, 21 Oct 2004 18:21:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjms-0002E6-8a for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 16:43:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22798 for ; Thu, 21 Oct 2004 16:43:51 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.104]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjzY-0007lW-PP for forces-protocol@ietf.org; Thu, 21 Oct 2004 16:57:01 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9LKhDCE632992; Thu, 21 Oct 2004 16:43:13 -0400 Received: from sihl.zurich.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9LKiBS8124016; Thu, 21 Oct 2004 16:44:12 -0400 Received: from [9.145.255.13] (sig-9-145-255-13.de.ibm.com [9.145.255.13]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA55106; Thu, 21 Oct 2004 22:42:50 +0200 Message-ID: <41781F3D.304@zurich.ibm.com> Date: Thu, 21 Oct 2004 22:42:37 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steven Blake Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408> <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> <417573E8.7070502@zurich.ibm.com> <1098385216.2340.239.camel@localhost.localdomain> <41781915.1030401@zurich.ibm.com> <1098390473.2340.263.camel@localhost.localdomain> In-Reply-To: <1098390473.2340.263.camel@localhost.localdomain> X-Spam-Score: 0.5 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , Zsolt Haraszti , "Joel M. Halpern" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , "Wang, Weiming" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1993978357==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 This is a multi-part message in MIME format. --===============1993978357== Content-Type: multipart/alternative; boundary="------------010408060805030205090209" This is a multi-part message in MIME format. --------------010408060805030205090209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id i9LKhDCE632992 Content-Transfer-Encoding: quoted-printable Steven Blake wrote: >>Do you think we should explicitely forbid the "layer-breaking" option, >>or could we use both ? >> =20 >> > >Yes. I consider it analogous to mixing IP addresses and ports. It >requires a special case in the message parser, and it just doesn't look >clean. > > =20 > As we don't mix layers, you could have the following scenario: MIID M=20 "contains" LFBx1, LFBy1, LFBz1 (on FEs x, y, z). But mcast ID m only spans FE x and FE y. So a PL message addressed to mcast ID m, and MIID M, would only act on=20 LFBx1 and LFBy1. Or do you want to require that messages to MIID m MUST go to a mcastID=20 (m or sth else) that spans at least FEs x and y ? This would be a layer=20 violation too, no ? >Note that I don't see much use in needing to map a single LFB instance >ID (MIID) to multiple instance IDs on a single ID; i.e., I don't see the >need for multicast within the FE. What is really needed is a >CE-assigned LFB instance ID alias that can be used on many FEs to allow >coordination of multicast table updates. > > =20 > I agree, but Zsolt example, if I recall well, included some level of=20 intra-LFB multicasting. Regards, --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------010408060805030205090209 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Steven Blake wrote:
Do you think we should explicitely forbid the "layer-breaking" option,
or could we use both ?
    

Yes.  I consider it analogous to mixing IP addresses and ports.  It
requires a special case in the message parser, and it just doesn't look
clean.

As we don't mix layers, you could have the following scenario: MIID M "contains" LFBx1, LFBy1, LFBz1 (on FEs x, y, z).
But mcast ID m only spans FE x and FE y.

So a PL message addressed to mcast ID m, and MIID M, would only act on LFBx1 and LFBy1.

Or do you want to require that messages to MIID m MUST go to a mcastID (m or sth else) that spans at least FEs x and y ? This would be a layer violation too, no ?


Note that I don't see much use in needing to map a single LFB instance
ID (MIID) to multiple instance IDs on a single ID; i.e., I don't see the
need for multicast within the FE.  What is really needed is a
CE-assigned LFB instance ID alias that can be used on many FEs to allow
coordination of multicast table updates.
I agree, but Zsolt example, if I recall well, included some level of intra-LFB multicasting.

Regards,
-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------010408060805030205090209-- --===============1993978357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1993978357==-- From forces-protocol-bounces@ietf.org Thu Oct 21 21:14:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20264 for ; Thu, 21 Oct 2004 21:14:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoDS-0008SL-HT for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:27:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlMQ-0004by-Ro; Thu, 21 Oct 2004 18:24:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjrU-0003i1-0V for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 16:48:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23332 for ; Thu, 21 Oct 2004 16:48:37 -0400 (EDT) Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKk49-0007xn-H4 for forces-protocol@ietf.org; Thu, 21 Oct 2004 17:01:46 -0400 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.43) id 1CKjqh-0004jj-7p; Thu, 21 Oct 2004 16:47:51 -0400 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Steven Blake To: Robert Haas In-Reply-To: <41781915.1030401@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408> <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> <417573E8.7070502@zurich.ibm.com> <1098385216.2340.239.camel@localhost.localdomain> <41781915.1030401@zurich.ibm.com> Content-Type: text/plain Message-Id: <1098391662.2340.276.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 21 Oct 2004 16:47:42 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , Zsolt Haraszti , "Joel M. Halpern" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , "Wang, Weiming" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit On Thu, 2004-10-21 at 16:27, Steven Blake wrote: > Note that I don't see much use in needing to map a single LFB instance > ID (MIID) to multiple instance IDs on a single ID; i.e., I don't see the ^FE BTW, Wieming's address always bounces when I respond to these threads. // Steve _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 21:16:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20652 for ; Thu, 21 Oct 2004 21:16:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoF4-00005F-Ob for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:29:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlS1-0000jm-Is; Thu, 21 Oct 2004 18:30:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKk1j-0008DO-7b for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 16:59:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25397 for ; Thu, 21 Oct 2004 16:59:12 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKkEP-00009t-Oy for forces-protocol@ietf.org; Thu, 21 Oct 2004 17:12:22 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9LKw1w9027201; Thu, 21 Oct 2004 20:58:01 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9LKoiQG030698; Thu, 21 Oct 2004 20:51:56 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102113581514637 ; Thu, 21 Oct 2004 13:58:15 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 13:58:14 -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 Date: Thu, 21 Oct 2004 13:58:13 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02F99EC4@orsmsx408> Thread-Topic: Instance Select Thread-Index: AcS3qzh4z9sL5ur3Q+G9g6ocPFQXdQABTOyQ From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 21 Oct 2004 20:58:14.0839 (UTC) FILETIME=[AED2BC70:01C4B7B0] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, "Wang, Weiming" , "Joel M. Halpern" , "Steven \"Blake \(petri-meat\)" , forces-protocol@ietf.org, Alan DeKok , zsolt@nc.rr.com, "Yang, Lily L" , "Deleganes, Ellen M" Subject: [Forces-protocol] RE: Instance Select X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Sounds good to me...we can leave a Editorial note in saying that this issue needs further discussion. In the mean time, can should continue discussion even on this mailing list and I will be happy to arrange a conference call before the IETF, if that is needed/requested. regards Hormuzd=20 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Thursday, October 21, 2004 1:19 PM To: Khosravi, Hormuzd M Cc: Wang,Weiming; forces-protocol@ietf.org; Joel M. Halpern; ram.gopal@nokia.com; Yang, Lily L; Alan DeKok; zsolt@nc.rr.com; Steven "Blake (petri-meat); Deleganes, Ellen M Subject: RE: Instance Select My opinion is this issue should be defered for this release of the protocol draft.=20 If Weiming can be given a slot to present on the topic (I will also provide him with my data) then lets discuss at the meeting. If not a presentation then maybe over a meal and some good caffeine. cheers, jamal On Thu, 2004-10-21 at 15:58, Khosravi, Hormuzd M wrote: > Weiming, >=20 > I haven't seen any compelling example (real NE) to need this kind of > functionality in the protocol. > Therefore, I don't think this complexity needs to be added...at most we > need a Broadcast Instance ID definition (Send msgs to all LFBs of a > particular Type). But I will be happy to hear what Jamal, others have to > say on this ? I am not religious either way... >=20 >=20 > regards > Hormuzd=20 >=20 > -----Original Message----- > From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn]=20 > Sent: Wednesday, October 20, 2004 9:48 PM > To: forces-protocol@ietf.org > Cc: Khosravi, Hormuzd M; hadi@znyx.com; Joel M. Halpern; > ram.gopal@nokia.com; Yang, Lily L; Alan DeKok; zsolt@nc.rr.com; Steven > Blake (petri-meat); Deleganes, Ellen M > Subject: Instance Select >=20 > Hi Jamal, Hormuzd, etc, >=20 > To summarize the discussions on multiple instances, I try to propose > following > scheme for instance selection, which follows Robert's idea and Jamal's > format, > as: >=20 > PL level PDU : =3D MAINHDR+ > LFBselect :=3D LFBCLASSID InsSelect + > InsSelect :=3D InstanceID + > RangeMark :=3D '0xFFFFFFFF'; the value is the same as Broadcast = Instance > address, > no worry of ambiguity here. >=20 > The InsSelect is a TLV, whose structure is shown as: >=20 > main hdr (eg type =3D config) > | > | > +-- T =3D LFBselect > | | > | +- LFBCLASSID =3D target LFB class > | | > | | > | +- T =3D InsSelect > | | | > | | V =3D InstanceID + > | | > | +- T =3D operation { ADD, DEL, GET, etc} > ... >=20 > Best Regards, > Weiming >=20 >=20 >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 21:19:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21368 for ; Thu, 21 Oct 2004 21:19:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoIi-0000DY-Sl for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:33:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlUZ-0005Gc-54; Thu, 21 Oct 2004 18:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKkPw-0001at-Oc for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 17:24:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01415 for ; Thu, 21 Oct 2004 17:24:13 -0400 (EDT) Received: from server26.totalchoicehosting.com ([209.152.177.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKkcc-00023h-Ow for forces-protocol@ietf.org; Thu, 21 Oct 2004 17:37:23 -0400 Received: from [204.85.2.252] (helo=[192.168.168.85]) by server26.totalchoicehosting.com with esmtp (Exim 4.43) id 1CKkP6-0000bo-9C; Thu, 21 Oct 2004 17:23:24 -0400 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Steven Blake To: Robert Haas In-Reply-To: <41781F3D.304@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408> <04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn> <417573E8.7070502@zurich.ibm.com> <1098385216.2340.239.camel@localhost.localdomain> <41781915.1030401@zurich.ibm.com> <1098390473.2340.263.camel@localhost.localdomain> <41781F3D.304@zurich.ibm.com> Content-Type: text/plain Message-Id: <1098393795.2340.287.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 21 Oct 2004 17:23:15 -0400 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server26.totalchoicehosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , Zsolt Haraszti , "Joel M. Halpern" , forces-protocol@ietf.org, hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , "Wang, Weiming" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit On Thu, 2004-10-21 at 16:42, Robert Haas wrote: > Steven Blake wrote: > > > Do you think we should explicitely forbid the "layer-breaking" option, > > > or could we use both ? > > > > > Yes. I consider it analogous to mixing IP addresses and ports. It > > requires a special case in the message parser, and it just doesn't look > > clean. > > > > > > As we don't mix layers, you could have the following scenario: MIID M > "contains" LFBx1, LFBy1, LFBz1 (on FEs x, y, z). I would rephrase it differently. MIID M could be configured individually on FEs x/y/z by the CE to alias to LFBx1, LFBy1, and LFBz1. > But mcast ID m only spans FE x and FE y. > So a PL message addressed to mcast ID m, and MIID M, would only act on > LFBx1 and LFBy1. Right. > Or do you want to require that messages to MIID m MUST go to a mcastID > (m or sth else) that spans at least FEs x and y ? This would be a > layer violation too, no ? I don't see any reason to require it in the protocol, but I also don't see much reason to use it any other way. > > Note that I don't see much use in needing to map a single LFB instance > > ID (MIID) to multiple instance IDs on a single ID; i.e., I don't see the > > need for multicast within the FE. What is really needed is a > > CE-assigned LFB instance ID alias that can be used on many FEs to allow > > coordination of multicast table updates. > > > > > I agree, but Zsolt example, if I recall well, included some level of > intra-LFB multicasting. I think it did. I still don't think it is very useful, since I think there is a better alternative for intra-FE/inter-LFB state sharing, but it doesn't cost much to support it either. Regards, // Steve _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 21:21:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21886 for ; Thu, 21 Oct 2004 21:21:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoKM-0000K1-Uy for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:34:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlWD-0001v5-9K; Thu, 21 Oct 2004 18:34:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKkj6-0006r1-10 for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 17:44:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05978 for ; Thu, 21 Oct 2004 17:44:00 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKkvm-0003IQ-QW for forces-protocol@ietf.org; Thu, 21 Oct 2004 17:57:11 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9LLh7w9016991; Thu, 21 Oct 2004 21:43:07 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9LLaxPg030196; Thu, 21 Oct 2004 21:37:12 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102114432823391 ; Thu, 21 Oct 2004 14:43:28 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 14:43:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Forces-protocol] Re: protocol draft editing? Date: Thu, 21 Oct 2004 14:43:27 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02F9A021@orsmsx408> Thread-Topic: [Forces-protocol] Re: protocol draft editing? Thread-Index: AcS3q9cPrTQ5MVRfRXyeu2oS5YmMGQABn0XQ From: "Khosravi, Hormuzd M" To: "Robert Haas" X-OriginalArrivalTime: 21 Oct 2004 21:43:28.0605 (UTC) FILETIME=[005A90D0:01C4B7B7] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.8 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Weiming Wang X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0227215301==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 This is a multi-part message in MIME format. --===============0227215301== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B7B6.FFEE223A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B7B6.FFEE223A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Robert (co-author :)), All =20 Here is a list of major todos... =20 Header Section - Jamal/Robert/Weiming? Protocol LFB - Robert/Others? FE LFB - Robert/Others? State Machine for Protocol - ?? Messages Section - working (Hormuzd, Weiming) HA Section - done (Hormuzd) Protocol Scenarios - Ram/H =20 Minor todos... Security section - any updates needed Ram ? Updates to Overview (Furquan had sent comments regarding inconsistencies) -done Jamal ? =20 =20 I think if we get all this done before the deadline, it will be a big accomplishment! =20 regards Hormuzd p.s. Robert, I will respond to your previous note in my next email, it mostly looked fine I think... =20 ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Robert, =20 Weiming and myself are already working on this section...I will send out what I have shortly. Some of the changes are pretty straightforward, e.g. remove section 6.6 :-) =20 Anyways we could definitely use help in the draft, there is lots of stuff that needs to be done You bet. I suppose I can help as a co-author of this draft ;-) I will send out a list of other todo items shortly.. =20 I'll start from your input tomorrow morning Europe time. Please take a look at my previous note and review the pending issues I listed. This way we avoid changing the text back and forth. Thanks, -Robert =20 ------_=_NextPart_001_01C4B7B6.FFEE223A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Robert (co-author :)), = All
 
Here is a list of major = todos...
 
Header Section - = Jamal/Robert/Weiming?
Protocol LFB - = Robert/Others?
FE LFB - Robert/Others?
State Machine for Protocol - ??
Messages Section = - working (Hormuzd,=20 Weiming)
HA Section - done = (Hormuzd)
Protocol Scenarios - Ram/H
 
Minor=20 todos...
Security section - any updates needed Ram ?
Updates to Overview (Furquan had sent comments regarding = inconsistencies)=20 -done Jamal ?
 
 
I=20 think if we get all this done before the deadline, it will be a big=20 accomplishment!
 
regards
Hormuzd
p.s.=20 Robert, I will respond to your previous note in my next email, it mostly = looked=20 fine I think...
 
From: Robert Haas = [mailto:rha@zurich.ibm.com]=20

Robert,

 

Weiming and = myself=20 are already working on this section…I will send out what I have=20 shortly.

Some of the = changes=20 are pretty straightforward, e.g. remove section 6.6 = J

 

Anyways we = could=20 definitely use help in the draft, there is lots of stuff that needs to = be=20 done

You bet. I suppose I can help = as a=20 co-author of this draft ;-)

I will send = out a=20 list of other todo items shortly..

 

I'll=20 start from your input tomorrow morning Europe time. Please take a look = at my=20 previous note and review the pending issues I listed. This way we avoid = changing=20 the text back and forth.

Thanks,
-Robert
 
------_=_NextPart_001_01C4B7B6.FFEE223A-- --===============0227215301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0227215301==-- From forces-protocol-bounces@ietf.org Thu Oct 21 21:22:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22077 for ; Thu, 21 Oct 2004 21:22:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoKp-0000Lp-HD for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:35:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlWM-0002Ev-Ps; Thu, 21 Oct 2004 18:34:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKkk3-0007Vk-SI for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 17:45:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06113 for ; Thu, 21 Oct 2004 17:45:00 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKkwj-0003Kd-Pt for forces-protocol@ietf.org; Thu, 21 Oct 2004 17:58:11 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9LLi6w9017398; Thu, 21 Oct 2004 21:44:06 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9LLlTYr007257; Thu, 21 Oct 2004 21:48:03 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102114442530537 ; Thu, 21 Oct 2004 14:44:25 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 14:44:25 -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 Subject: RE: [Forces-protocol] Re: protocol draft editing? Date: Thu, 21 Oct 2004 14:44:24 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02F9A026@orsmsx408> Thread-Topic: [Forces-protocol] Re: protocol draft editing? Thread-Index: AcS3qtii9vXRNEFHTMaB+7E4kn9n6wADCsww From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 21 Oct 2004 21:44:25.0479 (UTC) FILETIME=[2240D970:01C4B7B7] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Jamal,=20 Pls go ahead...it would be great if you present the protocol. Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 BTW, folks I would like to volunteer to present on the protocol this time if people are OK with it. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 21:23:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22489 for ; Thu, 21 Oct 2004 21:23:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoLr-0000Po-8M for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 21:36:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlY5-0003oJ-4J; Thu, 21 Oct 2004 18:36:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKkxa-000744-MS for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 17:59:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08315 for ; Thu, 21 Oct 2004 17:58:59 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKlAH-00041w-MB for forces-protocol@ietf.org; Thu, 21 Oct 2004 18:12:10 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9LLw2w9024105; Thu, 21 Oct 2004 21:58:02 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9LLxXaD014581; Thu, 21 Oct 2004 22:02:03 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102114582400107 ; Thu, 21 Oct 2004 14:58:24 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 14:58:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Oct 2004 14:58:22 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02F9A085@orsmsx408> Thread-Topic: Applying changes to Section 6 (Protocol Messages) Thread-Index: AcS3lVu6a9cPoTO1QU+4Qj8Fo+dmYQAIj23A From: "Khosravi, Hormuzd M" To: "Robert Haas" , "Ligang Dong" , , , , "Weiming Wang" X-OriginalArrivalTime: 21 Oct 2004 21:58:24.0635 (UTC) FILETIME=[166DE4B0:01C4B7B9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 1.5 (+) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: forces-protocol@ietf.org Subject: [Forces-protocol] RE: Applying changes to Section 6 (Protocol Messages) X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1749309559==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 This is a multi-part message in MIME format. --===============1749309559== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B7B9.15A1BF10" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B7B9.15A1BF10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert, =20 As I said, your note mostly looks...I have put some more comments below... (It would help a lot if you start defining the FE, Protocol LFBs...) ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 All: below is a rough list of changes and pending issues regarding section 6. Please review. 6.1.1 Association: The CE could obtain the HBI with a Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg strcutrue, we have to remove HBI from the Assoc Setup msg. [Agreed, this would be part of ProtocolLFB even if it is in this message]=20 6.1.2 How has the srcID=3D0 case been handled in the interop tests ? Is this really feasible ? [Yes it worked fine during Interop]=20 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into the FEProtocolLFB. [Agreed it would be in some LFB, but not sure which LFB this would be part of...?]=20 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note that for the sake of symmetry, we should introduce a CEProtocolLFB. [Sure, why dont you start defining some of these objects...then we can discuss more in detail]=20 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become settable attributes in the FEProtocolLFB. [Yes, these messages will be part of Events or Config...we need to specify this]=20 6.7 HB remains as is. [Agreed]=20 In summary, we have the following operations defined for each message type ( I broke the table into 3 parts): [looks good!]=20 OPERATION APPLICABLE MESSAGE TYPES Assoc-Setup Assoc-Setup-Resp Assoc-Teardown Heartbeat no operations defined Query Query-Resp Config Config-Resp SET, DEL, UPDATE x x GET x x EV_S, EV_U x x (for event subscribe/unsubscribe) Packet-Redir PAYLOAD x Event-Notif Event-Notif-Resp EVENT x x Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we have each time only one operation. Looks a bit redundant. Ideas ? [These are all very different, lets leave them as is, its not necessary to have multiple operations in all messages]=20 Regards, -Robert ------_=_NextPart_001_01C4B7B9.15A1BF10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Robert,
 
As I said, your note mostly looks...I have put = some more=20 comments below...
(It would help a lot if you s= tart defining the FE, Protocol LFBs...)
From: Robert Haas = [mailto:rha@zurich.ibm.com]=20

All: below is a rough list of changes and pending = issues=20 regarding section 6. Please review.

 6.1.1 Association: The = CE could=20 obtain the HBI with a Query-SGT-FEProtocolLFP-HeartbeatInterval. Given = the new=20 Assoc msg strcutrue, we have to remove HBI from the Assoc Setup = msg.  [Agreed,=20 this would be part of ProtocolLFB even if it is in this=20 message] 

 6.1.2 How has the srcID=3D0 = case been=20 handled in the interop tests ? Is this really feasible ?  [Yes it=20 worked fine during Interop] 

 6.2 Query: = coarse=20 FE info (inter/intra-FE topology, etc) goes into the FEProtocolLFB.  [Agreed it=20 would be in some LFB, but not sure which LFB this would be part=20 of...?] 

 6.4: Events: coarse CE and FE = events go=20 into CE/FEProtocolLFB. Note that for the sake of symmetry, we should = introduce a=20 CEProtocolLFB.  [Sure, why dont you start defining some of these = objects...then we=20 can discuss more in detail] 

 6.6 State=20 Maintenance: FE Activate/Deactivate/Shutdown become settable attributes = in the=20 FEProtocolLFB.  [Yes, these messages will be part of Events or = Config...we=20 need to specify this] 

 6.7 HB remains as = is. =20 [Agreed] 

In summary, we have the following = operations=20 defined for each message type ( I broke the table into 3 = parts):
 [looks=20 good!] 
OPERATION     &nbs= p;=20 APPLICABLE MESSAGE TYPES

       =   =20       Assoc-Setup  Assoc-Setup-Resp = Assoc-Teardown=20 Heartbeat

no operations
defined


   =20             Query  = Query-Resp =20 Config  Config-Resp
SET, DEL, UPDATE=20             &= nbsp;   =20    x         =20 x
GET           = ;   =20 x         x
EV_S, EV_U=20             &= nbsp;       =20      = x         =20 x

(for event subscribe/unsubscribe)


    =            =20 Packet-Redir

PAYLOAD       &nbs= p;   =20 x


           =20     Event-Notif  Event-Notif-Resp
EVENT =  =20           =20 x            =    =20 x

Note that for Query(-Resp), Packet-Redir, and = Event-Notif(-Resp),=20 we have each time only one operation. Looks a bit redundant. Ideas = ?  [These are=20 all very different, lets leave them as is, its not necessary to have = multiple=20 operations in all=20 messages] 

Regards,
-Robert
------_=_NextPart_001_01C4B7B9.15A1BF10-- --===============1749309559== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1749309559==-- From forces-protocol-bounces@ietf.org Thu Oct 21 21:53:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28144 for ; Thu, 21 Oct 2004 21:53:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKopM-00021l-VR for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 22:06:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoGr-00017c-NN; Thu, 21 Oct 2004 21:31:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKmxS-0000UN-A8 for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 20:07:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07378 for ; Thu, 21 Oct 2004 20:07:00 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnAA-0004Uz-63 for forces-protocol@ietf.org; Thu, 21 Oct 2004 20:20:10 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9LNgkep025587; Fri, 22 Oct 2004 01:42:47 +0200 In-Reply-To: <1098389749.1029.136.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02579200@orsmsx408> <1098389749.1029.136.camel@jzny.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48103EA9-23BE-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Re: protocol draft editing? Date: Thu, 21 Oct 2004 20:06:54 -0400 To: Jamal Hadi Salim X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit On 21 okt 2004, at 16.15, Jamal Hadi Salim wrote: > Avri, > > Are you compiling all the changes? i can. i have not started yet. > For this iteration of the draft I will leave the TML section alone. > The only change i am making on the overview is attached as a diff. > Avri, if you cant handle diffs i will send you the xml. i can handle the diffs. although monday, the deadline is real soon. > Robert,Weiming, Ligang: Are you taking care of the common header > section > or should i jump into that next? Not that i think there are any useful > changes tomake for this version of draft. > > BTW, folks I would like to volunteer to present on the protocol this > time if people are OK with it. fine with me. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 22:49:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04087 for ; Thu, 21 Oct 2004 22:49:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKph2-0003OO-FP for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 23:02:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKpAy-0001Vk-Rf; Thu, 21 Oct 2004 22:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKp1E-0001RT-Jb for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 22:19:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01535 for ; Thu, 21 Oct 2004 22:19:01 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKpDu-0002r9-NX for forces-protocol@ietf.org; Thu, 21 Oct 2004 22:32:13 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CKp19-0000hn-E8 for forces-protocol@ietf.org; Thu, 21 Oct 2004 22:18:59 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Fri, 22 Oct 2004 10:38:21 +0800 (CST) Received: from dlg (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with SMTP id ; Fri, 22 Oct 2004 10:14:45 +0800 Message-ID: <005a01c4b7dd$35248de0$8401a8c0@dlg> From: "Ligang Dong" To: "Khosravi, Hormuzd M" , "Robert Haas" References: <468F3FDA28AA87429AD807992E22D07E02F9A021@orsmsx408> Subject: Re: [Forces-protocol] Re: protocol draft editing? Date: Fri, 22 Oct 2004 10:16:57 +0800 MIME-Version: 1.0 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 X-Spam-Score: 3.6 (+++) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: hadi@znyx.com, avri@psg.com, ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0331706627==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 3.6 (+++) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 This is a multi-part message in MIME format. --===============0331706627== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0057_01C4B820.43300020" This is a multi-part message in MIME format. ------=_NextPart_000_0057_01C4B820.43300020 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 aGksIA0KSSBjYW4gZWRpdCB0aGUgInN0YXRlIG1hY2hpbmUgZm9yIHByb3RvY29sIi4NCmxpZ2Fu Zw0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBLaG9zcmF2aSwgSG9y bXV6ZCBNIA0KICBUbzogUm9iZXJ0IEhhYXMgDQogIENjOiByYW0uZ29wYWxAbm9raWEuY29tIDsg TGlnYW5nIERvbmcgOyBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcgOyBhdnJpQHBzZy5jb20gOyBo YWRpQHpueXguY29tIDsgV2VpbWluZyBXYW5nIA0KICBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIs IDIwMDQgNTo0MyBBTQ0KICBTdWJqZWN0OiBSRTogW0ZvcmNlcy1wcm90b2NvbF0gUmU6IHByb3Rv Y29sIGRyYWZ0IGVkaXRpbmc/DQoNCg0KICBEZWFyIFJvYmVydCAoY28tYXV0aG9yIDopKSwgQWxs DQoNCiAgSGVyZSBpcyBhIGxpc3Qgb2YgbWFqb3IgdG9kb3MuLi4NCg0KICBIZWFkZXIgU2VjdGlv biAtIEphbWFsL1JvYmVydC9XZWltaW5nPw0KICBQcm90b2NvbCBMRkIgLSBSb2JlcnQvT3RoZXJz Pw0KICBGRSBMRkIgLSBSb2JlcnQvT3RoZXJzPw0KICBTdGF0ZSBNYWNoaW5lIGZvciBQcm90b2Nv bCAtID8/DQogIE1lc3NhZ2VzIFNlY3Rpb24gLSB3b3JraW5nIChIb3JtdXpkLCBXZWltaW5nKQ0K ICBIQSBTZWN0aW9uIC0gZG9uZSAoSG9ybXV6ZCkNCiAgUHJvdG9jb2wgU2NlbmFyaW9zIC0gUmFt L0gNCg0KICBNaW5vciB0b2Rvcy4uLg0KICBTZWN1cml0eSBzZWN0aW9uIC0gYW55IHVwZGF0ZXMg bmVlZGVkIFJhbSA/DQogIFVwZGF0ZXMgdG8gT3ZlcnZpZXcgKEZ1cnF1YW4gaGFkIHNlbnQgY29t bWVudHMgcmVnYXJkaW5nIGluY29uc2lzdGVuY2llcykgLWRvbmUgSmFtYWwgPw0KDQoNCiAgSSB0 aGluayBpZiB3ZSBnZXQgYWxsIHRoaXMgZG9uZSBiZWZvcmUgdGhlIGRlYWRsaW5lLCBpdCB3aWxs IGJlIGEgYmlnIGFjY29tcGxpc2htZW50IQ0KDQogIHJlZ2FyZHMNCiAgSG9ybXV6ZA0KICBwLnMu IFJvYmVydCwgSSB3aWxsIHJlc3BvbmQgdG8geW91ciBwcmV2aW91cyBub3RlIGluIG15IG5leHQg ZW1haWwsIGl0IG1vc3RseSBsb29rZWQgZmluZSBJIHRoaW5rLi4uDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQogIEZyb206IFJvYmVydCBIYWFzIFttYWlsdG86cmhhQHp1cmljaC5pYm0uY29t XSANCg0KICAgIFJvYmVydCwNCg0KDQoNCiAgICBXZWltaW5nIGFuZCBteXNlbGYgYXJlIGFscmVh ZHkgd29ya2luZyBvbiB0aGlzIHNlY3Rpb24uSSB3aWxsIHNlbmQgb3V0IHdoYXQgSSBoYXZlIHNo b3J0bHkuDQoNCiAgICBTb21lIG9mIHRoZSBjaGFuZ2VzIGFyZSBwcmV0dHkgc3RyYWlnaHRmb3J3 YXJkLCBlLmcuIHJlbW92ZSBzZWN0aW9uIDYuNiBKDQoNCg0KDQogICAgQW55d2F5cyB3ZSBjb3Vs ZCBkZWZpbml0ZWx5IHVzZSBoZWxwIGluIHRoZSBkcmFmdCwgdGhlcmUgaXMgbG90cyBvZiBzdHVm ZiB0aGF0IG5lZWRzIHRvIGJlIGRvbmUNCg0KICBZb3UgYmV0LiBJIHN1cHBvc2UgSSBjYW4gaGVs cCBhcyBhIGNvLWF1dGhvciBvZiB0aGlzIGRyYWZ0IDstKQ0KDQogICAgSSB3aWxsIHNlbmQgb3V0 IGEgbGlzdCBvZiBvdGhlciB0b2RvIGl0ZW1zIHNob3J0bHkuLg0KDQoNCg0KICBJJ2xsIHN0YXJ0 IGZyb20geW91ciBpbnB1dCB0b21vcnJvdyBtb3JuaW5nIEV1cm9wZSB0aW1lLiBQbGVhc2UgdGFr ZSBhIGxvb2sgYXQgbXkgcHJldmlvdXMgbm90ZSBhbmQgcmV2aWV3IHRoZSBwZW5kaW5nIGlzc3Vl cyBJIGxpc3RlZC4gVGhpcyB3YXkgd2UgYXZvaWQgY2hhbmdpbmcgdGhlIHRleHQgYmFjayBhbmQg Zm9ydGguDQoNCiAgVGhhbmtzLA0KICAtUm9iZXJ0DQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQoNCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgRm9yY2VzLXByb3RvY29sIG1haWxpbmcgbGlzdA0KICBGb3JjZXMtcHJvdG9jb2xAaWV0 Zi5vcmcNCiAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzLXBy b3RvY29sDQo= ------=_NextPart_000_0057_01C4B820.43300020 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEg Y29udGVudD0iTVNIVE1MIDYuMDAuMjgwMC4xMTA2IiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8 Qk9EWSB0ZXh0PSMwMDAwMDAgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBzaXplPTI+aGks IDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgY2FuIGVkaXQgdGhlICJzdGF0ZSBt YWNoaW5lIGZvciBwcm90b2NvbCIuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+bGln YW5nPC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4 OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAw MDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlw dCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0K ICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIw MzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9aG9ybXV6 ZC5tLmtob3NyYXZpQGludGVsLmNvbSANCiAgaHJlZj0ibWFpbHRvOmhvcm11emQubS5raG9zcmF2 aUBpbnRlbC5jb20iPktob3NyYXZpLCBIb3JtdXpkIE08L0E+IDwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1yaGFAenVy aWNoLmlibS5jb20gDQogIGhyZWY9Im1haWx0bzpyaGFAenVyaWNoLmlibS5jb20iPlJvYmVydCBI YWFzPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsi PjxCPkNjOjwvQj4gPEEgdGl0bGU9cmFtLmdvcGFsQG5va2lhLmNvbSANCiAgaHJlZj0ibWFpbHRv OnJhbS5nb3BhbEBub2tpYS5jb20iPnJhbS5nb3BhbEBub2tpYS5jb208L0E+IDsgPEEgDQogIHRp dGxlPWRvbmdsZ0BtYWlsLmh6aWMuZWR1LmNuIGhyZWY9Im1haWx0bzpkb25nbGdAbWFpbC5oemlj LmVkdS5jbiI+TGlnYW5nIA0KICBEb25nPC9BPiA7IDxBIHRpdGxlPWZvcmNlcy1wcm90b2NvbEBp ZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyI+Zm9yY2Vz LXByb3RvY29sQGlldGYub3JnPC9BPiA7IDxBIA0KICB0aXRsZT1hdnJpQHBzZy5jb20gaHJlZj0i bWFpbHRvOmF2cmlAcHNnLmNvbSI+YXZyaUBwc2cuY29tPC9BPiA7IDxBIA0KICB0aXRsZT1oYWRp QHpueXguY29tIGhyZWY9Im1haWx0bzpoYWRpQHpueXguY29tIj5oYWRpQHpueXguY29tPC9BPiA7 IDxBIA0KICB0aXRsZT13bXdhbmdAbWFpbC5oemljLmVkdS5jbiBocmVmPSJtYWlsdG86d213YW5n QG1haWwuaHppYy5lZHUuY24iPldlaW1pbmcgDQogIFdhbmc8L0E+IDwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IEZyaWRheSwgT2N0 b2JlciAyMiwgMjAwNCA1OjQzIEFNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIz NDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUkU6IFtGb3JjZXMtcHJvdG9jb2xdIFJlOiBw cm90b2NvbCANCiAgZHJhZnQgZWRpdGluZz88L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxE SVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTcxMDAxMTAyMS0yMTEwMjAwND48Rk9O VCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5EZWFyIFJvYmVydCAoY28tYXV0 aG9yIDopKSwgQWxsPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9NzEwMDExMDIxLTIxMTAyMDA0PjxGT05UIGZhY2U9QXJpYWwgDQogIGNv bG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQogIDxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTcxMDAxMTAyMS0yMTEwMjAwND48Rk9OVCBmYWNl PUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5IZXJlIGlzIGEgbGlzdCBvZiBtYWpvciB0 b2Rvcy4uLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxT UEFOIGNsYXNzPTcxMDAxMTAyMS0yMTEwMjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0j MDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWIGRpcj1sdHIg YWxpZ249bGVmdD48U1BBTiBjbGFzcz03MTAwMTEwMjEtMjExMDIwMDQ+PEZPTlQgZmFjZT1Bcmlh bCANCiAgY29sb3I9IzAwMDBmZiBzaXplPTI+SGVhZGVyIFNlY3Rpb24gLSANCkphbWFsL1JvYmVy dC9XZWltaW5nPzwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0 PjxTUEFOIGNsYXNzPTcxMDAxMTAyMS0yMTEwMjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xv cj0jMDAwMGZmIHNpemU9Mj5Qcm90b2NvbCBMRkIgLSBSb2JlcnQvT3RoZXJzPzwvRk9OVD48L1NQ QU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTcxMDAxMTAy MS0yMTEwMjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5GRSBM RkIgLSBSb2JlcnQvT3RoZXJzPzwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xh c3M9NzEwMDExMDIxLTIxMTAyMDA0PjwvU1BBTj48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIA0KICBj b2xvcj0jMDAwMGZmPjxGT05UIA0KICBzaXplPTI+U3RhdGUmbmJzcDtNYWNoaW5lJm5ic3A7Zm9y Jm5ic3A7UHJvdG9jb2wmbmJzcDstJm5ic3A7PFNQQU4gDQogIGNsYXNzPTcxMDAxMTAyMS0yMTEw MjAwND4/PzwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBz aXplPSswPjxGT05UIGNvbG9yPSMwMDAwZmY+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz03 MTAwMTEwMjEtMjExMDIwMDQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9GT05UPjxTUEFOIA0KICBj bGFzcz03MTAwMTEwMjEtMjExMDIwMDQ+PC9TUEFOPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgY29s b3I9IzAwMDBmZj48Rk9OVCANCiAgc2l6ZT0yPk08U1BBTiBjbGFzcz03MTAwMTEwMjEtMjExMDIw MDQ+ZXNzYWdlcyBTZWN0aW9uIC0mbmJzcDt3b3JraW5nIA0KICAoSG9ybXV6ZCwgV2VpbWluZyk8 L1NQQU4+PC9GT05UPjwvRk9OVD48L0ZPTlQ+PEJSPjxTUEFOIA0KICBjbGFzcz03MTAwMTEwMjEt MjExMDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5IQSBTZWN0aW9u IC0gDQogIGRvbmUgKEhvcm11emQpPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBj bGFzcz03MTAwMTEwMjEtMjExMDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0K ICBzaXplPTI+UHJvdG9jb2wgU2NlbmFyaW9zIC0gUmFtL0g8L0ZPTlQ+PC9TUEFOPjwvRElWPg0K ICA8RElWPjxTUEFOIGNsYXNzPTcxMDAxMTAyMS0yMTEwMjAwND48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPSMwMDAwZmYgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElW PjxTUEFOIGNsYXNzPTcxMDAxMTAyMS0yMTEwMjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgDQogIHNpemU9Mj5NaW5vciB0b2Rvcy4uLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxE SVY+PFNQQU4gY2xhc3M9NzEwMDExMDIxLTIxMTAyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 IzAwMDBmZiANCiAgc2l6ZT0yPlNlY3VyaXR5IHNlY3Rpb24gLSBhbnkgdXBkYXRlcyBuZWVkZWQg UmFtID88L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICA8RElWPjxTUEFOIGNsYXNzPTcxMDAxMTAyMS0y MTEwMjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogIHNpemU9Mj5VcGRhdGVz IHRvIE92ZXJ2aWV3IChGdXJxdWFuIGhhZCBzZW50IGNvbW1lbnRzIHJlZ2FyZGluZyANCiAgaW5j b25zaXN0ZW5jaWVzKSAtZG9uZSBKYW1hbCA/PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48 U1BBTiBjbGFzcz03MTAwMTEwMjEtMjExMDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBj bGFzcz03MTAwMTEwMjEtMjExMDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0K ICBzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03 MTAwMTEwMjEtMjExMDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5J IA0KICB0aGluayBpZiB3ZSBnZXQgYWxsIHRoaXMgZG9uZSBiZWZvcmUgdGhlIGRlYWRsaW5lLCBp dCB3aWxsIGJlIGEgYmlnIA0KICBhY2NvbXBsaXNobWVudCE8L0ZPTlQ+PC9TUEFOPjwvRElWPg0K ICA8RElWPjxTUEFOIGNsYXNzPTcxMDAxMTAyMS0yMTEwMjAwND48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPSMwMDAwZmYgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElW PjxTUEFOIGNsYXNzPTcxMDAxMTAyMS0yMTEwMjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgDQogIHNpemU9Mj5yZWdhcmRzPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BB TiBjbGFzcz03MTAwMTEwMjEtMjExMDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IA0KICBzaXplPTI+SG9ybXV6ZDwvRk9OVD48L1NQQU4+PC9ESVY+DQogIDxESVY+PFNQQU4gY2xh c3M9NzEwMDExMDIxLTIxMTAyMDA0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXpl PTI+cC5zLiANCiAgUm9iZXJ0LCBJIHdpbGwgcmVzcG9uZCB0byB5b3VyIHByZXZpb3VzIG5vdGUg aW4gbXkgbmV4dCBlbWFpbCwgaXQgbW9zdGx5IA0KICBsb29rZWQgZmluZSBJIHRoaW5rLi4uPC9G T05UPjwvU1BBTj48L0RJVj4NCiAgPERJVj48U1BBTiBjbGFzcz03MTAwMTEwMjEtMjExMDIwMDQ+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICBzaXplPTI+PC9GT05UPjwvU1BBTj4m bmJzcDs8L0RJVj4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVz IGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgPEhSIHRhYkluZGV4PS0xPg0KICA8Rk9OVCBmYWNlPVRh aG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IFJvYmVydCBIYWFzIFttYWlsdG86cmhhQHp1cmljaC5p Ym0uY29tXSANCiAgPEJSPjwvRk9OVD48L0RJVj4NCiAgPEJMT0NLUVVPVEUgY2l0ZT1taWQ0NjhG M0ZEQTI4QUE4NzQyOUFEODA3OTkyRTIyRDA3RTAyNTc5MjAwQG9yc21zeDQwOCANCiAgdHlwZT0i Y2l0ZSI+DQogICAgPE1FVEEgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkKSIg bmFtZT1HZW5lcmF0b3I+DQogICAgPFNUWUxFPkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBX aW5nZGluZ3M7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogVGFob21hOw0KfQ0KQHBh Z2UgU2VjdGlvbjEge3NpemU6IDguNWluIDExLjBpbjsgbWFyZ2luOiAxLjBpbiAxLjI1aW4gMS4w aW4gMS4yNWluOyB9DQpQLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU46IDBp biAwaW4gMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIg0K fQ0KTEkuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEycHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7 IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpESVYuTXNv Tm9ybWFsIHsNCglGT05ULVNJWkU6IDEycHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IENPTE9SOiBi bGFjazsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpBOmxpbmsgew0KCUNPTE9S OiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsg ew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVk IHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNv SHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVy bGluZQ0KfQ0KUFJFIHsNCglGT05ULVNJWkU6IDEwcHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IENP TE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICJDb3VyaWVyIE5ldyINCn0NClNQQU4uRW1haWxTdHls ZTE4IHsNCglDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsDQp9DQpESVYuU2VjdGlvbjEg ew0KCXBhZ2U6IFNlY3Rpb24xDQp9DQo8L1NUWUxFPg0KDQogICAgPERJViBjbGFzcz1TZWN0aW9u MT4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNp emU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9O VC1GQU1JTFk6IEFyaWFsIj5Sb2JlcnQsPC9TUEFOPjwvRk9OVD48L1A+DQogICAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogICAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+ PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+V2VpbWluZyBhbmQgbXlzZWxm IA0KICAgIGFyZSBhbHJlYWR5IHdvcmtpbmcgb24gdGhpcyBzZWN0aW9uhUkgd2lsbCBzZW5kIG91 dCB3aGF0IEkgaGF2ZSANCiAgICBzaG9ydGx5LjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0K ICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJp YWwiPlNvbWUgb2YgdGhlIGNoYW5nZXMgDQogICAgYXJlIHByZXR0eSBzdHJhaWdodGZvcndhcmQs IGUuZy4gcmVtb3ZlIHNlY3Rpb24gNi42IDwvU1BBTj48L0ZPTlQ+PEZPTlQgDQogICAgZmFjZT1X aW5nZGluZ3MgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBXaW5nZGluZ3MiPko8L1NQQU4+PC9GT05U PjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5 IHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsg Rk9OVC1GQU1JTFk6IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAg ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFs Ij5Bbnl3YXlzIHdlIGNvdWxkIA0KICAgIGRlZmluaXRlbHkgdXNlIGhlbHAgaW4gdGhlIGRyYWZ0 LCB0aGVyZSBpcyBsb3RzIG9mIHN0dWZmIHRoYXQgbmVlZHMgdG8gYmUgDQogICAgZG9uZTwvU1BB Tj48L0ZPTlQ+PC9QPjwvRElWPjwvQkxPQ0tRVU9URT5Zb3UgYmV0LiBJIHN1cHBvc2UgSSBjYW4g aGVscCBhcyBhIA0KICBjby1hdXRob3Igb2YgdGhpcyBkcmFmdCA7LSk8QlI+DQogIDxCTE9DS1FV T1RFIGNpdGU9bWlkNDY4RjNGREEyOEFBODc0MjlBRDgwNzk5MkUyMkQwN0UwMjU3OTIwMEBvcnNt c3g0MDggDQogIHR5cGU9ImNpdGUiPg0KICAgIDxESVYgY2xhc3M9U2VjdGlvbjE+DQogICAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4g DQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBB cmlhbCI+SSB3aWxsIHNlbmQgb3V0IGEgDQogICAgbGlzdCBvZiBvdGhlciB0b2RvIGl0ZW1zIHNo b3J0bHkuLjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjwvU1BBTj48L0ZPTlQ+Jm5i c3A7PC9QPjwvRElWPjwvQkxPQ0tRVU9URT5JJ2xsIA0KICBzdGFydCBmcm9tIHlvdXIgaW5wdXQg dG9tb3Jyb3cgbW9ybmluZyBFdXJvcGUgdGltZS4gUGxlYXNlIHRha2UgYSBsb29rIGF0IG15IA0K ICBwcmV2aW91cyBub3RlIGFuZCByZXZpZXcgdGhlIHBlbmRpbmcgaXNzdWVzIEkgbGlzdGVkLiBU aGlzIHdheSB3ZSBhdm9pZCANCiAgY2hhbmdpbmcgdGhlIHRleHQgYmFjayBhbmQgZm9ydGguPEJS PjxCUj5UaGFua3MsPEJSPi1Sb2JlcnQ8QlI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkNDY4RjNG REEyOEFBODc0MjlBRDgwNzk5MkUyMkQwN0UwMjU3OTIwMEBvcnNtc3g0MDggDQogIHR5cGU9ImNp dGUiPg0KICAgIDxESVYgY2xhc3M9U2VjdGlvbjE+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAw MGZmIA0KICBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvQkxPQ0tRVU9URT4NCiAgPFA+DQog IDxIUj4NCg0KICA8UD48L1A+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188QlI+Rm9yY2VzLXByb3RvY29sIA0KICBtYWlsaW5nIA0KICBsaXN0PEJSPkZvcmNl cy1wcm90b2NvbEBpZXRmLm9yZzxCUj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9mb3JjZXMtcHJvdG9jb2w8QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0057_01C4B820.43300020-- --===============0331706627== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0331706627==-- From forces-protocol-bounces@ietf.org Thu Oct 21 22:49:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04181 for ; Thu, 21 Oct 2004 22:49:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKphS-0003PC-16 for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 23:02:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKpCQ-0002sJ-6U; Thu, 21 Oct 2004 22:30:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKp4Q-0002vS-G9 for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 22:22:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02038 for ; Thu, 21 Oct 2004 22:22:19 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKpH5-0002wI-7g for forces-protocol@ietf.org; Thu, 21 Oct 2004 22:35:31 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Fri, 22 Oct 2004 10:41:20 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Fri, 22 Oct 2004 10:17:43 +0800 Message-ID: <0e9d01c4b7dd$9c19d2d0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Zsolt Haraszti" References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> <1098383190.2883.386.camel@localhost.localdomain> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Fri, 22 Oct 2004 10:19:50 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "Khosravi, Hormuzd M" , "Joel M. Halpern" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , Alan DeKok , Jamal Hadi Salim , forces-protocol@ietf.org, Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Zsolt, ----- Original Message ----- From: "Zsolt Haraszti" Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? > Weiming, > > I have a very hard time to resonate with your examples, and therefore > with your reasoning. > > For one, if you end up needing 64k LFBs from the same class, I think > you or we did something wrong with the model. Sure you mean it an > extreme case, but I think it is a misleading one. I envision > practical LFB models having up to a few hundred LFB instances, where > multiple instances of the same class will be in very different roles > (e.g., a Classifier LFB supporting Diffserv versus a Classifier > LFB supporting IPsec, etc.), hence more often not sharing any config > data than sharing some. I think Joel has expained some. Actually I have no doult agreeing with you that different instances may have different roles there fore may have different attribute values, but we can not exclude that there are many cases the attributes of instances are the same. From my current experiences, I'v already seen the same attribute values needed for schedulers, queues, ports, policers, and even classifiers. Note that what I mean the 'same' is not the same for all data of insatnces, there can be only one attribute data entry that are set the same, then the value of multiple addressing appears. Even if we have say 10 instances, to repeat the same data for 10 times is already boring thing to do. > For two, displacing the two parts of the LFB address (class ID and > instance ID) in the protocol is a much bigger concern to me than to > allow ad-hoc/state-less multicast addressing. It would be in some > sense similar to if in the IP header the (sub-)network address and > host-address part of the IP address were placed in distant offsets. I see your thought here, and I actually like this, not at all exclude this. I just think both the multicast address based mulitple addressing and the explicit multiple addressing should all be needed. For multicast address based, it's more fit for those insatnces that have more same data to set and the multicast group are more permanent comparatively. For explicit based, it's more fit for some instant use of the same data setup for instances. I try to show an example to clear this as, say 10 insatnces, 1-5 need to setup same parameter1, 2-6 to set same parameter2, 3-10 to set p3, 4-6 to set pa4, etc. In this case, to setup many multicast group is really not applicable, but by using a very handy explicit muliple addressing, it just makes things very easy. > For three, on state-less versus state-ful multicast: Your example > below is based on the very extreme case when you have a SINGLE > config message addressed to a VERY LARGE number of LFB instances > of the same class. I have not yet seen a practical case for this > scenario. I reiterate that multicast groups are not ad-hoc, and > there will be typically a large number of config updates sent to a > group after the group is formed. > I'm not sure if you mean explicit multiple instance addressing is state-less and defining specific multicat group is stateful. I agree the latter is not ad-hoc. > Regards, > Zsolt > Thank you. Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 22:52:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04603 for ; Thu, 21 Oct 2004 22:52:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKpkj-0003UQ-SO for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 23:06:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKpVx-00008B-Co; Thu, 21 Oct 2004 22:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKpDB-00033x-Ch for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 22:31:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02836 for ; Thu, 21 Oct 2004 22:31:21 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKpPt-00037S-MF for forces-protocol@ietf.org; Thu, 21 Oct 2004 22:44:34 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9M2VTW0018001; Fri, 22 Oct 2004 02:31:29 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9M2Y0xo029363; Fri, 22 Oct 2004 02:34:29 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102119305106897 ; Thu, 21 Oct 2004 19:30:51 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 19:30:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Forces-protocol] Re: protocol draft editing? Date: Thu, 21 Oct 2004 19:30:24 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579204@orsmsx408> Thread-Topic: [Forces-protocol] Re: protocol draft editing? Thread-Index: AcS33X+oKY8RMvPYSs2Tj/qiIR3TuQAAYEwg From: "Khosravi, Hormuzd M" To: "Ligang Dong" , "Robert Haas" X-OriginalArrivalTime: 22 Oct 2004 02:30:50.0527 (UTC) FILETIME=[255712F0:01C4B7DF] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.2 (/) X-Scan-Signature: eb4c5242518af073df6fe45f0d1cde3e Cc: hadi@znyx.com, avri@psg.com, ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1276559149==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: b67ab81b2db0d00304056d0360a5a39a This is a multi-part message in MIME format. --===============1276559149== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B7DF.24F1A019" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B7DF.24F1A019 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Go ahead, pls try to send us something by tonight or tomorrow morning. =20 Thanks for volunteering, =20 Hormuzd =20 ________________________________ From: Ligang Dong [mailto:donglg@mail.hzic.edu.cn]=20 Sent: Thursday, October 21, 2004 7:17 PM To: Khosravi, Hormuzd M; Robert Haas Cc: ram.gopal@nokia.com; forces-protocol@ietf.org; avri@psg.com; hadi@znyx.com; Weiming Wang Subject: Re: [Forces-protocol] Re: protocol draft editing? =20 hi,=20 I can edit the "state machine for protocol". ligang ----- Original Message -----=20 From: Khosravi, Hormuzd M To: Robert Haas =20 Cc: ram.gopal@nokia.com ; Ligang Dong ; forces-protocol@ietf.org ; avri@psg.com ; hadi@znyx.com ; Weiming Wang =20 Sent: Friday, October 22, 2004 5:43 AM Subject: RE: [Forces-protocol] Re: protocol draft editing? =20 Dear Robert (co-author :)), All =20 Here is a list of major todos... =20 Header Section - Jamal/Robert/Weiming? Protocol LFB - Robert/Others? FE LFB - Robert/Others? State Machine for Protocol - ?? Messages Section - working (Hormuzd, Weiming) HA Section - done (Hormuzd) Protocol Scenarios - Ram/H =20 Minor todos... Security section - any updates needed Ram ? Updates to Overview (Furquan had sent comments regarding inconsistencies) -done Jamal ? =20 =20 I think if we get all this done before the deadline, it will be a big accomplishment! =20 regards Hormuzd p.s. Robert, I will respond to your previous note in my next email, it mostly looked fine I think... =20 =09 ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Robert, =20 Weiming and myself are already working on this section...I will send out what I have shortly. Some of the changes are pretty straightforward, e.g. remove section 6.6 :-) =20 Anyways we could definitely use help in the draft, there is lots of stuff that needs to be done You bet. I suppose I can help as a co-author of this draft ;-) =09 =09 I will send out a list of other todo items shortly.. =20 I'll start from your input tomorrow morning Europe time. Please take a look at my previous note and review the pending issues I listed. This way we avoid changing the text back and forth. =09 Thanks, -Robert =09 =09 =20 =09 ________________________________ _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol ------_=_NextPart_001_01C4B7DF.24F1A019 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Go ahead, pls try to send us = something by tonight or tomorrow morning.

 

Thanks for = volunteering,

 

Hormuzd

 

From: Ligang Dong [mailto:donglg@mail.hzic.edu.cn]
Sent: Thursday, October = 21, 2004 7:17 PM
To: Khosravi, Hormuzd M; = Robert Haas
Cc: ram.gopal@nokia.com; forces-protocol@ietf.org; avri@psg.com; hadi@znyx.com; Weiming Wang
Subject: Re: = [Forces-protocol] Re: protocol draft editing?

 

hi,

I can edit the "state machine for = protocol".

ligang

----- Original Message ----- =

To:<= /font> Robert = Haas

Sent: Friday, October 22, 2004 5:43 AM

Subject: RE: [Forces-protocol] Re: protocol draft editing?

 

Dear Robert (co-author :)), = All

 

Here is a list of major = todos...

 

Header Section - = Jamal/Robert/Weiming?

Protocol LFB - = Robert/Others?

FE LFB - = Robert/Others?

State Machine for Pro= tocol - ??

Messages Section - working = (Hormuzd, Weiming)
HA Section - done (Hormuzd)

Protocol Scenarios - = Ram/H

 

Minor todos...

Security section - any updates = needed Ram ?

Updates to Overview (Furquan had = sent comments regarding inconsistencies) -done Jamal ?

 

 

I think if we get all this done = before the deadline, it will be a big accomplishment!

 

regards

Hormuzd

p.s. Robert, I will respond to your previous note in my next email, it mostly looked fine I = think...

 

From: Robert Haas [mailto:rha@zurich.ibm.com]

Robert,

 

Weiming and myself are already = working on this section…I will send out what I have = shortly.

Some of the changes are pretty straightforward, e.g. remove section 6.6 J

 

Anyways we could definitely use = help in the draft, there is lots of stuff that needs to be = done

You bet. I suppose I can help as a co-author = of this draft ;-)

I will send out a list of other = todo items shortly..

 

I'll start from your input tomorrow morning = Europe time. Please take a look at my previous note and review the = pending issues I listed. This way we avoid changing the text back and forth.

Thanks,
-Robert

 

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

------_=_NextPart_001_01C4B7DF.24F1A019-- --===============1276559149== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1276559149==-- From forces-protocol-bounces@ietf.org Thu Oct 21 22:54:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04803 for ; Thu, 21 Oct 2004 22:54:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKpmM-0003X4-6U for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 23:07:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKpWp-0000Su-2m; Thu, 21 Oct 2004 22:51:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKpFD-0003cW-Dv for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 22:33:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02877 for ; Thu, 21 Oct 2004 22:33:27 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKpRr-00038b-Ba for forces-protocol@ietf.org; Thu, 21 Oct 2004 22:46:40 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Fri, 22 Oct 2004 10:50:54 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Fri, 22 Oct 2004 10:27:17 +0800 Message-ID: <0ee501c4b7de$f24000c0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Steven Blake" , "Robert Haas" References: <468F3FDA28AA87429AD807992E22D07E025791E9@orsmsx408><04ab01c4b5c7$1332c430$845c21d2@Necom.hzic.edu.cn><417573E8.7070502@zurich.ibm.com> <1098385216.2340.239.camel@localhost.localdomain> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Fri, 22 Oct 2004 10:29:24 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Zsolt Haraszti , "Joel M. Halpern" , hadi@znyx.com, forces-protocol@ietf.org, Alan DeKok , "Deleganes, Ellen M" , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 ----- Original Message ----- From: "Steven Blake" > > > To cover the case of a list of LFB Instances (reminds me of xcast ;-) > > we can modify the LFBSelect TLV as follows: > > main hdr (eg type = config)| > > +--- T = LFBselect > > | | > > | +-- LFBCLASSID = target LFB class > > | | > > | | > > | +-- one more LFBInstance(s) = target LFB instance(s). > > [the size of this TLV tells how long the list is] > > I'm not sure this is needed. If we have multiple LFB instances of a > certain class on an FE sharing configuration data, I would like to see > that explicitly represented in the model (a todo from the August IETF > that I haven't followed through on yet), rather than xcast'ing config > messages. I can not catch any idea on how a model can do this, could you present more on this? Thanks. Weiming > > > Regards, > > // Steve _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 21 23:00:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05426 for ; Thu, 21 Oct 2004 23:00:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKpsO-0003fN-Rn for forces-protocol-web-archive@ietf.org; Thu, 21 Oct 2004 23:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKpYI-0002FJ-8h; Thu, 21 Oct 2004 22:53:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKpW0-00008I-MV for forces-protocol@megatron.ietf.org; Thu, 21 Oct 2004 22:50:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04308 for ; Thu, 21 Oct 2004 22:50:49 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKpii-0003Pm-8l for forces-protocol@ietf.org; Thu, 21 Oct 2004 23:04:02 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Fri, 22 Oct 2004 11:09:42 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Fri, 22 Oct 2004 10:46:05 +0800 Message-ID: <0f0501c4b7e1$925dec50$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07E02F99D71@orsmsx408> Date: Fri, 22 Oct 2004 10:48:11 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: "Joel M. Halpern" , ram.gopal@nokia.com, zsolt@nc.rr.com, "Steven Blake \(petri-meat\)" , hadi@znyx.com, Alan DeKok , "Deleganes, Ellen M" , "Yang, Lily L" Subject: [Forces-protocol] Re: Instance Select X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Hormuzd, ----- Original Message ----- From: "Khosravi, Hormuzd M" Subject: RE: Instance Select Weiming, I haven't seen any compelling example (real NE) to need this kind of functionality in the protocol. [Weiming]I think i'v repeated this necessity several times . Sorry you can not feel it, but I'm sure if you'v got a test platform to practically do something, you'l have more strong feel on the desire for this :) Therefore, I don't think this complexity needs to be added... [Weiming] I don't agree it adds much complexity. at most we need a Broadcast Instance ID definition (Send msgs to all LFBs of a particular Type). [Weiming]That's not enough. I'v shown some examples to state this. But I will be happy to hear what Jamal, others have to say on this ? I am not religious either way... regards Hormuzd -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn] Sent: Wednesday, October 20, 2004 9:48 PM To: forces-protocol@ietf.org Cc: Khosravi, Hormuzd M; hadi@znyx.com; Joel M. Halpern; ram.gopal@nokia.com; Yang, Lily L; Alan DeKok; zsolt@nc.rr.com; Steven Blake (petri-meat); Deleganes, Ellen M Subject: Instance Select Hi Jamal, Hormuzd, etc, To summarize the discussions on multiple instances, I try to propose following scheme for instance selection, which follows Robert's idea and Jamal's format, as: PL level PDU : = MAINHDR+ LFBselect := LFBCLASSID InsSelect + InsSelect := InstanceID + RangeMark := '0xFFFFFFFF'; the value is the same as Broadcast Instance address, no worry of ambiguity here. The InsSelect is a TLV, whose structure is shown as: main hdr (eg type = config) | | +-- T = LFBselect | | | +- LFBCLASSID = target LFB class | | | | | +- T = InsSelect | | | | | V = InstanceID + | | | +- T = operation { ADD, DEL, GET, etc} ... Best Regards, Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 01:12:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14763 for ; Fri, 22 Oct 2004 01:12:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKrw4-00062I-SA for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 01:25:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKria-0000KU-K5; Fri, 22 Oct 2004 01:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKreq-0006vs-IZ for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 01:08:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14488 for ; Fri, 22 Oct 2004 01:08:07 -0400 (EDT) From: avri@acm.org Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKrrZ-0005wS-FS for forces-protocol@ietf.org; Fri, 22 Oct 2004 01:21:18 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9M4hmep026094; Fri, 22 Oct 2004 06:43:50 +0200 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <570BE1B0-23E8-11D9-9DB1-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Date: Fri, 22 Oct 2004 01:07:58 -0400 To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: Hormuzd M Khosravi , Jamal Hadi Salim Subject: [Forces-protocol] draft-ietf-forces-protocol-01-0.txt X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit hi, i will try to put out a draft each day over the next few days including anything i have received so far. at this point, unless i missed something (alwasys possible as we know) i only had Jamal's diffs. the current draft is: http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-0.txt while i read all the email, it is easiest if the subject lines indicates something that should be included in the draft. for example, put [draft] in the subject line. i will still read all the messages looking for content and just in case i have a comment, but to be sure i catch everything, it is best to be obvious. thanks a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 02:03:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21153 for ; Fri, 22 Oct 2004 02:03:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKsjb-0006kj-MY for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 02:17:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKsU6-0000t2-SX; Fri, 22 Oct 2004 02:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKsLm-00066x-8f for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 01:52:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16659 for ; Fri, 22 Oct 2004 01:52:29 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKsYV-0006bL-EL for forces-protocol@ietf.org; Fri, 22 Oct 2004 02:05:40 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9M5qW06032736; Fri, 22 Oct 2004 05:52:32 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9M5svn3031265; Fri, 22 Oct 2004 05:55:30 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102122515226639 ; Thu, 21 Oct 2004 22:51:52 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 22:51:52 -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 Date: Thu, 21 Oct 2004 22:51:37 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579206@orsmsx408> Thread-Topic: draft-ietf-forces-protocol-01-0.txt Thread-Index: AcS39SA2+AwtSYvaQH22PyCa5hyoLAABfp8A From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 22 Oct 2004 05:51:52.0165 (UTC) FILETIME=[3AA2F950:01C4B7FB] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Weiming Wang , Ligang Dong , Steve Blake Subject: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Avri, I sent an update to the HA section, pls incorporate it into the draft Thanks Hormuzd -----Original Message----- From: avri@acm.org [mailto:avri@acm.org]=20 Sent: Thursday, October 21, 2004 10:08 PM To: forces-protocol@ietf.org Cc: Khosravi, Hormuzd M; Jamal Hadi Salim; ram.gopal@nokia.com; Steve Blake; Ligang Dong; Weiming Wang Subject: draft-ietf-forces-protocol-01-0.txt hi, i will try to put out a draft each day over the next few days including=20 anything i have received so far. at this point, unless i missed something (alwasys possible as we know)=20 i only had Jamal's diffs. the current draft is: http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-0.txt while i read all the email, it is easiest if the subject lines=20 indicates something that should be included in the draft. for example,=20 put [draft] in the subject line. i will still read all the messages=20 looking for content and just in case i have a comment, but to be sure i=20 catch everything, it is best to be obvious. thanks a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 02:15:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02102 for ; Fri, 22 Oct 2004 02:15:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKsv3-0006z4-5k for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 02:28:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKsgM-0002m9-H0; Fri, 22 Oct 2004 02:13:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKsfc-0001ha-F1 for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 02:13:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00017 for ; Fri, 22 Oct 2004 02:12:58 -0400 (EDT) From: avri@acm.org Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKssJ-0006vk-9l for forces-protocol@ietf.org; Fri, 22 Oct 2004 02:26:10 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9M5mcep026225; Fri, 22 Oct 2004 07:48:39 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579206@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579206@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <65E308B0-23F1-11D9-9DB1-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Date: Fri, 22 Oct 2004 02:12:48 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: forces-protocol@ietf.org, ram.gopal@nokia.com, Ligang Dong , Steve Blake , Jamal Hadi Salim , Weiming Wang X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit what did you do, rewrite the entire section. or do i need to go through and find the diffs? a. On 22 okt 2004, at 01.51, Khosravi, Hormuzd M wrote: > Avri, > > I sent an update to the HA section, pls incorporate it into the draft > > Thanks > Hormuzd > > -----Original Message----- > From: avri@acm.org [mailto:avri@acm.org] > Sent: Thursday, October 21, 2004 10:08 PM > To: forces-protocol@ietf.org > Cc: Khosravi, Hormuzd M; Jamal Hadi Salim; ram.gopal@nokia.com; Steve > Blake; Ligang Dong; Weiming Wang > Subject: draft-ietf-forces-protocol-01-0.txt > > hi, > > i will try to put out a draft each day over the next few days including > anything i have received so far. > > at this point, unless i missed something (alwasys possible as we know) > i only had Jamal's diffs. > > the current draft is: > http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-0.txt > > while i read all the email, it is easiest if the subject lines > indicates something that should be included in the draft. for example, > put [draft] in the subject line. i will still read all the messages > looking for content and just in case i have a comment, but to be sure i > catch everything, it is best to be obvious. > > thanks > a. > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 02:25:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03268 for ; Fri, 22 Oct 2004 02:25:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKt4q-00076U-J3 for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 02:39:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKsr3-0000v7-2z; Fri, 22 Oct 2004 02:24:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKsn8-0006sS-OI for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 02:20:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02584 for ; Fri, 22 Oct 2004 02:20:45 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKszs-00071a-TF for forces-protocol@ietf.org; Fri, 22 Oct 2004 02:33:57 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9M6Kn06012159; Fri, 22 Oct 2004 06:20:49 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9M6DhJ6001971; Fri, 22 Oct 2004 06:13:50 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102123201008828 ; Thu, 21 Oct 2004 23:20:10 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 23:20:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4B7FF.2E8C66B2" Subject: RE: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Date: Thu, 21 Oct 2004 23:19:56 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579209@orsmsx408> X-MS-Has-Attach: yes Thread-Topic: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Thread-Index: AcS3/i+LMe6Ch0CYT2qE21XYX0FNvAAADTzw From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 22 Oct 2004 06:20:10.0679 (UTC) FILETIME=[2F07A470:01C4B7FF] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B7FF.2E8C66B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I sent you the entire section so you can just put it in. You don't have to find any diffs. I have attached it again for your convenience. BTW, where are you at this moment? in the US or Europe? Just curious in case we need to setup some conference calls. Hormuzd -----Original Message----- From: avri@acm.org [mailto:avri@acm.org]=20 Sent: Thursday, October 21, 2004 11:13 PM To: Khosravi, Hormuzd M Cc: forces-protocol@ietf.org; Jamal Hadi Salim; Ligang Dong; ram.gopal@nokia.com; Steve Blake; Weiming Wang Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt what did you do, rewrite the entire section. or do i need to go=20 through and find the diffs? a. On 22 okt 2004, at 01.51, Khosravi, Hormuzd M wrote: > Avri, > > I sent an update to the HA section, pls incorporate it into the draft > > Thanks > Hormuzd > > -----Original Message----- > From: avri@acm.org [mailto:avri@acm.org] > Sent: Thursday, October 21, 2004 10:08 PM > To: forces-protocol@ietf.org > Cc: Khosravi, Hormuzd M; Jamal Hadi Salim; ram.gopal@nokia.com; Steve > Blake; Ligang Dong; Weiming Wang > Subject: draft-ietf-forces-protocol-01-0.txt > > hi, > > i will try to put out a draft each day over the next few days including > anything i have received so far. > > at this point, unless i missed something (alwasys possible as we know) > i only had Jamal's diffs. > > the current draft is: > http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-0.txt > > while i read all the email, it is easiest if the subject lines > indicates something that should be included in the draft. for example, > put [draft] in the subject line. i will still read all the messages > looking for content and just in case i have a comment, but to be sure i > catch everything, it is best to be obvious. > > thanks > a. > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > ------_=_NextPart_001_01C4B7FF.2E8C66B2 Content-Type: text/plain; name="HA-section-new.txt" Content-Description: HA-section-new.txt Content-Disposition: attachment; filename="HA-section-new.txt" Content-Transfer-Encoding: base64 OC4gSGlnaCBBdmFpbGFiaWxpdHkgU3VwcG9ydCAoQ0UgZmFpbG92ZXIgU3VwcG9ydCkNCg0KICAg VGhlIEZvckNFUyBwcm90b2NvbCBwcm92aWRlcyBtZWNoYW5pc21zIGZvciBDRSByZWR1bmRhbmN5 IGFuZA0KICAgZmFpbG92ZXIsIGluIG9yZGVyIHRvIHN1cHBvcnQgSGlnaCBBdmFpbGFiaWxpdHkg YXMgcGVyIFJlcXNbXS4gRkUgDQpyZWR1bmRhbmN5IGFuZCBGRSB0byBGRQ0KaW50ZXJhY3Rpb24g aXMgY3VycmVudGx5IG91dCBvZiBzY29wZSBvZiB0aGlzIGRyYWZ0LiBUaGVyZSBjYW4gYmUNCiAg IG11bHRpcGxlIHJlZHVuZGFudCBDRXMgYW5kIEZFcyBpbiBhIEZvckNFUyBORS4gIEhvd2V2ZXIs IGF0IGFueSB0aW1lDQogICB0aGVyZSBjYW4gb25seSBiZSBvbmUgUHJpbWFyeSBDRSBjb250cm9s bGluZyB0aGUgRkVzIGFuZCB0aGVyZSBjYW4gYmUNCiAgIG11bHRpcGxlIHNlY29uZGFyeSBDRXMu ICBUaGUgRkUgYW5kIHRoZSBDRSBQTCBhcmUgYXdhcmUgb2YgdGhlDQogICBwcmltYXJ5IGFuZCBz ZWNvbmRhcnkgQ0VzLiAgVGhpcyBpbmZvcm1hdGlvbiAocHJpbWFyeSwgc2Vjb25kYXJ5IENFcykN CiAgIGlzIGNvbmZpZ3VyZWQgaW4gdGhlIEZFLCBDRSBQTHMgZHVyaW5nIHByZS1hc3NvY2lhdGlv biBieSBGRU0sIENFTQ0KICAgcmVzcGVjdGl2ZWx5LiAgT25seSB0aGUgcHJpbWFyeSBDRSBzZW5k cyBDb250cm9sIG1lc3NhZ2VzIHRvIHRoZSBGRXMuDQogICBUaGUgRkUgbWF5IHNlbmQgaXRzIGV2 ZW50IHJlcG9ydHMsIHJlZGlyZWN0aW9uIHBhY2tldHMgdG8gb25seSB0aGUNCiAgIFByaW1hcnkg Q0UgKFJlcG9ydCBQcmltYXJ5IE1vZGUpIG9yIGl0IG1heSBzZW5kIHRoZXNlIHRvIGJvdGggcHJp bWFyeQ0KICAgYW5kIHNlY29uZGFyeSBDRXMgKFJlcG9ydCBBbGwgTW9kZSkuICAoVGhlIGxhdHRl ciBoZWxwcyB3aXRoIGtlZXBpbmcNCiAgIHN0YXRlIGJldHdlZW4gQ0VzIHN5bmNocm9uaXplZCwg YWx0aG91Z2ggaXQgZG9lcyBub3QgZ3VhcmFudGVlDQogICBzeW5jaHJvbml6YXRpb24uKSBUaGlz IGJlaGF2aW9yIG9yIEhBIE1vZGVzIGFyZSBjb25maWd1cmVkIGR1cmluZw0KICAgQXNzb2NpYXRp b24gc2V0dXAgcGhhc2UgYnV0IGNhbiBiZSBjaGFuZ2VkIGJ5IHRoZSBDRSBhbnl0aW1lIGR1cmlu Zw0KICAgcHJvdG9jb2wgb3BlcmF0aW9uLiAgQSBDRS10by1DRSBzeW5jaHJvbml6YXRpb24gcHJv dG9jb2wgd2lsbCBiZQ0KICAgbmVlZGVkIGluIG1vc3QgY2FzZXMgdG8gc3VwcG9ydCBmYXN0IGZh aWxvdmVyLCBob3dldmVyIHRoaXMgd2lsbCBub3QNCiAgIGJlIGRlZmluZWQgYnkgdGhlIEZvckNF UyBwcm90b2NvbC4NCg0KICAgRHVyaW5nIGEgY29tbXVuaWNhdGlvbiBmYWlsdXJlIGJldHdlZW4g dGhlIEZFIGFuZCBDRSAod2hpY2ggaXMgY2F1c2VkDQogICBkdWUgdG8gQ0Ugb3IgbGluayByZWFz b25zLCBpLmUuICBub3QgRkUgcmVsYXRlZCksIHRoZSBUTUwgb24gdGhlIEZFDQogICB3aWxsIHRy aWdnZXIgdGhlIEZFIFBMIHJlZ2FyZGluZyB0aGlzIGZhaWx1cmUuIFRoaXMgY2FuIGFsc28gYmUg ZGV0ZWN0ZWQgDQp1c2luZyB0aGUgSEIgbWVzc2FnZXMgYmV0d2VlbiBGRXMgYW5kIENFcy4gVGhl IEZFIFBMIHdpbGwgc2VuZCBhDQogICBtZXNzYWdlIChFdmVudCBSZXBvcnQpIHRvIHRoZSBTZWNv bmRhcnkgQ0VzIHRvIGluZGljYXRlIHRoaXMgZmFpbHVyZQ0KICAgb3IgdGhlIENFIFBMIHdpbGwg ZGV0ZWN0IHRoaXMgYW5kIG9uZSBvZiB0aGUgU2Vjb25kYXJ5IENFcyB0YWtlcyBvdmVyDQogICBh cyB0aGUgcHJpbWFyeSBDRSBmb3IgdGhlIEZFLiAgRHVyaW5nIHRoaXMgcGhhc2UsIGlmIHRoZSBv cmlnaW5hbCBwcmltYXJ5DQpDRSBjb21lcyBhbGl2ZSBhbmQgc3RhcnRzIHNlbmRpbmcgYW55IGNv bW1hbmRzIHRvIHRoZSBGRSwgdGhlIEZFIHNob3VsZCANCmlnbm9yZSB0aG9zZSBtZXNzYWdlcyBh bmQgc2VuZCBhbiBFdmVudCB0byBhbGwgQ0VzIGluZGljYXRpbmcgaXRzIGNoYW5nZSBpbg0KUHJp bWFyeSBDRS4gVGh1cyB0aGUgRkUgb25seSBoYXMgb25lIHByaW1hcnkgQ0UgYXQgYSB0aW1lLg0K DQpBbiBleHBsaWNpdCBtZXNzYWdlIChDb25maWcgbWVzc2FnZS0NCiAgIE1vdmUgY29tbWFuZCkg ZnJvbSB0aGUgcHJpbWFyeSBDRSwgY2FuIGFsc28gYmUgdXNlZCB0byBjaGFuZ2UgdGhlDQogICBQ cmltYXJ5IENFIGZvciBhbiBGRSBkdXJpbmcgbm9ybWFsIHByb3RvY29sIG9wZXJhdGlvbi4gIElu IG9yZGVyIHRvDQogICBzdXBwb3J0IGZhc3QgZmFpbG92ZXIsIHRoZSBGRSB3aWxsIGVzdGFibGlz aCBhc3NvY2lhdGlvbiAoc2V0dXAgbXNnKQ0KICAgYXMgd2VsbCBhcyBjb21wbGV0ZSB0aGUgY2Fw YWJpbGl0eSBleGNoYW5nZSB3aXRoIHRoZSBQcmltYXJ5IGFzIHdlbGwNCiAgIGFzIGFsbCB0aGUg U2Vjb25kYXJ5IENFcyAoaW4gYWxsIHNjZW5hcmlvcy9tb2RlcykuDQoNCiAgIFRoZXNlIHR3byBz Y2VuYXJpb3MgKFJlcG9ydCBBbGwsIFJlcG9ydCBQcmltYXJ5KSBoYXZlIGJlZW4NCiAgIGlsbHVz dHJhdGVkIGluIHRoZSBmaWd1cmVzIGJlbG93Lg0KDQoNCiAgICAgICAgICAgICAgICAgICAgIEZF ICAgICAgICAgICAgICAgICAgICAgIENFIFByaW1hcnkgICAgICAgICBDRSBTZWNvbmRhcnkNCiAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgQXNzbyBFc3RiLENhcHMgZXhj aGcgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAxIHw8LS0t LS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICBBc3NvIEVzdGIsQ2Fwc3xleGNoYW5n ZSAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAyIHw8LS0tLS0tLS0tLS0tLS0t LS0tLS0tLXwtLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgIEFsbCBtc2dzICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAzIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgcGFja2V0IHJlZGlyZWN0aW9uLHxldmVudHMsIEhCcyAgICAgICAgIHwNCiAgICAgICAg ICAgICAgICAgICAgICA0IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwtLS0tLS0tLS0tLS0tLS0t LS0tPnwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgRkFJTFVSRSAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgRXZlbnQgUmVwb3J0IChwcmkgQ0UgZG93 bikgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICA1IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICBBbGwgTXNncyAgICAgICAgICAgICAgICAgIHwNCiAg ICAgICAgICAgICAgICAgICAgICA2IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPnwNCg0KDQogICAgICAgICAgICAgICBGaWd1cmUgMzA6IENFIEZhaWxvdmVyIGZv ciBSZXBvcnQgQWxsIG1vZGUNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICBGRSAgICAgICAg ICAgICAgICAgICBDRSBQcmltYXJ5ICAgICAgICBDRSBTZWNvbmRhcnkNCiAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICAgICAgICAgICAgICAgICAgIHwgIEFzc28gRXN0YixDYXBzIGV4Y2hnIHwgICAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAxIHw8LS0tLS0tLS0tLS0tLS0t LS0tLS0tPnwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICBBc3NvIEVzdGIsQ2Fwc3xleGNoYW5nZSAgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAyIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwtLS0t LS0tLS0tLS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgQWxsIG1zZ3MgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAg ICAgICAgICAgICAgICAzIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAoSGVhcnRCZWF0c3wgb25seSkgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAg ICA0IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwtLS0tLS0tLS0tLS0tLS0tLS0tPnwNCiAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgRkFJ TFVSRSAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgIEV2ZW50IFJlcG9ydCAocHJpIENFIGRvd24pICAgIHwNCiAg ICAgICAgICAgICAgICAgICAgICA1IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPnwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgQWxsIE1zZ3MgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgICA2IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwN Cg0KDQogICAgICAgICAgICAgRmlndXJlIDMxOiBDRSBGYWlsb3ZlciBmb3IgUmVwb3J0IFByaW1h cnkgTW9kZQ0KDQoNCjguMSAgUmVzcG9uc2liaWxpdGllcyBmb3IgSEENCg0KICAgVE1MIGxldmVs IC0gVHJhbnNwb3J0IGxldmVsOg0KICAgMS4gIFRoZSBUTUwgY29udHJvbHMgbG9naWNhbCBjb25u ZWN0aW9uIGF2YWlsYWJpbGl0eSBhbmQgZmFpbG92ZXIuDQogICAyLiAgVGhlIFRNTCBhbHNvIGNv bnRyb2xzIHBlZXIgSEEgbWFuYWdlbWVudHMuDQoNCiAgIEF0IHRoaXMgbGV2ZWwsIGNvbnRyb2wg b2YgYWxsIGxvd2VyIGxheWVycyBleGFtcGxlIHRyYW5zcG9ydCBsZXZlbA0KICAgKHN1Y2ggYXMg SVAgYWRkcmVzc2VzLCBNQUMgYWRkcmVzc2VzIGV0YykgYW5kIGFzc29jaWF0ZWQgbGlua3MgZ29p bmcNCiAgIGRvd24gYXJlIHRoZSByb2xlIG9mIHRoZSBUTUwuDQoNCiAgIFBMIExldmVsOg0KICAg QWxsIHRoZSBvdGhlciBmdW5jdGlvbmFsaXR5IGluY2x1ZGluZyBjb25maWd1cmluZyB0aGUgSEEg YmVoYXZpb3INCiAgIGR1cmluZyBzZXR1cCwgdGhlIENFSURzIGFyZSB1c2VkIHRvIGlkZW50aWZ5 IHByaW1hcnksIHNlY29uZGFyeSBDRXMsDQogICBwcm90b2NvbCBNZXNzYWdlcyB1c2VkIHRvIHJl cG9ydCBDRSBmYWlsdXJlIChFdmVudCBSZXBvcnQpLCBIZWFydGJlYXQNCiAgIG1lc3NhZ2VzIHVz ZWQgdG8gZGV0ZWN0IGFzc29jaWF0aW9uIGZhaWx1cmUsIG1lc3NhZ2VzIHRvIGNoYW5nZQ0KICAg cHJpbWFyeSBDRSAoQ29uZmlnIC0gbW92ZSksIGFuZCBvdGhlciBIQSByZWxhdGVkIG9wZXJhdGlv bnMNCiAgIGRlc2NyaWJlZCBiZWZvcmUgYXJlIHRoZSBQTCByZXNwb25zaWJpbGl0eS4NCg0KICAg VG8gcHV0IHRoZSB0d28gdG9nZXRoZXIsIGlmIGEgcGF0aCB0byBhIHByaW1hcnkgQ0UgaXMgZG93 biwgdGhlIFRNTA0KICAgd291bGQgdGFrZSBjYXJlIG9mIGZhaWxpbmcgb3ZlciB0byBhIGJhY2t1 cCBwYXRoLCBpZiBvbmUgaXMNCiAgIGF2YWlsYWJsZS4gIElmIHRoZSBDRSBpcyB0b3RhbGx5IHVu cmVhY2hhYmxlIHRoZW4gdGhlIFBMIHdvdWxkIGJlDQogICBpbmZvcm1lZCBhbmQgaXQgd2lsbCB0 YWtlIHRoZSBhcHByb3ByaWF0ZSBhY3Rpb25zIGRlc2NyaWJlZCBiZWZvcmUuDQoNCg== ------_=_NextPart_001_01C4B7FF.2E8C66B2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol ------_=_NextPart_001_01C4B7FF.2E8C66B2-- From forces-protocol-bounces@ietf.org Fri Oct 22 03:08:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06303 for ; Fri, 22 Oct 2004 03:08:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKtjq-0007qZ-CX for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 03:21:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtUm-00010h-3z; Fri, 22 Oct 2004 03:05:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtK9-0005bt-Do for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 02:54:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05154 for ; Fri, 22 Oct 2004 02:54:51 -0400 (EDT) From: avri@acm.org Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKtWt-0007ZY-3O for forces-protocol@ietf.org; Fri, 22 Oct 2004 03:08:04 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9M6UZep026274; Fri, 22 Oct 2004 08:30:36 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579209@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579209@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <420441FF-23F7-11D9-9DB1-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Date: Fri, 22 Oct 2004 02:54:45 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit On 22 okt 2004, at 02.19, Khosravi, Hormuzd M wrote: > I sent you the entire section so you can just put it in. You don't have > to find any diffs. I have attached it again for your convenience. doesn't quite work like that. but i have put in the changes as far as i can tell. check to make sure i got it right. http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-1.txt > > BTW, where are you at this moment? in the US or Europe? Just curious in > case we need to setup some conference calls. this week in the us - east coast. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 03:08:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06322 for ; Fri, 22 Oct 2004 03:08:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKtkB-0007qw-Ae for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 03:21:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtUr-00017v-Sj; Fri, 22 Oct 2004 03:05:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtLh-0005hC-SN for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 02:56:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05250 for ; Fri, 22 Oct 2004 02:56:28 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKtY5-0007WX-7J for forces-protocol@ietf.org; Fri, 22 Oct 2004 03:09:41 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Fri, 22 Oct 2004 15:12:31 +0800 (CST) Received: from dlg (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with SMTP id ; Fri, 22 Oct 2004 14:48:52 +0800 Message-ID: <00dd01c4b803$806bd620$8401a8c0@dlg> From: "Ligang Dong" To: "Zsolt Haraszti" , "Wang,Weiming" References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408><002d01c4b50b$1ecc9c10$020aa8c0@wwm1><1098102734.1042.134.camel@jzny.localdomain><013101c4b51d$a50761e0$020aa8c0@wwm1><1098134060.1077.446.camel@jzny.localdomain><5.1.0.14.0.20041019093826.0232d418@mail.megisto.com><055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> <1098383190.2883.386.camel@localhost.localdomain> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Fri, 22 Oct 2004 14:51:04 +0800 MIME-Version: 1.0 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 X-Spam-Score: 1.4 (+) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: "Khosravi, Hormuzd M" , "Joel M. Halpern" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, Jamal Hadi Salim , Alan DeKok , Ellen M Deleganes , "Yang, Lily L" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2089428511==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d --===============2089428511== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGksDQoNClRoZSBmb2xsb3dpbmcgaXMgbXkgb3BpbmlvbiBhYm91dCB0aGUgZGViYXRlIHdoZXRo ZXIgbXVsdGljYXN0IChpLmUuLCBtdWx0aXBsZSBhZGRyZXNzaW5nKSBvZiBMRkIgSW5zdGFuY2Ug aXMgcmVxdWlyZWQgb3Igbm90LiANCg0KKDEpIEluIHBhc3Qgc2V2ZXJhbCBtb250aHMsIEkgYW0g ZW5nYWdlZCBpbiB0aGUgaW1wbGVtZW50YXRpb24gb2YgRm9yQ0VTICYgR1JNUC4gVGlsbCBub3cs IGEgYmFzaWMgcHJvdG90eXBlIGlzIGFscmVhZHkgY29uc3RydWN0ZWQuIEFsc28gaXQgaGFzIGJl ZW4gc2hvd24gdG8gc2V2ZXJhbCBndXlzIGluIHRoaXMgcmVzZWFyY2ggZmllbGQuIEZyb20gdGhl IHZpZXcgb2YgaW1wbGVtZW50YXRpb24sIHRoZSBtdWx0aWNhc3Qgb2YgTEZCIGluc3RhbmNlIGlz IGVhc3kuIA0KKDIpIEZ1cnRoZXJtb3JlLCBtdWx0aWNhc3Qgb2YgTEZCIGluc3RhbmNlIGlzIG1v cmUgZWZmaWNpZW50IHRoYW4gdGhlICJ1bmljYXN0IiBhcHByb2FjaCBhbmQgdGhlICJ2aXJ0dWFs SUQiIGFwcHJvYWNoLiBUaGVyZWZvcmUsIHdoeSBub3QgYWRvcHQgbXVsdGljYXN0IG9mIExGQiBp bnN0YW5jZSBpbiB0aGUgcHJvdG9jb2wuIA0KYmVzdCByZWdhcmRzDQpMaWdhbmcNCi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiWnNvbHQgSGFyYXN6dGkiIDx6c29sdEBtb2R1 bGFybmV0LmNvbT4NClRvOiAiV2FuZyxXZWltaW5nIiA8d213YW5nQG1haWwuaHppYy5lZHUuY24+ DQpDYzogIktob3NyYXZpLCBIb3JtdXpkIE0iIDxob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29t PjsgIkpvZWwgTS4gSGFscGVybiIgPGpoYWxwZXJuQG1lZ2lzdG8uY29tPjsgPHJhbS5nb3BhbEBu b2tpYS5jb20+OyAiU3RldmVuIEJsYWtlIChwZXRyaS1tZWF0KSIgPHNsYmxha2VAcGV0cmktbWVh dC5jb20+OyAiQWxhbiBEZUtvayIgPGFsYW4uZGVrb2tAaWR0LmNvbT47ICJKYW1hbCBIYWRpIFNh bGltIiA8aGFkaUB6bnl4LmNvbT47IDxmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc+OyAiRWxsZW4g TSBEZWxlZ2FuZXMiIDxlbGxlbi5tLmRlbGVnYW5lc0BpbnRlbC5jb20+OyAiWWFuZyxMaWx5IEwi IDxsaWx5LmwueWFuZ0BpbnRlbC5jb20+DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMDQg MjoyNiBBTQ0KU3ViamVjdDogUmU6IFtGb3JjZXMtcHJvdG9jb2xdIFJFOiBHRVQvU0VUIGluIG9u ZSBtc2cgPw0KDQoNCj4gV2VpbWluZywNCj4gDQo+IEkgaGF2ZSBhIHZlcnkgaGFyZCB0aW1lIHRv IHJlc29uYXRlIHdpdGggeW91ciBleGFtcGxlcywgYW5kIHRoZXJlZm9yZQ0KPiB3aXRoIHlvdXIg cmVhc29uaW5nLg0KPiANCj4gRm9yIG9uZSwgaWYgeW91IGVuZCB1cCBuZWVkaW5nIDY0ayBMRkJz IGZyb20gdGhlIHNhbWUgY2xhc3MsIEkgdGhpbmsNCj4geW91IG9yIHdlIGRpZCBzb21ldGhpbmcg d3Jvbmcgd2l0aCB0aGUgbW9kZWwuICBTdXJlIHlvdSBtZWFuIGl0IGFuDQo+IGV4dHJlbWUgY2Fz ZSwgYnV0IEkgdGhpbmsgaXQgaXMgYSBtaXNsZWFkaW5nIG9uZS4gIEkgZW52aXNpb24NCj4gcHJh Y3RpY2FsIExGQiBtb2RlbHMgaGF2aW5nIHVwIHRvIGEgZmV3IGh1bmRyZWQgTEZCIGluc3RhbmNl cywgd2hlcmUNCj4gbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIGNsYXNzIHdpbGwgYmUg aW4gdmVyeSBkaWZmZXJlbnQgcm9sZXMNCj4gKGUuZy4sIGEgQ2xhc3NpZmllciBMRkIgc3VwcG9y dGluZyBEaWZmc2VydiB2ZXJzdXMgYSBDbGFzc2lmaWVyDQo+IExGQiBzdXBwb3J0aW5nIElQc2Vj LCBldGMuKSwgaGVuY2UgbW9yZSBvZnRlbiBub3Qgc2hhcmluZyBhbnkgY29uZmlnDQo+IGRhdGEg dGhhbiBzaGFyaW5nIHNvbWUuDQo+IA0KPiBGb3IgdHdvLCBkaXNwbGFjaW5nIHRoZSB0d28gcGFy dHMgb2YgdGhlIExGQiBhZGRyZXNzIChjbGFzcyBJRCBhbmQNCj4gaW5zdGFuY2UgSUQpIGluIHRo ZSBwcm90b2NvbCBpcyBhIG11Y2ggYmlnZ2VyIGNvbmNlcm4gdG8gbWUgdGhhbiB0bw0KPiBhbGxv dyBhZC1ob2Mvc3RhdGUtbGVzcyBtdWx0aWNhc3QgYWRkcmVzc2luZy4gIEl0IHdvdWxkIGJlIGlu IHNvbWUNCj4gc2Vuc2Ugc2ltaWxhciB0byBpZiBpbiB0aGUgSVAgaGVhZGVyIHRoZSAoc3ViLSlu ZXR3b3JrIGFkZHJlc3MgYW5kDQo+IGhvc3QtYWRkcmVzcyBwYXJ0IG9mIHRoZSBJUCBhZGRyZXNz IHdlcmUgcGxhY2VkIGluIGRpc3RhbnQgb2Zmc2V0cy4NCj4gDQo+IEZvciB0aHJlZSwgb24gc3Rh dGUtbGVzcyB2ZXJzdXMgc3RhdGUtZnVsIG11bHRpY2FzdDogIFlvdXIgZXhhbXBsZQ0KPiBiZWxv dyBpcyBiYXNlZCBvbiB0aGUgdmVyeSBleHRyZW1lIGNhc2Ugd2hlbiB5b3UgaGF2ZSBhIFNJTkdM RQ0KPiBjb25maWcgbWVzc2FnZSBhZGRyZXNzZWQgdG8gYSBWRVJZIExBUkdFIG51bWJlciBvZiBM RkIgaW5zdGFuY2VzDQo+IG9mIHRoZSBzYW1lIGNsYXNzLiAgSSBoYXZlIG5vdCB5ZXQgc2VlbiBh IHByYWN0aWNhbCBjYXNlIGZvciB0aGlzDQo+IHNjZW5hcmlvLiAgSSByZWl0ZXJhdGUgdGhhdCBt dWx0aWNhc3QgZ3JvdXBzIGFyZSBub3QgYWQtaG9jLCBhbmQNCj4gdGhlcmUgd2lsbCBiZSB0eXBp Y2FsbHkgYSBsYXJnZSBudW1iZXIgb2YgY29uZmlnIHVwZGF0ZXMgc2VudCB0byBhDQo+IGdyb3Vw IGFmdGVyIHRoZSBncm91cCBpcyBmb3JtZWQuDQo+IA0KPiBSZWdhcmRzLA0KPiBac29sdA0KPiAN Cj4gT24gV2VkLCAyMDA0LTEwLTIwIGF0IDAxOjU2LCBXYW5nLFdlaW1pbmcgd3JvdGU6DQo+ID4g Sm9lbCwNCj4gPiANCj4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gRnJvbTog IkpvZWwgTS4gSGFscGVybiIgPGpoYWxwZXJuQE1FR0lTVE8uY29tPg0KPiA+IFN1YmplY3Q6IFJl OiBbRm9yY2VzLXByb3RvY29sXSBSRTogR0VUL1NFVCBpbiBvbmUgbXNnID8NCj4gPiANCj4gPiAN Cj4gPiA+IEkgZG8gdGhpbmsgdGhhdCB0aGVyZSBtYXkgYmUgdGhvdXNhbmRzIG9mIGluc3RhbmNl cy4NCj4gPiA+IEkgZG8gbm90IHRoaW5rIHRoYXQgdGhpcyByZXF1aXJlcyBtdWx0aXBsZSBhZGRy ZXNzaW5nLg0KPiA+ID4NCj4gPiA+IEkgdGhpbmsgdGhhdCB0aGVyZSBhcmUgc29tZSBpbnRlcmVz dGluZyBjYXNlcyBwcm9tcHRlZCBieSB0aGUgcG9zc2liaWxpdHkNCj4gPiA+IG9mIHZlcnkgbGFy Z2UgbnVtYmVycyBvZiBMRkJzLCBidXQgdGhleSBkbyBub3QgZHJpdmUgbXVsdGlwbGUgYWRkcmVz c2luZy4NCj4gPiA+DQo+ID4gPiBNeSByZWFzb25pbmcgaXMgYmFzZWQgb24gdGhlIGZvbGxvd2lu ZyBwcmVtaXNlLg0KPiA+ID4gRmlyc3RseSwgaWYgdGhlcmUgYXJlIG1hbnkgTEZCaW5zdGFuY2Vz IHMgb2YgYSBjbGFzcywgdGhlbiBpdCBpcyBsaWtlbHkNCj4gPiA+IHRoYXQgbWFueSBmaWVsZHMg b2YgdGhlIExGQiBpbnN0YW5jZXMgd2lsbCBiZSB0aGUgc2FtZSwgYnV0IGl0IGlzIGV4dHJlbWVs eQ0KPiA+ID4gdW5saWtlbHkgdGhhdCBhbGwgZmllbGRzIG9mIHRoZSBMRkIgaW5zdGFuY2VzIHdp bGwgYmUgdGhlIHNhbWUuDQo+ID4gW1dlaW1pbmddVGhhdCdzIGp1c3Qgd2h5IGV4cGxpY2l0IG11 bHRpcHVsIGFkZHJlc3NpbmcgaXMgbmVlZGVkLiBGb3IgdGhlIGNhc2Ugb2YNCj4gPiBmaWVsZHMg b2YgYWxsIExGQmluc2F0bmNlcyBhcmUgdGhlIHNhbWUsIHdlIGNhbiBzaW1wbHkgdXNlIGEgYnJv YWRjYXN0IHRvIGRvIHNvLg0KPiA+IExldCBtZSB0cnkgdG8gc2hvdyBhIHNjZW5hcmlvIHdoeSBt dWx0aXB1bCBhZGRyZXNzaW5nIGlzIG5lZWRlZCBmb3IgZGlmZmVyZW50DQo+ID4gZmllbGRzIGNh c2UuDQo+ID4gDQo+ID4gRmlyc3RseSwgYmVjYXVzZSB3ZSBoYXZlIGFzc3VtZWQgdGhlIDE2Yml0 IGluc2F0bmNlIElkIGlzIG5vdCBlbm91Z2gsIHdlIGNhbg0KPiA+IHJlYXNvbmFibHkgYXNzbXVl IHRoZXJlIGlzIGEgY2FzZSB3aGVyZSB0aGVyZSBhcmUgNjRrIG9yIG1vcmUgaW5zdGFuY2VzIChz YXkNCj4gPiA2NGspLiBGdXJ0aGVyLCB3ZSBzdXBwb3NlIElkMSB0byBJZDMyayBuZWVkIHRvIGNv bmZpZyBwYXJhbWV0ZXIgMSwgSWQoMzJrKzEpIHRvDQo+ID4gSWQgNjRrIHRvIHNldCBwYXJhbWV0 ZXIyLg0KPiA+IA0KPiA+IFRoZW4sIGJ5IHVzaW5nIHNpbmdsZSBpbnN0YW5jZSBhZGRyZXNzaW5n LCB0aGUgcHJvdG9jb2wgYmVjb21lcyBob3JyaWJsZSwgZWl0aGVyDQo+ID4gdXNpbmcgb25lIG1l c3NhZ2Ugb3IgdXNpbmcgc2VwYXJhdGUgbWVzc2FnZXMuIEkganVzdCBzaG93IHRoZSBvbmUgbWVz c2FnZSBjYXNlLg0KPiA+IFRoZSBtZXNzYWdlIGZvcm1hdCB3b3VsZCBsaWtlIGxpa2U6DQo+ID4g DQo+ID4gTXNnaGRyDQo+ID4gTEZCc2VsZWN0DQo+ID4gTEZCQ2xhc3NJRA0KPiA+IEluc3RhbmNl IElEMQ0KPiA+IFBhcmFtZXRlcjENCj4gPiBJbnN0YW5jZSBJRDINCj4gPiBQYXJhbWV0ZXIxDQo+ ID4gLi4uDQo+ID4gLi4uDQo+ID4gSW5zdGFuY2UgSUQgMzJrDQo+ID4gUGFyYW1ldGVyMQ0KPiA+ IEluc2F0bmNlIElEICgzMmsrMSkNCj4gPiBQYXJhbWV0ZXIyDQo+ID4gLi4uLg0KPiA+IEluc3Rh bmNlIElEIDY0aw0KPiA+IFBhcmFtZXRlciAyDQo+ID4gDQo+ID4gUmVtZW1iZXIgd2UgdGhlbiBo YXZlIDY0ayBwYWlyIG9mIGluc3RhbmNlIGFuZCBwYXJhbWV0ZXIgaW4gdGhlIHByb3RvY29sIHRl eHQuDQo+ID4gSW4gc29tZSBjYXNlcywgSSdtIGp1c3Qgd29ycmllZCB0aGlzIG1ha2UgcHJvdG9j b2wgdW5wcmFjdGljYWwuDQo+ID4gDQo+ID4gQnkgdXNpbmcgbXVsdGlwdWwgYWRkcmVzc2luZywg dGhlIG9ubHkgdGV4dCBpcyBhczoNCj4gPiBNc2doZHINCj4gPiBMRkJzZWxlY3QNCj4gPiBMRkJD bGFzc0lEDQo+ID4gSW5zdGFuY2UgSUQxIHRvIElEIDMyaw0KPiA+IFBhcmFtZXRlcjENCj4gPiBJ bnN0YW5jZSBJRCAoMzJrKzEpIHRvIElEIDY0aw0KPiA+IFBhcmFtZXRlcjINCj4gPiANCj4gPiBC eSB1c2luZyBtdWx0aWNhc3Qgc2NoZW1lIHN1cHBvc2VkIGJ5IFpzb2x0LCBJIHN1cHBvc2Ugd2Ug bmVlZCBmb2xsb3dpbmcgc3RlcHM6DQo+ID4gMS4gc2VuZCBhIEZFIGF0dHJpYnV0ZSB0byBGRSBv YmplY3QgdG8gc2V0dXAgYSB2aXJ0dWFsSUQxIGZvciBJbnN0YW5jZSAxIHRvDQo+ID4gSW5zdGFu Y2UgMzJrDQo+ID4gMi4gc2VuZCBhIEZFIGF0dHJpYnV0ZSB0byBGRSBvYmplY3QgdG8gc2V0dXAg YSB2aXJ0dWFsSUQyIGZvciBJbnN0YW5jZSAoMzJrKzEpDQo+ID4gdG8gSW5zdGFuY2UgNjRrDQo+ ID4gMy4gY29uZmlnOg0KPiA+IE1zZ2hkcg0KPiA+IExGQnNlbGVjdA0KPiA+IExGQkNsYXNzSUQN Cj4gPiBWaXJ0dWFsIElEMQ0KPiA+IFBhcmFtZXRlcjENCj4gPiBWaXJ0dWFsIElEMg0KPiA+IFBh cmFtZXRlcjINCj4gPiA0LiBzZW5kIGEgbWVzc2FnZSB0byByZWxlYXNlIHZpcnR1YWwgSUQxDQo+ ID4gNS4gc2VuZCBhIG1lc3NhZ2UgdG8gcmVsZWFzZSB2aXJ0dWFsIElEMg0KPiA+IA0KPiA+IEkg Y2FuIHNlZSB0aGUgYWR2YXRhZ2Ugb2YgYWJvdmUgZXhwbGljaXQgbXVsdGlwdWwgYWRkcmVzc2lu ZyBzY2hlbWUgdmVyeQ0KPiA+IGNsZWFybHkuDQo+ID4gDQo+ID4gPiBUaGUgc2ltcGxlc3QgY2Fz ZSB0byB1bmRlcnN0YW5kIHdoZW4gb25lIHdvdWxkIG5lZWQgdG8gc2V0dXAgYWxsIHRob3NlIExG QnMNCj4gPiA+IGF0IG9uY2UgaXMgaW4gYSBwb3dlciByZWNvdmVyeSBzaXR1YXRpb24gICh0aGUg RkUgbG9zdCBwb3dlciwgdGhlbg0KPiA+ID4gcmVjb3ZlcmVkIHRvIGFuIGVtcHR5IHN0YXRlLikg IFRoZSBDRSBuZWVkcyB0byBzZW5kIHRoZSBjb25maWd1cmF0aW9uDQo+ID4gPiBpbmZvcm1hdGlv biB0byB0aGUgRkUuDQo+ID4gW1dlaW1pbmddWWVzLCB0aGF0J3MgdGhlIG9uZSBjYXNlIGJ1dCBu b3QgdGhlIG9ubHkuDQo+ID4gDQo+ID4gPiBTZWNvbmRseSwgSSBiZWxpZXZlIHRoYXQgdHJhbnNh Y3Rpb24gY291bnQgaXMgbXVjaCBtb3JlIGltcG9ydGFudCB0aGFuIGRhdGENCj4gPiA+IHZvbHVt ZS4gIFRoZSBGRSBpcyBnb2luZyB0byBoYXZlIHRvIHNldCBldmVyeSBmaWVsZCBpbiBldmVyeSBM RkIuICBFbmNvZGluZw0KPiA+ID4gaXMgbm90IGdvaW5nIHRvIGNoYW5nZSB0aGF0Lg0KPiA+IFtX ZWltaW5nXUknbSBub3Qgc3VyZSBpZiB5b3UgbWVhbiBmb3IgZXZlcnkgb3BlcmF0aW9uLCB3ZSBz aG91bGQgbWFpbnRhaW4gYQ0KPiA+IHRyYW5zYWN0aW9uIGNvdW50LiBJZiBpcywgdGhlbiBJIGhh dmUgdG8gc2F5IG91ciBjdXJyZW50IG9uZSBtZXNzYWdlIHdpdGgNCj4gPiBtdWx0aXBsZSBPcGVy YXRpb24gZGVmaW5pdGlvbnMgaGFzIGFscmVhZHkgYmUgYWdhaW5zdCB0aGUgcmVxdWlyZW1lbnQu IE15DQo+ID4gb3BpbmlvbiBpcyB0cmFuc2FjdGlvbiBtYWludGVuYW5jZSBpcyBtb2RlcmF0ZSwg d2hpbGUgbXVsdGljYXN0IGFuZCBtdWx0aXBsZQ0KPiA+IG9wZXJhdGlvbiBhcmUgbW9yZSBpbXBv cnRhbnQuDQo+ID4gDQo+ID4gPiBHaXZlbiB0aGF0IHRoZXJlIGFyZSBkaXN0aW5jdCB2YWx1ZXMg aW4gZWFjaCBMRkIgaW5zdGFuY2UsIHRoZXJlIG11c3QgYmUgYW4NCj4gPiA+IG9wZXJhdGlvbiBh Z2FpbnN0IGVhY2ggTEZCIGluc3RhbmNlLg0KPiA+IEkgZG9uJ3QgdGhpbmsgbXVsdGljYXN0IHdp bGwgbG9vc2Ugb3BlcmF0aW9uIGluZGl2aWR1YWxpdHkuDQo+ID4gPg0KPiA+ID4gVGhlIG1hcmdp bmFsIGdhaW4gZnJvbSBoYXZpbmcgYSBzaW5nbGUgdHJhbnNhY3Rpb24gdG8gdXBkYXRlIHRoZSBp ZGVudGljYWwNCj4gPiA+IGZpZWxkcywgYW5kIHRoZW4gaW5kaXZpZHVhbCB0cmFuc2FjdGlvbnMg Zm9yIHRoZSBkaXN0aW5jdCBmaWVsZHMgaXMgdmVyeQ0KPiA+ID4gc21hbGwuICBJdCBkb2VzIG5v dCByZWR1Y2UgdGhlIG51bWJlciBvZiBJT3Mgb3IgdGhlIGNvcmUgdHJhbnNhY3Rpb24gcmF0ZS4N Cj4gPiBbV2VpbWluZ11BdCBsZWFzdCBpdCBzYXZlcyBiaXRzIGdyZWF0bHkgYW5kIG1ha2VzIHBy b3RvY29sIHByYWN0aWNhbC4gUmVtZW1iZXINCj4gPiB0aGUgY2FwYWJpbGl0eSBiZXR3ZWVuIENF IGFuZCBGRSBhcmUgcXVpdGUgbGltaXRlZCwgZXNwZWNpYWxseSBpbiBtdWxpLWhvcA0KPiA+IEZv ckNFUyBhcHBsaWNhdGlvbi4NCj4gPiA+DQo+ID4gPiBJZiBpdCBpcyBkZXNpcmVkIHRvIG9wdGlt aXplIGZvciB0aGlzIGNhc2UsIHdlIG1heSB3YW50IHRvIGludHJvZHVjZSAoaW4gYQ0KPiA+ID4g ZnV0dXJlIHZlcnNpb24gb2YgdGhlIHByb3RvY29sKSBzb21lIGtpbmQgb2YgYmxvY2sgY2hlY2tw b2ludCAvIHJlc3RhcnQNCj4gPiA+IG1lY2hhbmlzbS4gIFRoZSBDRSB3b3VsZCByZWNvcmQgaXRz IGZ1bGwgc3RhdGUgYWJvdXQgdGhlIEZFLCBhbmQgdGhlbiBhc2sNCj4gPiA+IHRoZSBGRSBmb3Ig YSBkdW1wIHN1aXRhYmxlIGZvciByZXN0b3JhbCBvZiB0aGUgRkUgc3RhdGUuICBVcG9uIHJlc3Rh cnQsIHRoZQ0KPiA+ID4gQ0Ugd291bGQgcmVidWlsZCBpdHMgc3RhdGUgZnJvbSBpdHMgc3RvcmVk IHJlcHJlc2VudGF0aW9uLCBhbmQgd291bGQgc2hpcA0KPiA+ID4gdGhlIGR1bXAgYmFjayB0byB0 aGUgRkUgdG8gZW5hYmxlIGVmZmljaWVudCByZWJ1aWxkaW5nIHRoZXJlLiAgSSBjYW4gc2VlDQo+ ID4gPiBzaWduaWZpY2FudCB2YWx1ZSBpbiBzdWNoIGEgbWVjaGFuaXNtLiAgSSBkbyBub3QgaG93 ZXZlciBzZWUgYSBuZWVkIHRvDQo+ID4gPiBpbmNsdWRlIHRoaXMgaW4gdGhlIGZpcnN0IGRlbGl2 ZXJhYmxlIG9mIHRoZSBwcm90b2NvbC4NCj4gPiBbV2VpbWluZ11JIHN1cHBvc2UgdGhpcyBpcyBv bmx5IGZvciByZXN0YXJ0IGNhc2UsIEkgY2FuIHNlZSBtYW55IGNhc2VzIHdoZXJlDQo+ID4gbXVs dGlwbGUgYWRkcmVzc2luZyBjYW4gYXBwbHksIHN1Y2ggYXMgZGVsZXRlLCBjaGFuZ2Ugb2YgTEZC IHBhcmFtZXRlciwgbG9hZCBhbmQNCj4gPiB1bmxvYWQgb2YgTEZCcywgZXRjLiBBbmQgYWxzbyBJ IHRoaW5rIHRoZSBzY2hlbWUgYWJvdmUgaXMgbXVjaCBtb3JlIGNvbXBsZXggdGhhbg0KPiA+IG11 bHRpcGxlIGFkZHJlc3NpbmcuIFNvLCBteSBjb25jbHVzaW9uIGlzLCB3aXRoIGEgbGl0dGxlIGJp dCBleHBhbnNpb24sIHdlIGNhbg0KPiA+IGdhaW4gbXVjaCwgdGhlbiB3aHkgbm90IHdlIGFkcG90 IGl0Pw0KPiA+IA0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBXZWltaW5nDQo+ID4gPg0KPiA+ID4g WW91cnMsDQo+ID4gPiBKb2VsIE0uIEhhbHBlcm4NCj4gPiANCj4gLS0gDQo+IFpzb2x0IEhhcmFz enRpICAgICAgICAgICAgICAgIFBob25lOiAgKzEgOTE5LTc2NS0wMDI3LzIwMTcNCj4gTW9kdWxh ciBOZXR3b3JrcyAgICAgICAgICAgICAgTW9iaWxlOiAgICAgICsxIDkxOS01MjItMjMzNw0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFbWFpbDogIHpzb2x0QG1vZHVsYXJuZXQuY29t DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gRm9yY2VzLXByb3RvY29sIG1haWxpbmcgbGlzdA0KPiBGb3JjZXMtcHJvdG9jb2xAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzLXBy b3RvY29sDQo+IA== --===============2089428511== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============2089428511==-- From forces-protocol-bounces@ietf.org Fri Oct 22 03:35:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08730 for ; Fri, 22 Oct 2004 03:35:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKu9q-0008PC-7C for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 03:48:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtsr-0002d8-RB; Fri, 22 Oct 2004 03:30:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtnh-0000FH-Fr for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 03:25:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07706 for ; Fri, 22 Oct 2004 03:25:23 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKu0P-0008C6-8o for forces-protocol@ietf.org; Fri, 22 Oct 2004 03:38:36 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9M7PP06004355; Fri, 22 Oct 2004 07:25:25 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9M7SKmf013579; Fri, 22 Oct 2004 07:28:25 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102200244703344 ; Fri, 22 Oct 2004 00:24:47 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 00:24:46 -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 Subject: RE: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Date: Fri, 22 Oct 2004 00:24:36 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0257920C@orsmsx408> Thread-Topic: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Thread-Index: AcS4BAq95/1sNV+0RnWp7QYMJkzMdAABBxQQ From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 22 Oct 2004 07:24:46.0838 (UTC) FILETIME=[35669160:01C4B808] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Avri, This looks good, Thanks! Hormuzd -----Original Message----- From: avri@acm.org [mailto:avri@acm.org]=20 Sent: Thursday, October 21, 2004 11:55 PM To: Khosravi, Hormuzd M Cc: Weiming Wang; forces-protocol@ietf.org; Ligang Dong; Robert Haas; ram.gopal@nokia.com; Jamal Hadi Salim Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt On 22 okt 2004, at 02.19, Khosravi, Hormuzd M wrote: > I sent you the entire section so you can just put it in. You don't have > to find any diffs. I have attached it again for your convenience. doesn't quite work like that. but i have put in the changes as far as i can tell. check to make sure=20 i got it right. http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-1.txt > > BTW, where are you at this moment? in the US or Europe? Just curious in > case we need to setup some conference calls. this week in the us - east coast. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 03:55:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09916 for ; Fri, 22 Oct 2004 03:55:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKuT9-0000OM-04 for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 04:08:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKu65-0007cT-UX; Fri, 22 Oct 2004 03:44:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKu1z-0005rc-25 for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 03:40:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09121 for ; Fri, 22 Oct 2004 03:40:09 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKuEj-0008UP-0l for forces-protocol@ietf.org; Fri, 22 Oct 2004 03:53:22 -0400 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9M7d7pA238074; Fri, 22 Oct 2004 03:39:08 -0400 Received: from sihl.zurich.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9M7eTFD125904; Fri, 22 Oct 2004 03:40:30 -0400 Received: from [9.145.135.216] (sig-9-145-135-216.de.ibm.com [9.145.135.216]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA50554; Fri, 22 Oct 2004 09:39:01 +0200 Message-ID: <4178B909.3010904@zurich.ibm.com> Date: Fri, 22 Oct 2004 09:38:49 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E02F9A085@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02F9A085@orsmsx408> X-Spam-Score: 1.5 (+) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Weiming Wang Subject: [Forces-protocol] Re: Applying changes to Section 6 (Protocol Messages) X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0760567356==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af This is a multi-part message in MIME format. --===============0760567356== Content-Type: multipart/alternative; boundary="------------060608090804040309020305" This is a multi-part message in MIME format. --------------060608090804040309020305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e5.ny.us.ibm.com id i9M7d7pA238074 Content-Transfer-Encoding: quoted-printable Hormuzd, Could you please pass the token on section 6 together with your latest=20 version so I can start editing it ? Thanks, -Robert Khosravi, Hormuzd M wrote: > Robert, > =20 > As I said, your note mostly looks...I have put some more comments below= ... > (It would help a lot if you start defining the FE, Protocol LFBs...) > -----------------------------------------------------------------------= - > From: Robert Haas [mailto:rha@zurich.ibm.com] > > All: below is a rough list of changes and pending issues regarding=20 > section 6. Please review. > > 6.1.1 Association: The CE could obtain the HBI with a=20 > Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg=20 > strcutrue, we have to remove HBI from the Assoc Setup msg. [Agreed,=20 > this would be part of ProtocolLFB even if it is in this message]=20 > > 6.1.2 How has the srcID=3D0 case been handled in the interop tests ? I= s=20 > this really feasible ? [Yes it worked fine during Interop]=20 > > 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into=20 > the FEProtocolLFB. [Agreed it would be in some LFB, but not sure=20 > which LFB this would be part of...?]=20 > > 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note=20 > that for the sake of symmetry, we should introduce a CEProtocolLFB. =20 > [Sure, why dont you start defining some of these objects...then we can=20 > discuss more in detail]=20 > > 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become=20 > settable attributes in the FEProtocolLFB. [Yes, these messages will=20 > be part of Events or Config...we need to specify this]=20 > > 6.7 HB remains as is. [Agreed]=20 > > In summary, we have the following operations defined for each message=20 > type ( I broke the table into 3 parts): > [looks good!]=20 > OPERATION APPLICABLE MESSAGE TYPES > > Assoc-Setup Assoc-Setup-Resp Assoc-Teardown Heartbeat > > no operations > defined > > > Query Query-Resp Config Config-Resp > SET, DEL, UPDATE x x > GET x x > EV_S, EV_U x x > > (for event subscribe/unsubscribe) > > > Packet-Redir > > PAYLOAD x > > > Event-Notif Event-Notif-Resp > EVENT x x > > Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we=20 > have each time only one operation. Looks a bit redundant. Ideas ? =20 > [These are all very different, lets leave them as is, its not=20 > necessary to have multiple operations in all messages]=20 > > Regards, > -Robert --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------060608090804040309020305 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hormuzd,
Could you please pass the token on section 6 together with your latest version so I can start editing it ?
Thanks,
-Robert

Khosravi, Hormuzd M wrote:
Robert,
 
As I said, your note mostly looks...I have put some more comments below...
(It would help a lot if you start defining the FE, Protocol LFBs...)
From: Robert Haas [mailto:rha@zurich.ibm.com]

All: below is a rough list of changes and pending issues regarding section 6. Please review.

 6.1.1 Association: The CE could obtain the HBI with a Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg strcutrue, we have to remove HBI from the Assoc Setup msg.  [Agreed, this would be part of ProtocolLFB even if it is in this message] 

 6.1.2 How has the srcID=0 case been handled in the interop tests ? Is this really feasible ?  [Yes it worked fine during Interop] 

 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into the FEProtocolLFB.  [Agreed it would be in some LFB, but not sure which LFB this would be part of...?] 

 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note that for the sake of symmetry, we should introduce a CEProtocolLFB.  [Sure, why dont you start defining some of these objects...then we can discuss more in detail] 

 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become settable attributes in the FEProtocolLFB.  [Yes, these messages will be part of Events or Config...we need to specify this] 

 6.7 HB remains as is.  [Agreed] 

In summary, we have the following operations defined for each message type ( I broke the table into 3 parts):
 [looks good!] 
OPERATION       APPLICABLE MESSAGE TYPES

                Assoc-Setup  Assoc-Setup-Resp Assoc-Teardown Heartbeat

no operations
defined


                Query  Query-Resp  Config  Config-Resp
SET, DEL, UPDATE                     x          x
GET               x         x
EV_S, EV_U                           x          x

(for event subscribe/unsubscribe)


                Packet-Redir

PAYLOAD            x


                Event-Notif  Event-Notif-Resp
EVENT              x                x

Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we have each time only one operation. Looks a bit redundant. Ideas ?  [These are all very different, lets leave them as is, its not necessary to have multiple operations in all messages] 

Regards,
-Robert

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------060608090804040309020305-- --===============0760567356== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0760567356==-- From forces-protocol-bounces@ietf.org Fri Oct 22 04:39:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12595 for ; Fri, 22 Oct 2004 04:39:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKvAP-00015q-T2 for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 04:52:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKuvg-00038E-TW; Fri, 22 Oct 2004 04:37:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKuun-0002eS-4l for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 04:36:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12381 for ; Fri, 22 Oct 2004 04:36:46 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKv7X-00011M-Ih for forces-protocol@ietf.org; Fri, 22 Oct 2004 04:50:00 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9M8ap06031953; Fri, 22 Oct 2004 08:36:51 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9M8dkmf017003; Fri, 22 Oct 2004 08:39:51 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102201361210924 ; Fri, 22 Oct 2004 01:36:12 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 01:36:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4B812.2ECFB6C7" Date: Fri, 22 Oct 2004 01:35:49 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0257920D@orsmsx408> X-MS-Has-Attach: yes Thread-Topic: Section 6 update Thread-Index: AcS4CjvLuaKAcbmxQMyL3bgFjajptgABs6oQ From: "Khosravi, Hormuzd M" To: "Robert Haas" X-OriginalArrivalTime: 22 Oct 2004 08:36:11.0924 (UTC) FILETIME=[2F82CD40:01C4B812] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.7 (/) X-Scan-Signature: 0dcdaa57c570c86b2e4beb0ed476393e Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Weiming Wang Subject: [Forces-protocol] Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: a233275913d1d34f257cf9b4f3544846 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B812.2ECFB6C7 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4B812.2ECFB6C7" ------_=_NextPart_002_01C4B812.2ECFB6C7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Robert, All =20 Here you go...I have updated sections 6.1, 6.3, 6.6 (remove), 6.7 = (same). I have directly used the text that Jamal sent out wherever = applicable. You can update sections 6.2, 6.4, 6.5 -> however, I would check with = Weiming first as courtesy since he is working on these sections. =20 BTW, there were lots of things in the todo list I sent out... =20 Header Section - Jamal/Robert/Weiming? Protocol LFB - Robert/Others? FE LFB - Robert/Others? CE LFB - ? State Machine for Protocol - Ligang (taken) =20 Will you be working on any of these ?? =20 Pls do let us know...I will start working on whatever hasn't been = claimed by tomorrow morning my time. =20 Thanks Hormuzd =20 ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Friday, October 22, 2004 12:39 AM To: Khosravi, Hormuzd M Cc: Ligang Dong; hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com; = Weiming Wang; forces-protocol@ietf.org Subject: Re: Applying changes to Section 6 (Protocol Messages) =20 Hormuzd, Could you please pass the token on section 6 together with your latest = version so I can start editing it ? Thanks, -Robert Khosravi, Hormuzd M wrote: Robert, =20 As I said, your note mostly looks...I have put some more comments = below... (It would help a lot if you start defining the FE, Protocol LFBs...) ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 All: below is a rough list of changes and pending issues regarding = section 6. Please review. 6.1.1 Association: The CE could obtain the HBI with a = Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg = strcutrue, we have to remove HBI from the Assoc Setup msg. [Agreed, = this would be part of ProtocolLFB even if it is in this message]=20 6.1.2 How has the srcID=3D0 case been handled in the interop tests ? Is = this really feasible ? [Yes it worked fine during Interop]=20 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into the = FEProtocolLFB. [Agreed it would be in some LFB, but not sure which LFB = this would be part of...?]=20 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note = that for the sake of symmetry, we should introduce a CEProtocolLFB. = [Sure, why dont you start defining some of these objects...then we can = discuss more in detail]=20 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become settable = attributes in the FEProtocolLFB. [Yes, these messages will be part of = Events or Config...we need to specify this]=20 6.7 HB remains as is. [Agreed]=20 In summary, we have the following operations defined for each message = type ( I broke the table into 3 parts): [looks good!]=20 OPERATION APPLICABLE MESSAGE TYPES Assoc-Setup Assoc-Setup-Resp Assoc-Teardown Heartbeat no operations defined Query Query-Resp Config Config-Resp SET, DEL, UPDATE x x GET x x EV_S, EV_U x x (for event subscribe/unsubscribe) Packet-Redir PAYLOAD x Event-Notif Event-Notif-Resp EVENT x x Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we = have each time only one operation. Looks a bit redundant. Ideas ? = [These are all very different, lets leave them as is, its not necessary = to have multiple operations in all messages]=20 Regards, -Robert --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha ------_=_NextPart_002_01C4B812.2ECFB6C7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Robert, All

 

Here you go…I have updated = sections 6.1, 6.3, 6.6 (remove), 6.7 (same). I have directly used the text that = Jamal sent out wherever applicable.

You can update sections 6.2, 6.4, = 6.5 -> however, I would check with Weiming first as courtesy since he is = working on these sections.

 

BTW, there were lots of things in = the todo list I sent out…

 

Header Section - = Jamal/Robert/Weiming?

Protocol LFB - = Robert/Others?

FE LFB - = Robert/Others?

CE LFB - ?

State Machine for Pro= tocol – Ligang (taken)

 

Will you be working on any of these = ??

 

Pls do let us know…I will = start working on whatever hasn’t been claimed by tomorrow morning my = time.

 

Thanks

Hormuzd

 

From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Friday, October 22, = 2004 12:39 AM
To: Khosravi, Hormuzd = M
Cc: Ligang Dong; = hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com; Weiming Wang; = forces-protocol@ietf.org
Subject: Re: Applying = changes to Section 6 (Protocol Messages)

 

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

Khosravi, Hormuzd M wrote:

Robert,

 

As I said, your note mostly = looks...I have put some more comments below...

(It would help a = ;lot if you start defining the FE, Pro= tocol LFBs...)

From: Robert Haas [mailto:rha@zurich.ibm.com] =


All: below is a rough list of changes and pending issues regarding = section 6. Please review.

 6.1.1 Association: The CE could obtain the HBI with a Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg = strcutrue, we have to remove HBI from the Assoc Setup msg.  [Agreed, this would be part of ProtocolLFB even if it = is in this message] 

 6.1.2 How has the srcID=3D0 case been handled in the interop tests = ? Is this really feasible ?  [Yes it = worked fine during Interop] 

 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into = the FEProtocolLFB.  [Agreed it would be in some LFB, = but not sure which LFB this would be part of...?] 

 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. = Note that for the sake of symmetry, we should introduce a CEProtocolLFB.  [Sure, why dont you start defining some of these objects...then we can discuss more in detail] 

 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become = settable attributes in the FEProtocolLFB.  [Yes,= these messages will be part of Events or Config...we need to specify = this] 

 6.7 HB remains as is.  = [Agreed] 

In summary, we have the following operations defined for each message = type ( I broke the table into 3 parts):
 [looks = good!] 
OPERATION       APPLICABLE MESSAGE TYPES

       =          Assoc-Setup  Assoc-Setup-Resp = Assoc-Teardown Heartbeat

no operations
defined


       =          Query  Query-Resp  Config  = Config-Resp
SET, DEL, UPDATE             &= nbsp;       x          = x
GET           = ;    x         x
EV_S, EV_U             &= nbsp;             = x          = x

(for event = subscribe/unsubscribe)


       =          Packet-Redir

PAYLOAD          &= nbsp; x


                Event-Notif  Event-Notif-Resp
EVENT              x            =     x

Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we = have each time only one operation. Looks a bit redundant. Ideas ?  [These are all very different, lets leave them as is, its not necessary = to have multiple operations in all messages] 

Regards,
-Robert



-- 
Robert Haas
IBM Zurich Research =
Laboratory
S=E4umerstrasse =
4
CH-8803 =
R=FCschlikon/Switzerland
phone +41-1-724-8698=A0 fax +41-1-724-8578=A0 =
http://www.zurich.ibm.com/~rha
------_=_NextPart_002_01C4B812.2ECFB6C7-- ------_=_NextPart_001_01C4B812.2ECFB6C7 Content-Type: text/plain; name="section-6-update.txt" Content-Transfer-Encoding: base64 Content-Description: section-6-update.txt Content-Disposition: attachment; filename="section-6-update.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Ni4gIFByb3RvY29sIE1lc3NhZ2VzDQoNClRoZSBnZW5lcmFsIHN0cnVjdHVyZSBvZiBtb3N0IG1l c3NhZ2VzIGlzIGFzIGZvbGxvd3MgaW4gQk5GIGZvcm1hdDoNCg0KUEwgbGV2ZWwgUERVIDogPSBN QUlOSERSPExGQnNlbGVjdD4rIA0KTEZCc2VsZWN0IDo9IExGQkNMQVNTSUQgTEZCSW5zdGFuY2Ug PE9QRVI+Kw0KT1BFUjo9IDxPUEVSQVRJT04gWzxwYXRoLWRhdGE+XSo+Kw0KDQotIE1BSU5IRFIg ZGVmaW5lcyBtc2cgdHlwZSwgVGFyZ2V0IEZFL0NFIElEIGV0Yy4NCnRoZSBNQUlOSERSIGFsc28g ZGVmaW5lcyB0aGUgY29udGVudC4gQXMgYW4gZXhhbXBsZSB0aGUgY29udGVudCBvZg0KYSAiY29u ZmlnIiBtZXNzYWdlIHdvdWxkIGJlIGRpZmZlcmVudCBmcm9tIGFuICJhc3NvY2lhdGlvbiIgbWVz c2FnZS4NCi0gTEZCQ0xBU1NJRCBpcyBhIDMyIGJpdCB1bmlxdWUgaWRlbnRpZmllciBwZXIgTEZC IGNsYXNzIGRlZmluZWQNCmF0IGNsYXNzIGNyZWF0aW9uIHRpbWUuDQotIExGQkluc3RhbmNlIGlz IGEgMzIgYml0IHVuaXF1ZSBpbnN0YW5jZSBpZGVudGlmaWVyIG9mIGFuIExGQiBjbGFzcw0KLSBP UEVSQVRJT04gaXMgb25lIG9mIHtBREQsREVMLGV0Yy59IGRlcGVuZGluZyBvbiB0aGUgbWVzc2Fn ZSB0eXBlDQoNClRoZSBwYXRoLWRhdGEgaWRlbnRpZmllcyB0aGUgZXhhY3QgZWxlbWVudCB0YXJn ZXRlZC4NCkl0IG1heSBoYXZlIHplcm8gb3IgbW9yZSBkYXRhIHZhbHVlcyBhc3NvY2lhdGVkLg0K DQpJbiBzdW1tYXJ5IHRoaXMgYXBwcm9hY2ggaGFzIHRoZSBmb2xsb3dpbmcgY2hhcmFjdGVyaXN0 aWM6DQotIHRoZXJlIGNhbiBiZSBvbmUgb3IgbW9yZSBMRkIgQ2xhc3MgKyBJbnN0YW5jZUlkIGNv bWJvDQp0YXJnZXRlZCBpbiBhIG1lc3NhZ2UgKGJhdGNoKQ0KLSBUaGVyZSBjYW4gb25lIG9yIG1v cmUgb3BlcmF0aW9uIG9uIGFuIGFkZHJlc3NlZCBMRkIgDQpjbGFzc2lkK2luc3RhbmNlaWQgY29t Ym8oYmF0Y2gpIA0KLSBUaGVyZSBjYW4gYmUgb25lIG9yIG1vcmUgcGF0aCB0YXJnZXRzIHBlciBv cGVyYXRpb24gKGJhdGNoKQ0KLSBwYXRocyBtYXkgaGF2ZSB6ZXJvIG9yIG1vcmUgZGF0YSB2YWx1 ZXMgYXNzb2NpYXRlZCAoZmxleGliaWxpdHkNCmFuZCBvcGVyYXRpb24gc3BlY2lmaWMpDQoNCkl0 IHNob3VsZCBiZSBub3RlZCB0aGF0IHRoZSBhYm92ZSBpcyBvcHRpbWl6ZWQgZm9yIHRoZSBjYXNl IG9mIGENCmEgc2luZ2xlIGNsYXNzaWQraW5zdGFuY2UgdGFyZ2V0aW5nLiBUbyB0YXJnZXQgbXVs dGlwbGUgaW5zdGFuY2VzDQp3aXRoaW4gdGhlIHNhbWUgY2xhc3MsIG11bHRpcGxlIExGQnNlbGVj dCBhcmUgbmVlZGVkLiANCg0KDQo2LjEgIEFzc29jaWF0aW9uIE1lc3NhZ2VzDQoNCiAgIFRoZSBG b3JDRVMgQXNzb2NpYXRpb24gbWVzc2FnZXMgYXJlIHVzZWQgdG8gZXN0YWJsaXNoIGFuZCB0ZWFy ZG93bg0KICAgYXNzb2NpYXRpb25zIGJldHdlZW4gRkVzIGFuZCBDRXMuDQoNCjYuMS4xICBBc3Nv Y2lhdGlvbiBTZXR1cCBNZXNzYWdlDQoNCiAgIFRoaXMgbWVzc2FnZSBpcyBzZW50IGJ5IHRoZSBG RSB0byB0aGUgQ0UgdG8gc2V0dXAgYSBGb3JDRVMNCiAgIGFzc29jaWF0aW9uIGJldHdlZW4gdGhl bS4gIFRoaXMgbWVzc2FnZSBjb3VsZCBhbHNvIGJlIHVzZWQgYnkgQ0VzIHRvDQogICBqb2luIGEg Rm9yQ0VTIE5FLCBob3dldmVyIENFLXRvLUNFIGNvbW11bmljYXRpb24gaXMgbm90IGNvdmVyZWQg YnkNCiAgIHRoaXMgcHJvdG9jb2wuDQoNCiAgIE1lc3NhZ2UgdHJhbnNmZXIgZGlyZWN0aW9uOg0K ICAgICAgRkUgdG8gQ0UNCiAgIE1lc3NhZ2UgSGVhZGVyOg0KICAgICAgVGhlIE1lc3NhZ2UgVHlw ZSBpbiB0aGUgaGVhZGVyIGlzIHNldCBNZXNzYWdlVHlwZT0gJ0Fzc29jaWF0aW9uDQogICAgICBT ZXR1cCcuICBUaGUgQUNLIGZsYWcgaW4gdGhlIGhlYWRlciBpcyBpZ25vcmVkLCBiZWNhdXNlIHRo ZSBzZXR1cA0KICAgICAgbWVzc2FnZSB3aWxsIGFsd2F5cyBleHBlY3QgdG8gZ2V0IGEgcmVzcG9u c2UgZnJvbSB0aGUgbWVzc2FnZQ0KICAgICAgcmVjZWl2ZXIgKENFKSB3aGV0aGVyIHRoZSBzZXR1 cCBpcyBzdWNjZXNzZnVsIG9yIG5vdC4gIFRoZSBTcmMgSUQNCiAgICAgIChGRSBJRCkgbWF5IGJl IHNldCB0byBPIGluIHRoZSBoZWFkZXIgd2hpY2ggbWVhbnMgdGhhdCB0aGUgRkUNCiAgICAgIHdv dWxkIGxpa2UgdGhlIENFIHRvIGFzc2lnbiBhIEZFIElEIGZvciB0aGUgRkUgaW4gdGhlIHNldHVw DQogICAgICByZXNwb25zZSBtZXNzYWdlLg0KICAgTWVzc2FnZSBib2R5Og0KICAgICAgVGhlIHNl dHVwIG1lc3NhZ2UgYm9keSBjb25zaXN0cyBvZiBMRkJTZWxlY3QgJiBGRSBOYW1lIFRMViwgdGhl IGZvcm1hdCBvZg0KICAgICAgd2hpY2ggaXMgYXMgZm9sbG93czoNCg0KbWFpbiBoZHIgKGVnIHR5 cGUgPSAgQXNzb2NpYXRpb24gc2V0dXApDQogICAgIHwNCiAgICAgfA0KICAgICArLS0tIFQgPSBM RkJzZWxlY3QNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gTEZCQ0xBU1NJRCA9 IEZFIG9iamVjdA0KICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAg ICAgKy0tIExGQkluc3RhbmNlID0gMHgxDQogICAgIHwgICAgICAgIA0KICAgICArLS0tIFQgPSBG RU5BTUUNCiAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICArLS0gIm15bmFtZSINCg0KDQoN CiAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxDQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICB8ICAgICAgICBUeXBlID0g TEZCIHNlbGVjdCAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQogICAgICAgfCAgICAgICAgICAgICAgICAgTEZCIENsYXNzIElEID0gRkUgT2Jq ZWN0ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICBMRkIgSW5zdGFuY2UgSUQgICAgICAgICAgICAgICAgICAgICAg ICB8DQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAuICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KICAgICAgIHwgICAgICAgICAg ICAgICAgICAgRkUgT2JqZWN0IExGQiAoaW5jbHVkaW5nIEhCSSwgZXRjKSAgICAgICAgICB8DQog ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgICAgICB8ICAgICAgICBUeXBlID0gRkUgTmFtZSAgICAgICAgIHwg ICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICAg LiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC4NCiAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICBGRSBOYW1lIHN0cmluZyAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgOA0KDQogICBUeXBlICgxNiBiaXRzKToNCiAg ICAgIExGQiBTZWxlY3QuDQogICBMZW5ndGggKDE2IGJpdHMpOg0KICAgICAgTGVuZ3RoIG9mIHRo ZSBUTFYgaW5jbHVkaW5nIHRoZSBUIGFuZCBMIGZpZWxkcywgaW4gYnl0ZXMuDQogICBGRSBPYmpl Y3QgTEZCOg0KICAgICAgVGhlIEZFIHBhcmFtZXRlcnMgZS5nLiBIQkkgd2lsbCBiZSBleGNoYW5n ZWQgd2l0aCB0aGUgQ0UgdXNpbmcgdGhpcyBMRkIuDQogICBGRSBOYW1lIFN0cmluZzoNCiAgICAg IFRoaXMgaXMgYSB2YXJpYWJsZSBsZW5ndGggc3RyaW5nIHdoaWNoIGNvbnRhaW5zIHRoZSBGRSBu YW1lIGFuZA0KICAgICAgaXMgZW5jb2RlZCBpbiBhIFRMVi4NCg0KICAgICAgRWRpdG9yaWFsIE5v dGU6ICBJbiBjZXJ0YWluIHNpdHVhdGlvbnMgKHN1Y2ggYXMgdXNlIG9mIG11bHRpY2FzdA0KICAg ICAgICAgICAgICAgICAgICAgICBJRHMpLCBpdCBtaWdodCBub3QgYmUgcG9zc2libGUgdG8gbWFr ZSB1c2Ugb2YgdGhlDQogICAgICAgICAgICAgICAgICAgICAgIHByb2NlZHVyZSBkZXNjcmliZWQg YWJvdmUgZm9yIHRoZSBGRSB0bw0KICAgICAgICAgICAgICAgICAgICAgICBkeW5hbWljYWxseSBv YnRhaW4gYW4gSUQgZnJvbSB0aGUgQ0UuICBTdWNoDQogICAgICAgICAgICAgICAgICAgICAgIHNp dHVhdGlvbnMgbmVlZCB0byBiZSBpZGVudGlmaWVkLg0KDQo2LjEuMiAgQXNzb2NpYXRpb24gU2V0 dXAgUmVzcG9uc2UgTWVzc2FnZQ0KDQogICBUaGlzIG1lc3NhZ2UgaXMgc2VudCBieSB0aGUgQ0Ug dG8gdGhlIEZFIGluIHJlc3BvbnNlIHRvIHRoZSBTZXR1cA0KICAgbWVzc2FnZS4gIEl0IGluZGlj YXRlcyB0byB0aGUgRkUgd2hldGhlciB0aGUgc2V0dXAgaXMgc3VjY2Vzc2Z1bCBvcg0KICAgbm90 LCBpLmUuICB3aGV0aGVyIGFuIGFzc29jaWF0aW9uIGlzIGVzdGFibGlzaGVkLg0KDQogICBNZXNz YWdlIHRyYW5zZmVyIGRpcmVjdGlvbjoNCiAgICAgICBDRSB0byBGRQ0KICAgTWVzc2FnZSBIZWFk ZXI6DQogICAgICAgVGhlIE1lc3NhZ2UgVHlwZSBpbiB0aGUgaGVhZGVyIGlzIHNldCBNZXNzYWdl VHlwZT0gJ1NldHVwDQogICAgICAgUmVzcG9uc2UnLiAgVGhlIEFDSyBmbGFnIGluIHRoZSBoZWFk ZXIgaXMgYWx3YXlzIGlnbm9yZWQsIGJlY2F1c2UNCiAgICAgICB0aGUgc2V0dXAgcmVzcG9uc2Ug bWVzc2FnZSB3aWxsIG5ldmVyIGV4cGVjdCB0byBnZXQgYW55IG1vcmUNCiAgICAgICByZXNwb25z ZSBmcm9tIHRoZSBtZXNzYWdlIHJlY2VpdmVyIChGRSkuICBUaGUgRHN0IElEIGluIHRoZQ0KICAg ICAgIGhlYWRlciB3aWxsIGJlIHNldCB0byBzb21lIEZFIElEIHZhbHVlIGFzc2lnbmVkIGJ5IHRo ZSBDRSBpZiB0aGUNCiAgICAgICBGRSBoYWQgcmVxdWVzdGVkIHRoYXQgaW4gdGhlIHNldHVwIG1l c3NhZ2UgKGJ5IFNyY0lEID0gMCkuDQogICBNZXNzYWdlIGJvZHk6DQogICAgICAgVGhlIHNldHVw IHJlc3BvbnNlIG1lc3NhZ2UgYm9keSBjb25zaXN0cyBvZiBMRkJTZWxlY3QgJiBSZXN1bHQgVExW LCB0aGUgZm9ybWF0DQogICAgICAgb2Ygd2hpY2ggaXMgYXMgZm9sbG93czoNCg0KDQptYWluIGhk ciAoZWcgdHlwZSA9ICBBc3NvY2lhdGlvbiBzZXR1cCByZXNwb25zZSkNCiAgICAgfA0KICAgICB8 DQogICAgICstLS0gVCA9IExGQnNlbGVjdA0KICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAg ICstLSBMRkJDTEFTU0lEID0gRkUgb2JqZWN0DQogICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAg ICAgfA0KICAgICB8ICAgICAgICArLS0gTEZCSW5zdGFuY2UgPSAweDENCiAgICAgfCAgICAgICAg DQogICAgICstLS0gVCA9IEZFUmVzdWx0DQogICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg Ky0tIHJlc3VsdHZhbHVlDQoNCg0KICAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAg ICAgICB8ICAgICAgICBUeXBlID0gTEZCIHNlbGVjdCAgICAgIHwgICAgICAgICAgICAgICBMZW5n dGggICAgICAgICAgfA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICAgfCAgICAgICAgICAgICAgICAg TEZCIENsYXNzIElEID0gRkUgT2JqZWN0ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBMRkIgSW5zdGFuY2UgSUQg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAuICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Lg0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgRkUgT2JqZWN0IExGQiAoaW5jbHVkaW5nIEhC SSwgZXRjKSAgICAgICAgICB8DQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICB8ICAgICAgIFR5cGUg PSBSZXN1bHQgICAgICAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQogICAgICAgfCAgICAgICAgIFJlc3VsdCAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICBSZXNlcnZlZCAgICAgICAgIHwNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDkNCg0KICAgVHlwZSAoMTYgYml0cyk6 DQogICAgICAgTEZCIFNlbGVjdC4NCiAgIExlbmd0aCAoMTYgYml0cyk6DQogICAgICAgTGVuZ3Ro IG9mIHRoZSBUTFYgaW5jbHVkaW5nIHRoZSBUIGFuZCBMIGZpZWxkcywgaW4gYnl0ZXMuDQogICBG RSBPYmplY3QgTEZCOg0KICAgICAgVGhlIEZFIHBhcmFtZXRlcnMgZS5nLiBIQkkgbWF5IGJlIGV4 Y2hhbmdlZCB1c2luZyB0aGlzIExGQi4NCiAgIFJlc3VsdCAoMTYgYml0cyk6DQogICAgICAgVGhp cyBpbmRpY2F0ZXMgd2hldGhlciB0aGUgc2V0dXAgbXNnIHdhcyBzdWNjZXNzZnVsIG9yIHdoZXRo ZXINCiAgICAgICB0aGUgRkUgcmVxdWVzdCB3YXMgcmVqZWN0ZWQgYnkgdGhlIENFLg0KDQo2LjEu MyAgQXNzb2NpYXRpb24gVGVhcmRvd24gTWVzc2FnZQ0KDQogICBUaGlzIG1lc3NhZ2UgY2FuIGJl IHNlbnQgYnkgdGhlIEZFIG9yIENFIHRvIGFueSBGb3JDRVMgZWxlbWVudCB0byBlbmQNCiAgIGl0 cyBGb3JDRVMgYXNzb2NpYXRpb24gd2l0aCB0aGF0IGVsZW1lbnQuDQoNCiAgIE1lc3NhZ2UgdHJh bnNmZXIgZGlyZWN0aW9uOg0KICAgICAgIENFIHRvIEZFLCBvciBGRSB0byBDRSAob3IgQ0UgdG8g Q0UpDQogICBNZXNzYWdlIEhlYWRlcjoNCiAgICAgICBUaGUgTWVzc2FnZSBUeXBlIGluIHRoZSBo ZWFkZXIgaXMgc2V0IE1lc3NhZ2VUeXBlPSAiQXNzby4NCiAgICAgICBUZWFyZG93biIuICBUaGUg QUNLIGZsYWcgaW4gdGhlIGhlYWRlciBpcyBhbHdheXMgaWdub3JlZCwNCiAgICAgICBiZWNhdXNl IHRoZSB0ZWFyZG93biBtZXNzYWdlIHdpbGwgbmV2ZXIgZXhwZWN0IHRvIGdldCBhbnkNCiAgICAg ICByZXNwb25zZSBmcm9tIHRoZSBtZXNzYWdlIHJlY2VpdmVyLg0KICAgTWVzc2FnZSBib2R5Og0K ICAgICAgIFRoZSBhc3NvY2lhdGlvbiB0ZWFyZG93biBtZXNzYWdlIGJvZHkgY29uc2lzdHMgb2Yg TEZCU2VsZWN0ICYgRkVSZWFzb24gVExWLCB0aGUNCiAgICAgICBmb3JtYXQgb2Ygd2hpY2ggaXMg YXMgZm9sbG93czoNCg0KbWFpbiBoZHIgKGVnIHR5cGUgPSAgQXNzb2NpYXRpb24gdGVhcikNCiAg ICAgfA0KICAgICB8DQogICAgICstLS0gVCA9IExGQnNlbGVjdA0KICAgICB8ICAgICAgICB8DQog ICAgIHwgICAgICAgICstLSBMRkJDTEFTU0lEID0gRkUgb2JqZWN0DQogICAgIHwgICAgICAgIHwN CiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gTEZCSW5zdGFuY2UgPSAweDENCiAg ICAgfCAgICAgICAgDQogICAgICstLS0gVCA9IEZFUmVhc29uDQogICAgICAgICAgICAgIHwNCiAg ICAgICAgICAgICAgKy0tICJteXJlYXNvbiINCg0KDQoNCiAgICAgICAgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgICAgICB8ICAgICAgICBUeXBlID0gTEZCIHNlbGVjdCAgICAgIHwgICAgICAg ICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICAgfCAgICAg ICAgICAgICAgICAgTEZCIENsYXNzIElEID0gRkUgT2JqZWN0ICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBMRkIg SW5zdGFuY2UgSUQgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAg ICAgICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLg0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgRkUgT2JqZWN0IExGQiAo aW5jbHVkaW5nIEhCSSwgZXRjKSAgICAgICAgICB8DQogICAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICB8 ICAgICAgICAgVHlwZSA9IFQucmVhc29uICAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAg ICAgICAgfA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICAgfCAgICAgICAgICAgICAgICAgICBSZWFz b24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTANCg0KICAgVHlw ZSAoMTYgYml0cyk6DQogICAgICAgTEZCIFNlbGVjdC4NCiAgIExlbmd0aCAoMTYgYml0cyk6DQog ICAgICAgTGVuZ3RoIG9mIHRoZSBUTFYgaW5jbHVkaW5nIHRoZSBUIGFuZCBMIGZpZWxkcywgaW4g Ynl0ZXMuDQogICBGRSBPYmplY3QgTEZCOg0KICAgICAgVGhlIEZFIHBhcmFtZXRlcnMgbWF5IGJl IGV4Y2hhbmdlZCB1c2luZyB0aGlzIExGQi4NCiAgIFQucmVhc29uICgzMiBiaXRzKToNCiAgICAg ICBUaGlzIGluZGljYXRlcyB0aGUgcmVhc29uIHdoeSB0aGUgYXNzb2NpYXRpb24gaXMgYmVpbmcN CiAgICAgICB0ZXJtaW5hdGVkLg0KDQoNCjYuMyAgQ29uZmlndXJhdGlvbiBNZXNzYWdlcw0KDQog ICBUaGUgRm9yQ0VTIENvbmZpZ3VyYXRpb24gbWVzc2FnZXMgYXJlIHVzZWQgYnkgdGhlIENFcyB0 byBjb25maWd1cmUNCiAgIHRoZSBGRXMgaW4gYSBGb3JDRVMgTkUgYW5kIHJlcG9ydCB0aGUgcmVz dWx0cyBiYWNrIHRvIHRoZSBDRS4NCg0KNi4zLjEgIENvbmZpZyBNZXNzYWdlDQoNCiAgIFRoaXMg bWVzc2FnZSBpcyBzZW50IGJ5IHRoZSBDRSB0byB0aGUgRkUgdG8gY29uZmlndXJlIEZFIG9yIExG Qg0KICAgYXR0cmlidXRlcy4gIFRoaXMgbWVzc2FnZSBpcyBhbHNvIHVzZWQgYnkgdGhlIENFIHRv IHN1YnNjcmliZS8NCiAgIHVuc3Vic2NyaWJlIHRvIEZFLCBMRkIgZXZlbnRzLg0KDQogICBNZXNz YWdlIHRyYW5zZmVyIGRpcmVjdGlvbjoNCiAgICAgICBDRSB0byBGRQ0KICAgTWVzc2FnZSBIZWFk ZXI6DQogICAgICAgVGhlIE1lc3NhZ2UgVHlwZSBpbiB0aGUgaGVhZGVyIGlzIHNldCBNZXNzYWdl VHlwZT0gJ0NvbmZpZycuICBUaGUNCiAgICAgICBBQ0sgZmxhZyBpbiB0aGUgaGVhZGVyIGlzIGNh biBiZSB1c2VkIGJ5IHRoZSBDRSB0byB0dXJuIG9mZiBhbnkNCiAgICAgICByZXNwb25zZSBmcm9t IHRoZSBGRS4gIFRoZSBkZWZhdWx0IGJlaGF2aW9yIGlzIHRvIHR1cm4gb24gdGhlIEFDSw0KICAg ICAgIHRvIGdldCB0aGUgY29uZmlnIHJlc3BvbnNlIGZyb20gdGhlIEZFLg0KICAgTWVzc2FnZSBi b2R5Og0KICAgICAgIFRoZSBDb25maWcgbWVzc2FnZSBib2R5IGNvbnNpc3RzIG9mIG9uZSBvciBt b3JlIFRMVnMsIHRoZSBmb3JtYXQNCiAgICAgICBvZiB0aGUgVExWcy9tZXNzYWdlIGlzIGFzIGZv bGxvd3M6DQoNCg0KbWFpbiBoZHIgKGVnIHR5cGUgPSBjb25maWcpDQogICAgIHwNCiAgICAgfA0K ICAgICArLS0tIFQgPSBMRkJzZWxlY3QNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICAr LS0gTEZCQ0xBU1NJRCA9IHRhcmdldCBMRkIgY2xhc3MNCiAgICAgfCAgICAgICAgfA0KICAgICB8 ICAgICAgICB8DQogICAgIHwgICAgICAgICstLSBMRkJJbnN0YW5jZSA9IHRhcmdldCBMRkIgaW5z dGFuY2UgDQogICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICAr LS0gVCA9IG9wZXJhdGlvbiB7IEFERCwgREVMLCAgZXRjfQ0KICAgICB8ICAgICAgICB8ICAgfA0K ICAgICB8ICAgICAgICB8ICAgKy0tICAvLyBvbmUgb3IgbW9yZSBwYXRoIHRhcmdldHMgDQogICAg IHwgICAgICAgIHwgICAgICAgIC8vIHVuZGVyIGRpc2N1c3Npb24NCiAgICAgfCAgICAgICAgfA0K ICAgICB8ICAgICAgICArLS0gVCA9IG9wZXJhdGlvbiB7IEFERCwgREVMLCAgZXRjfQ0KICAgICB8 ICAgICAgICB8ICAgfA0KICAgICB8ICAgICAgICB8ICAgKy0tICAvLyBvbmUgb3IgbW9yZSBwYXRo IHRhcmdldHMgDQogICAgIHwgICAgICAgIHwgICAgICAgIC8vIHVuZGVyIGRpc2N1c3Npb24NCiAg ICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gVCA9IG9wZXJhdGlvbiB7IEFERCwgREVM LCAgZXRjfQ0KICAgICB8ICAgICAgICB8ICAgfA0KICAgICB8ICAgICAgICB8ICAgKy0tICAvLyBv bmUgb3IgbW9yZSBwYXRoIHRhcmdldHMgDQogICAgIHwgICAgICAgIHwgICAgICAgIC8vIHVuZGVy IGRpc2N1c3Npb24NCiAgICAgfCAgICAgICAgfA0KDQoNCiAgICAgIDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICAgICB8ICAgICAgICBUeXBlID0gTEZCIHNlbGVjdCAgICAgIHwgICAgICAgICAgICAg ICBMZW5ndGggICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICBMRkIgQ2xhc3MgSUQgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgTEZCIEluc3RhbmNlIElEICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgIFR5cGUgPSBP cGVyYXRpb25zIChBREQpICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICBFdmVudCBUeXBlICAgICAgICAgIHwgICAgICAg ICAgIFJlc2VydmVkICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgIENvbmZpZyBkYXRhICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgIFR5cGUgPSBPcGVyYXRpb25z IChERUwpICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgICB8ICAgICAgICAgICBFdmVudCBUeXBlICAgICAgICAgIHwgICAgICAgICAgICAgUmVz ZXJ2ZWQgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgIENvbmZpZyBkYXRhICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAuICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmln dXJlIDE2DQoNCiAgIFR5cGUgKDE2IGJpdHMpOg0KICAgICAgIExGQiBTZWxlY3QuDQogICBMZW5n dGggKDE2IGJpdHMpOg0KICAgICAgIExlbmd0aCBvZiB0aGUgVExWIGluY2x1ZGluZyB0aGUgVCBh bmQgTCBmaWVsZHMsIGluIGJ5dGVzLg0KICAgTEZCIENsYXNzIElEICgxNiBiaXRzKToNCiAgICAg ICBUaGlzIGZpZWxkIHVuaXF1ZWx5IHJlY29nbml6ZXMgdGhlIExGQiBjbGFzcy90eXBlLg0KICAg TEZCIEluc3RhbmNlIElEICgxNiBiaXRzKToNCiAgICAgICBUaGlzIGZpZWxkIHVuaXF1ZWx5IGlk ZW50aWZpZXMgdGhlIExGQiBpbnN0YW5jZS4NCg0KICAgVHlwZSAoMTYgYml0cyk6DQogICAgICAg VGhlIG9wZXJhdGlvbnMgaW5jbHVkZSwgQURELCBERUwsIFVQREFURS9SRVBMQUNFLCBERUwgQUxM LCBTVUJTQ1JJQkUsDQogICAgICAgVU5TVUJTQ1JJQkUsIENBTkNFTC4gIFRoZSBmb2xsb3dpbmcg VHlwZXMgYXJlIGRlZmluZWQgZm9yIHRoaXMNCiAgICAgICBUTFY6DQogICAgICAgKiAgIEFkZCwg RGVsLCBVcGRhdGUsIERlbCBBbGwsIENhbmNlbCwgU3Vic2NyaWJlLCBVbnN1YnNjcmliZQ0KICAg ICAgICAgICBldmVudHMNCiAgIExlbmd0aCAoMTYgYml0cyk6DQogICAgICAgTGVuZ3RoIG9mIHRo ZSBUTFYgaW5jbHVkaW5nIHRoZSBUIGFuZCBMIGZpZWxkcywgaW4gYnl0ZXMuDQogICBFdmVudCBU eXBlICgxNiBiaXRzKToNCiAgICAgICBGb3IgU1VCU0NSSUJFLCBVTlNVQlNDUklCRSBFdmVudHMg VHlwZSBUTFZzLCBhbiBFdmVudCBUeXBlIGZpZWxkDQogICAgICAgd2lsbCBkZWZpbmUgdGhlIEV2 ZW50cyBvZiBpbnRlcmVzdC4gIEV4YW1wbGVzIG9mIEV2ZW50IFR5cGUNCiAgICAgICBpbmNsdWRl LCBBbGwgRXZlbnRzLCBGRSBFdmVudHMsIExGQiBFdmVudHMsIFBhY2tldHMsIFBhY2tldA0KICAg ICAgIE1pcnJvcmluZy4NCiAgIENvbmZpZyBEYXRhICh2YXJpYWJsZSBsZW5ndGgpOg0KICAgICAg IFRoaXMgd2lsbCBjYXJyeSBMRkIgc3BlY2lmaWMgZGF0YSAoPHBhdGg+LHNpbmdsZSBvciBBcnJh eSBMRkIgc3BlY2lmaWMNCiAgICAgICBlbnRyaWVzKS4gIFRoZSBjb25maWcgZGF0YSBtaWdodCBp dHNlbGYgYmUgb2YgdGhlIGZvcm0gb2YgYSBUTFYuDQoNCipOb3RlOiBGRSBBY3RpdmF0ZS9EZWFj dGl2YXRlLCBTaHV0ZG93biBGRSBjb21tYW5kcyBmb3IgU3RhdGUgTWFpbnRlbmFuY2Ugd2lsbA0K ICAgICAgYmUgc2VudCB1c2luZyBDb25maWcgbWVzc2FnZXMuDQogDQoNCjYuMy4yICBDb25maWcg UmVzcG9uc2UgTWVzc2FnZQ0KDQogICBUaGlzIG1lc3NhZ2UgaXMgc2VudCBieSB0aGUgRkUgdG8g dGhlIENFIGluIHJlc3BvbnNlIHRvIHRoZSBDb25maWcNCiAgIG1lc3NhZ2UuICBJdCBpbmRpY2F0 ZXMgd2hldGhlciB0aGUgQ29uZmlnIHdhcyBzdWNjZXNzZnVsIG9yIG5vdCBvbg0KICAgdGhlIEZF IGFuZCBhbHNvIGdpdmVzIGEgZGV0YWlsZWQgcmVzcG9uc2UgcmVnYXJkaW5nIHRoZSBjb25maWd1 cmF0aW9uDQogICByZXN1bHQgb2YgZWFjaCBhdHRyaWJ1dGUuDQoNCiAgIE1lc3NhZ2UgdHJhbnNm ZXIgZGlyZWN0aW9uOg0KICAgICAgIEZFIHRvIENFDQogICBNZXNzYWdlIEhlYWRlcjoNCiAgICAg ICBUaGUgTWVzc2FnZSBUeXBlIGluIHRoZSBoZWFkZXIgaXMgc2V0IE1lc3NhZ2VUeXBlPSAnQ29u ZmlnDQogICAgICAgUmVzcG9uc2UnLiAgVGhlIEFDSyBmbGFnIGluIHRoZSBoZWFkZXIgaXMgYWx3 YXlzIGlnbm9yZWQsIGJlY2F1c2UNCiAgICAgICB0aGUgY29uZmlnIHJlc3BvbnNlIG1lc3NhZ2Ug d2lsbCBuZXZlciBleHBlY3QgdG8gZ2V0IGFueSBtb3JlDQogICAgICAgcmVzcG9uc2UgZnJvbSB0 aGUgbWVzc2FnZSByZWNlaXZlciAoQ0UpLg0KICAgTWVzc2FnZSBib2R5Og0KICAgICAgIFRoZSBD b25maWcgcmVzcG9uc2UgbWVzc2FnZSBib2R5IGNvbnNpc3RzIG9mIG9uZSBvciBtb3JlIFRMVnMs DQogICAgICAgdGhlIGZvcm1hdCBvZiB0aGUgVExWcy9tZXNzYWdlIGlzIGFzIGZvbGxvd3M6DQoN Cg0KICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMQ0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICBUeXBlID0gTEZC IHNlbGVjdCAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBMRkIgQ2xhc3MgSUQgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgTEZCIEluc3RhbmNlIElEICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB8ICAgIFR5cGUgPSBPcGVyYXRpb25zIChBREQpICAgIHwgICAgICAgICAg ICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICBPdmVyYWxs IFJlc3VsdCAgICAgICAgICAgIHwgICAgICAgICAgIHJlc2VydmVkICAgICAgICAgICAgfA0KICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIENvbmZpZyBSZXN1bHQg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAuICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K ICAgICB8ICAgIFR5cGUgPSBPcGVyYXRpb25zIChERUwpICAgIHwgICAgICAgICAgICAgICBMZW5n dGggICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICBPdmVyYWxsIFJlc3VsdCAg ICAgICAgICAgIHwgICAgICAgICAgIHJlc2VydmVkICAgICAgICAgICAgfA0KICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIENvbmZpZyBSZXN1bHQgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE3DQoNCiAgIFR5cGUgKDE2IGJpdHMpOg0K ICAgICAgIExGQiBTZWxlY3QuDQogICBMZW5ndGggKDE2IGJpdHMpOg0KICAgICAgIExlbmd0aCBv ZiB0aGUgVExWIGluY2x1ZGluZyB0aGUgVCBhbmQgTCBmaWVsZHMsIGluIGJ5dGVzLg0KICAgTEZC IENsYXNzIElEICgxNiBiaXRzKToNCiAgICAgICBUaGlzIGZpZWxkIHVuaXF1ZWx5IHJlY29nbml6 ZXMgdGhlIExGQiBjbGFzcy90eXBlLg0KICAgTEZCIEluc3RhbmNlIElEICgxNiBiaXRzKToNCiAg ICAgICBUaGlzIGZpZWxkIHVuaXF1ZWx5IGlkZW50aWZpZXMgdGhlIExGQiBpbnN0YW5jZS4NCg0K ICAgVHlwZSAoMTYgYml0cyk6DQogICAgICAgVGhlIG9wZXJhdGlvbnMgaW5jbHVkZSwgQURELCBE RUwsIFVQREFURS9SRVBMQUNFLCBERUwgQUxMLCBTVUJTQ1JJQkUsDQogICAgICAgVU5TVUJTQ1JJ QkUsIENBTkNFTC4gIFRoZSBmb2xsb3dpbmcgVHlwZXMgYXJlIGRlZmluZWQgZm9yIHRoaXMNCiAg ICAgICBUTFY6DQogICAgICAgKiAgIEFkZCwgRGVsLCBVcGRhdGUsIERlbCBBbGwsIENhbmNlbCwg U3Vic2NyaWJlLCBVbnN1YnNjcmliZQ0KICAgICAgICAgICBldmVudHMNCiAgIExlbmd0aCAoMTYg Yml0cyk6DQogICAgICAgTGVuZ3RoIG9mIHRoZSBUTFYgaW5jbHVkaW5nIHRoZSBUIGFuZCBMIGZp ZWxkcywgaW4gYnl0ZXMuDQogICBPdmVyYWxsIFJlc3VsdCAoMTYgYml0cyk6DQogICAgICAgVGhp cyBpbmRpY2F0ZXMgdGhlIG92ZXJhbGwgcmVzdWx0IG9mIHRoZSBjb25maWcgbWVzc2FnZSwgd2hl dGhlcg0KICAgICAgIGl0IHdhcyBzdWNjZXNzZnVsIG9yIGl0IGZhaWxlZC4NCiAgIENvbmZpZyBS ZXN1bHQgKHZhcmlhYmxlIGxlbmd0aCk6DQogICAgICAgVGhpcyB3aWxsIGNhcnJ5IExGQiBzcGVj aWZpYyByZXN1bHRzIChzaW5nbGUgb3IgQXJyYXkgTEZCDQogICAgICAgc3BlY2lmaWMgcmVzdWx0 IGVudHJpZXMpLiAgVGhlIGNvbmZpZyByZXN1bHQgbWlnaHQgaXRzZWxmIGJlIG9mDQogICAgICAg dGhlIGZvcm0gb2YgYSBUTFYuDQoNCg0KNi42LiAtPiBSZW1vdmUgdGhpcyBzZWN0aW9uDQoNCjYu NyAgSGVhcnRiZWF0IE1lc3NhZ2UNCg0KICAgVGhlIEhlYXJ0YmVhdCAoSEIpIE1lc3NhZ2UgaXMg dXNlZCBmb3Igb25lIEZvckNFUyBlbGVtZW50IChGRSBvciBDRSkNCiAgIHRvIGFzeW5jaHJvbm91 c2x5IG5vdGlmeSBvbmUgb3IgbW9yZSBvdGhlciBGb3JDRVMgZWxlbWVudHMgaW4gdGhlDQogICBz YW1lIEZvckNFUyBORSBvbiBpdHMgbGl2ZW5lc3MuDQoNCiAgIEEgSGVhcnRiZWF0IE1lc3NhZ2Ug aXMgc2VudCBieSBhIEZvckNFUyBlbGVtZW50IHBlcmlvZGljYWxseS4gIFRoZQ0KICAgdGltZSBp bnRlcnZhbCB0byBzZW5kIHRoZSBtZXNzYWdlIGlzIHNldCBieSB0aGUgQXNzb2NpYXRpb24gU2V0 dXANCiAgIE1lc3NhZ2UgZGVzY3JpYmVkIGluIFNlY3Rpb24gNi4xLjEuICBBIGxpdHRsZSBkaWZm ZXJlbnQgZnJvbSBvdGhlcg0KICAgcHJvdG9jb2wgbWVzc2FnZXMsIGEgSGVhcnRiZWF0IG1lc3Nn ZSBpcyBvbmx5IGNvbXBvc2VkIG9mIGEgY29tbW9uDQogICBoZWFkZXIsIHdpdGhlIHRoZSBtZXNz YWdlIGJvZHkgbGVmdCBlbXB0eS4gIERldGFpbGVkIGRlc2NyaXB0aW9uIG9mDQogICB0aGUgbWVz c2FnZSBpcyBhcyBiZWxvdy4NCiAgIE1lc3NhZ2UgVHJhbnNmZXIgRGlyZWN0aW9uOg0KICAgICAg IEZFIHRvIENFLCBvciBDRSB0byBGRQ0KICAgTWVzc2FnZSBIZWFkZXI6DQogICAgICAgVGhlIE1l c3NhZ2UgVHlwZSBpbiB0aGUgbWVzc2FnZSBoZWFkZXIgaXMgc2V0IHRvIE1lc3NhZ2VUeXBlID0N CiAgICAgICAnSGVhcnRiZWF0Jy4gIFRoZSBBQ0sgZmxhZyBpbiB0aGUgaGVhZGVyIFNIT1VMRCBi ZSBzZXQgdG8NCiAgICAgICAnTm9BQ0snLCBtZWFuaW5nIG5vIHJlc3BvbnNlIGZyb20gcmVjZWl2 ZXIocykgaXMgZXhwZWN0ZWQgYnkgdGhlDQogICAgICAgbWVzc2FnZSBzZW5kZXIuICBPdGhlciB2 YWx1ZXMgb2YgdGhlIEFDSyBmbGFnIHdpbGwgYWx3YXlzIGJlDQogICAgICAgaWdub3JlZCBieSB0 aGUgbWVzc2FnZSByZWNlaXZlci4NCiAgIE1lc3NhZ2UgQm9keToNCiAgICAgICBUaGUgbWVzc2Fn ZSBib2R5IGlzIGVtcHR5IGZvciB0aGUgSGVhcnRiZWF0IE1lc3NhZ2UsIHNvIGFzIHRvDQogICAg ICAgZ3Jhc3AgbW9yZSBlZmZpY2llbmN5IGZvciBtZXNzYWdlIHRyYW5zcG9ydGF0aW9uIGFuZCBw cm9jZXNzaW5nLg0KDQoNCg0KDQo= ------_=_NextPart_001_01C4B812.2ECFB6C7 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol ------_=_NextPart_001_01C4B812.2ECFB6C7-- From forces-protocol-bounces@ietf.org Fri Oct 22 05:22:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14860 for ; Fri, 22 Oct 2004 05:22:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKvqB-0001kl-JR for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 05:36:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKvXQ-0008Pv-Ca; Fri, 22 Oct 2004 05:16:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKvTK-0005tt-4S for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 05:12:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14412 for ; Fri, 22 Oct 2004 05:12:27 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKvfr-0001bl-Ov for forces-protocol@ietf.org; Fri, 22 Oct 2004 05:25:41 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Fri, 22 Oct 2004 17:31:02 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Fri, 22 Oct 2004 17:07:21 +0800 Message-ID: <0fe601c4b816$d55930c0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , "Robert Haas" References: <468F3FDA28AA87429AD807992E22D07E0257920D@orsmsx408> Date: Fri, 22 Oct 2004 17:09:27 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.6 (+++) X-Scan-Signature: f0ea5880a0890be2408609376fa519aa Cc: ram.gopal@nokia.com, avri@psg.com, hadi@znyx.com, Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] Re: Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1665359423==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 3.6 (+++) X-Scan-Signature: da41e01217ab11ad82db577473e913ae This is a multi-part message in MIME format. --===============1665359423== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0FE3_01C4B859.E35B0610" This is a multi-part message in MIME format. ------=_NextPart_000_0FE3_01C4B859.E35B0610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 Um9iZXJ0LCANCg0KRG9uJ3Qgd29ycnkgdG9vIG11Y2ggYWJvdXQgdGhlIEZFIExGQiBhbmQgUHJv dG9jb2wgTEZCLCBJIHRoaW5rIGl0IGNhbiBiZSBmaXQgaXQgd2VsbCBpbiB0aGUgc2VjdGlvbnMu DQoNCkFjdHVhbGx5IEkgY2FuIGRvIHNvbWV0aGluZyBmb3IgUHJvdG9jb2wgTEZCIGFuZCBGRSBM RkIgaWYgeW91IHRoaW5rIHBvc3NpYmxlLg0KDQpSZWdhcmRzLA0KV2VpbWluZw0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBLaG9zcmF2aSwgSG9ybXV6ZCBNIA0KICBU bzogUm9iZXJ0IEhhYXMgDQogIENjOiBMaWdhbmcgRG9uZyA7IGhhZGlAem55eC5jb20gOyBhdnJp QHBzZy5jb20gOyByYW0uZ29wYWxAbm9raWEuY29tIDsgV2VpbWluZyBXYW5nIDsgZm9yY2VzLXBy b3RvY29sQGlldGYub3JnIA0KICBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMDQgNDozNSBQ TQ0KICBTdWJqZWN0OiBTZWN0aW9uIDYgdXBkYXRlDQoNCg0KICBIaSBSb2JlcnQsIEFsbA0KDQoN Cg0KICBIZXJlIHlvdSBnby5JIGhhdmUgdXBkYXRlZCBzZWN0aW9ucyA2LjEsIDYuMywgNi42IChy ZW1vdmUpLCA2LjcgKHNhbWUpLiBJIGhhdmUgZGlyZWN0bHkgdXNlZCB0aGUgdGV4dCB0aGF0IEph bWFsIHNlbnQgb3V0IHdoZXJldmVyIGFwcGxpY2FibGUuDQoNCiAgWW91IGNhbiB1cGRhdGUgc2Vj dGlvbnMgNi4yLCA2LjQsIDYuNSAtPiBob3dldmVyLCBJIHdvdWxkIGNoZWNrIHdpdGggV2VpbWlu ZyBmaXJzdCBhcyBjb3VydGVzeSBzaW5jZSBoZSBpcyB3b3JraW5nIG9uIHRoZXNlIHNlY3Rpb25z Lg0KDQoNCg0KICBCVFcsIHRoZXJlIHdlcmUgbG90cyBvZiB0aGluZ3MgaW4gdGhlIHRvZG8gbGlz dCBJIHNlbnQgb3V0Lg0KDQoNCg0KICBIZWFkZXIgU2VjdGlvbiAtIEphbWFsL1JvYmVydC9XZWlt aW5nPw0KDQogIFByb3RvY29sIExGQiAtIFJvYmVydC9PdGhlcnM/DQoNCiAgRkUgTEZCIC0gUm9i ZXJ0L090aGVycz8NCg0KICBDRSBMRkIgLSA/DQoNCiAgU3RhdGUgTWFjaGluZSBmb3IgUHJvdG9j b2wgLSBMaWdhbmcgKHRha2VuKQ0KDQoNCg0KICBXaWxsIHlvdSBiZSB3b3JraW5nIG9uIGFueSBv ZiB0aGVzZSA/Pw0KDQoNCg0KICBQbHMgZG8gbGV0IHVzIGtub3cuSSB3aWxsIHN0YXJ0IHdvcmtp bmcgb24gd2hhdGV2ZXIgaGFzbid0IGJlZW4gY2xhaW1lZCBieSB0b21vcnJvdyBtb3JuaW5nIG15 IHRpbWUuDQoNCg0KDQogIFRoYW5rcw0KDQogIEhvcm11emQNCg0KDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCiAgRnJvbTogUm9iZXJ0IEhhYXMgW21haWx0bzpyaGFAenVyaWNoLmlibS5j b21dIA0KICBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMDQgMTI6MzkgQU0NCiAgVG86IEto b3NyYXZpLCBIb3JtdXpkIE0NCiAgQ2M6IExpZ2FuZyBEb25nOyBoYWRpQHpueXguY29tOyBhdnJp QHBzZy5jb207IHJhbS5nb3BhbEBub2tpYS5jb207IFdlaW1pbmcgV2FuZzsgZm9yY2VzLXByb3Rv Y29sQGlldGYub3JnDQogIFN1YmplY3Q6IFJlOiBBcHBseWluZyBjaGFuZ2VzIHRvIFNlY3Rpb24g NiAoUHJvdG9jb2wgTWVzc2FnZXMpDQoNCg0KDQogIEhvcm11emQsDQogIENvdWxkIHlvdSBwbGVh c2UgcGFzcyB0aGUgdG9rZW4gb24gc2VjdGlvbiA2IHRvZ2V0aGVyIHdpdGggeW91ciBsYXRlc3Qg dmVyc2lvbiBzbyBJIGNhbiBzdGFydCBlZGl0aW5nIGl0ID8NCiAgVGhhbmtzLA0KICAtUm9iZXJ0 DQoNCiAgS2hvc3JhdmksIEhvcm11emQgTSB3cm90ZToNCg0KDQoNCiAgUm9iZXJ0LA0KDQoNCg0K ICBBcyBJIHNhaWQsIHlvdXIgbm90ZSBtb3N0bHkgbG9va3MuLi5JIGhhdmUgcHV0IHNvbWUgbW9y ZSBjb21tZW50cyBiZWxvdy4uLg0KDQogIChJdCB3b3VsZCBoZWxwIGEgbG90IGlmIHlvdSBzdGFy dCBkZWZpbmluZyB0aGUgRkUsIFByb3RvY29sIExGQnMuLi4pDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCiAgRnJvbTogUm9iZXJ0IEhhYXMgW21haWx0bzpyaGFAenVyaWNoLmlibS5jb21d IA0KDQoNCiAgQWxsOiBiZWxvdyBpcyBhIHJvdWdoIGxpc3Qgb2YgY2hhbmdlcyBhbmQgcGVuZGlu ZyBpc3N1ZXMgcmVnYXJkaW5nIHNlY3Rpb24gNi4gUGxlYXNlIHJldmlldy4NCg0KICAgNi4xLjEg QXNzb2NpYXRpb246IFRoZSBDRSBjb3VsZCBvYnRhaW4gdGhlIEhCSSB3aXRoIGEgUXVlcnktU0dU LUZFUHJvdG9jb2xMRlAtSGVhcnRiZWF0SW50ZXJ2YWwuIEdpdmVuIHRoZSBuZXcgQXNzb2MgbXNn IHN0cmN1dHJ1ZSwgd2UgaGF2ZSB0byByZW1vdmUgSEJJIGZyb20gdGhlIEFzc29jIFNldHVwIG1z Zy4gIFtBZ3JlZWQsIHRoaXMgd291bGQgYmUgcGFydCBvZiBQcm90b2NvbExGQiBldmVuIGlmIGl0 IGlzIGluIHRoaXMgbWVzc2FnZV0gDQoNCiAgIDYuMS4yIEhvdyBoYXMgdGhlIHNyY0lEPTAgY2Fz ZSBiZWVuIGhhbmRsZWQgaW4gdGhlIGludGVyb3AgdGVzdHMgPyBJcyB0aGlzIHJlYWxseSBmZWFz aWJsZSA/ICBbWWVzIGl0IHdvcmtlZCBmaW5lIGR1cmluZyBJbnRlcm9wXSANCg0KICAgNi4yIFF1 ZXJ5OiBjb2Fyc2UgRkUgaW5mbyAoaW50ZXIvaW50cmEtRkUgdG9wb2xvZ3ksIGV0YykgZ29lcyBp bnRvIHRoZSBGRVByb3RvY29sTEZCLiAgW0FncmVlZCBpdCB3b3VsZCBiZSBpbiBzb21lIExGQiwg YnV0IG5vdCBzdXJlIHdoaWNoIExGQiB0aGlzIHdvdWxkIGJlIHBhcnQgb2YuLi4/XSANCg0KICAg Ni40OiBFdmVudHM6IGNvYXJzZSBDRSBhbmQgRkUgZXZlbnRzIGdvIGludG8gQ0UvRkVQcm90b2Nv bExGQi4gTm90ZSB0aGF0IGZvciB0aGUgc2FrZSBvZiBzeW1tZXRyeSwgd2Ugc2hvdWxkIGludHJv ZHVjZSBhIENFUHJvdG9jb2xMRkIuICBbU3VyZSwgd2h5IGRvbnQgeW91IHN0YXJ0IGRlZmluaW5n IHNvbWUgb2YgdGhlc2Ugb2JqZWN0cy4uLnRoZW4gd2UgY2FuIGRpc2N1c3MgbW9yZSBpbiBkZXRh aWxdIA0KDQogICA2LjYgU3RhdGUgTWFpbnRlbmFuY2U6IEZFIEFjdGl2YXRlL0RlYWN0aXZhdGUv U2h1dGRvd24gYmVjb21lIHNldHRhYmxlIGF0dHJpYnV0ZXMgaW4gdGhlIEZFUHJvdG9jb2xMRkIu ICBbWWVzLCB0aGVzZSBtZXNzYWdlcyB3aWxsIGJlIHBhcnQgb2YgRXZlbnRzIG9yIENvbmZpZy4u LndlIG5lZWQgdG8gc3BlY2lmeSB0aGlzXSANCg0KICAgNi43IEhCIHJlbWFpbnMgYXMgaXMuICBb QWdyZWVkXSANCg0KICBJbiBzdW1tYXJ5LCB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcgb3BlcmF0aW9u cyBkZWZpbmVkIGZvciBlYWNoIG1lc3NhZ2UgdHlwZSAoIEkgYnJva2UgdGhlIHRhYmxlIGludG8g MyBwYXJ0cyk6DQogICBbbG9va3MgZ29vZCFdIA0KICBPUEVSQVRJT04gICAgICAgQVBQTElDQUJM RSBNRVNTQUdFIFRZUEVTDQoNCiAgICAgICAgICAgICAgICAgIEFzc29jLVNldHVwICBBc3NvYy1T ZXR1cC1SZXNwIEFzc29jLVRlYXJkb3duIEhlYXJ0YmVhdA0KDQogIG5vIG9wZXJhdGlvbnMNCiAg ZGVmaW5lZA0KDQoNCiAgICAgICAgICAgICAgICAgIFF1ZXJ5ICBRdWVyeS1SZXNwICBDb25maWcg IENvbmZpZy1SZXNwDQogIFNFVCwgREVMLCBVUERBVEUgICAgICAgICAgICAgICAgICAgICB4ICAg ICAgICAgIHgNCiAgR0VUICAgICAgICAgICAgICAgeCAgICAgICAgIHgNCiAgRVZfUywgRVZfVSAg ICAgICAgICAgICAgICAgICAgICAgICAgIHggICAgICAgICAgeA0KDQogIChmb3IgZXZlbnQgc3Vi c2NyaWJlL3Vuc3Vic2NyaWJlKQ0KDQoNCiAgICAgICAgICAgICAgICAgIFBhY2tldC1SZWRpcg0K DQogIFBBWUxPQUQgICAgICAgICAgICB4DQoNCg0KICAgICAgICAgICAgICAgICAgRXZlbnQtTm90 aWYgIEV2ZW50LU5vdGlmLVJlc3ANCiAgRVZFTlQgICAgICAgICAgICAgIHggICAgICAgICAgICAg ICAgeA0KDQogIE5vdGUgdGhhdCBmb3IgUXVlcnkoLVJlc3ApLCBQYWNrZXQtUmVkaXIsIGFuZCBF dmVudC1Ob3RpZigtUmVzcCksIHdlIGhhdmUgZWFjaCB0aW1lIG9ubHkgb25lIG9wZXJhdGlvbi4g TG9va3MgYSBiaXQgcmVkdW5kYW50LiBJZGVhcyA/ICBbVGhlc2UgYXJlIGFsbCB2ZXJ5IGRpZmZl cmVudCwgbGV0cyBsZWF2ZSB0aGVtIGFzIGlzLCBpdHMgbm90IG5lY2Vzc2FyeSB0byBoYXZlIG11 bHRpcGxlIG9wZXJhdGlvbnMgaW4gYWxsIG1lc3NhZ2VzXSANCg0KICBSZWdhcmRzLA0KICAtUm9i ZXJ0DQoNCg0KDQoNCg0KLS0gDQpSb2JlcnQgSGFhcw0KSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJv cmF0b3J5DQpT5HVtZXJzdHJhc3NlIDQNCkNILTg4MDMgUvxzY2hsaWtvbi9Td2l0emVybGFuZA0K cGhvbmUgKzQxLTEtNzI0LTg2OTggIGZheCArNDEtMS03MjQtODU3OCAgaHR0cDovL3d3dy56dXJp Y2guaWJtLmNvbS9+cmhhDQoNCg== ------=_NextPart_000_0FE3_01C4B859.E35B0610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjYwMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogVGFob21hOw0KfQ0KQHBhZ2UgU2VjdGlvbjEge3NpemU6IDguNWluIDExLjBpbjsg bWFyZ2luOiAxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluOyB9DQpQLk1zb05vcm1hbCB7DQoJRk9O VC1TSVpFOiAxMnB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFN SUxZOiAiVGltZXMgTmV3IFJvbWFuIg0KfQ0KTEkuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEy cHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICJUaW1l cyBOZXcgUm9tYW4iDQp9DQpESVYuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEycHQ7IE1BUkdJ TjogMGluIDBpbiAwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iDQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGlu ZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046 IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9O OiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9SOiBibHVl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KUFJFIHsNCglGT05ULVNJWkU6IDEwcHQ7 IE1BUkdJTjogMGluIDBpbiAwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICJDb3VyaWVy IE5ldyINCn0NClRUIHsNCglGT05ULUZBTUlMWTogIkNvdXJpZXIgTmV3Ig0KfQ0KU1BBTi5FbWFp bFN0eWxlMTkgew0KCUNPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwNCn0NCkRJVi5TZWN0 aW9uMSB7DQoJcGFnZTogU2VjdGlvbjENCn0NCjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBsYW5n PUVOLVVTIHZMaW5rPWJsdWUgbGluaz1ibHVlIGJnQ29sb3I9d2hpdGU+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPlJvYmVydCwgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPkRvbid0IHdvcnJ5IHRvbyBtdWNoIGFib3V0IHRoZSBGRSBMRkIgYW5kIFByb3RvY29sIA0K TEZCLCBJIHRoaW5rIGl0IGNhbiBiZSBmaXQgaXQgd2VsbCBpbiB0aGUgc2VjdGlvbnMuPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFjdHVhbGx5IEkgY2FuIGRvIHNvbWV0aGlu ZyBmb3IgUHJvdG9jb2wgTEZCIGFuZCBGRSANCkxGQiBpZiB5b3UgdGhpbmsgcG9zc2libGUuPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlJlZ2FyZHMsPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5XZWltaW5nPC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCjxC TE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxF RlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlk OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgDQogIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRl NGU0OyBGT05UOiAxMHB0IGFyaWFsOyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0K ICA8QSB0aXRsZT1ob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tIA0KICBocmVmPSJtYWlsdG86 aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbSI+S2hvc3JhdmksIEhvcm11emQgTTwvQT4gPC9E SVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlRvOjwvQj4gPEEgdGl0bGU9 cmhhQHp1cmljaC5pYm0uY29tIA0KICBocmVmPSJtYWlsdG86cmhhQHp1cmljaC5pYm0uY29tIj5S b2JlcnQgSGFhczwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxC PkNjOjwvQj4gPEEgdGl0bGU9ZG9uZ2xnQG1haWwuaHppYy5lZHUuY24gDQogIGhyZWY9Im1haWx0 bzpkb25nbGdAbWFpbC5oemljLmVkdS5jbiI+TGlnYW5nIERvbmc8L0E+IDsgPEEgdGl0bGU9aGFk aUB6bnl4LmNvbSANCiAgaHJlZj0ibWFpbHRvOmhhZGlAem55eC5jb20iPmhhZGlAem55eC5jb208 L0E+IDsgPEEgdGl0bGU9YXZyaUBwc2cuY29tIA0KICBocmVmPSJtYWlsdG86YXZyaUBwc2cuY29t Ij5hdnJpQHBzZy5jb208L0E+IDsgPEEgdGl0bGU9cmFtLmdvcGFsQG5va2lhLmNvbSANCiAgaHJl Zj0ibWFpbHRvOnJhbS5nb3BhbEBub2tpYS5jb20iPnJhbS5nb3BhbEBub2tpYS5jb208L0E+IDsg PEEgDQogIHRpdGxlPXdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuIGhyZWY9Im1haWx0bzp3bXdhbmdA bWFpbC5oemljLmVkdS5jbiI+V2VpbWluZyANCiAgV2FuZzwvQT4gOyA8QSB0aXRsZT1mb3JjZXMt cHJvdG9jb2xAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpmb3JjZXMtcHJvdG9jb2xAaWV0Zi5v cmciPmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZP TlQ6IDEwcHQgYXJpYWwiPjxCPlNlbnQ6PC9CPiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMDQgNDoz NSANCiAgUE08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+U3ViamVj dDo8L0I+IFNlY3Rpb24gNiB1cGRhdGU8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVYg Y2xhc3M9U2VjdGlvbjE+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog bmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5IaSBSb2JlcnQsIA0KICBBbGw8L1NQQU4+PC9GT05U PjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBz aXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05U LUZBTUlMWTogQXJpYWwiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SGVyZSB5 b3UgZ2+FSSBoYXZlIA0KICB1cGRhdGVkIHNlY3Rpb25zIDYuMSwgNi4zLCA2LjYgKHJlbW92ZSks IDYuNyAoc2FtZSkuIEkgaGF2ZSBkaXJlY3RseSB1c2VkIHRoZSANCiAgdGV4dCB0aGF0IEphbWFs IHNlbnQgb3V0IHdoZXJldmVyIGFwcGxpY2FibGUuPC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFs Ij5Zb3UgY2FuIHVwZGF0ZSANCiAgc2VjdGlvbnMgNi4yLCA2LjQsIDYuNSAtJmd0OyBob3dldmVy LCBJIHdvdWxkIGNoZWNrIHdpdGggV2VpbWluZyBmaXJzdCBhcyANCiAgY291cnRlc3kgc2luY2Ug aGUgaXMgd29ya2luZyBvbiB0aGVzZSBzZWN0aW9ucy48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJp YWwiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+QlRXLCB0aGVyZSB3ZXJlIGxv dHMgDQogIG9mIHRoaW5ncyBpbiB0aGUgdG9kbyBsaXN0IEkgc2VudCBvdXSFPC9TUEFOPjwvRk9O VD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUg c2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9O VC1GQU1JTFk6IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPkhlYWRl ciBTZWN0aW9uIC0gDQogIEphbWFsL1JvYmVydC9XZWltaW5nPzwvU1BBTj48L0ZPTlQ+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+UHJvdG9jb2wgTEZCIC0gDQogIFJvYmVydC9PdGhlcnM/PC9TUEFOPjwvRk9OVD48 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6 ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1G QU1JTFk6IEFyaWFsIj5GRSBMRkIgLSANCiAgUm9iZXJ0L090aGVycz88L1NQQU4+PC9GT05UPjwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXpl PTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZB TUlMWTogQXJpYWwiPkNFIExGQiAtIA0KICA/PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5T dGF0ZSZuYnNwO01hY2hpbmUmbmJzcDtmb3ImbmJzcDtQcm90b2NvbCZuYnNwO5YmbmJzcDtMaWdh bmcgDQogICh0YWtlbik8L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjwvU1BBTj48L0ZPTlQ+ Jm5ic3A7PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1u YXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7 IEZPTlQtRkFNSUxZOiBBcmlhbCI+V2lsbCB5b3UgYmUgd29ya2luZyANCiAgb24gYW55IG9mIHRo ZXNlID8/PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNwOzwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXpl PTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZB TUlMWTogQXJpYWwiPlBscyBkbyBsZXQgdXMga25vd4VJIA0KICB3aWxsIHN0YXJ0IHdvcmtpbmcg b24gd2hhdGV2ZXIgaGFzbpJ0IGJlZW4gY2xhaW1lZCBieSB0b21vcnJvdyBtb3JuaW5nIG15IA0K ICB0aW1lLjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6 ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1G QU1JTFk6IEFyaWFsIj5UaGFua3M8L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPkhvcm11emQ8 L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICA8 RElWPg0KICA8RElWIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1BTElHTjogY2VudGVyIiBh bGlnbj1jZW50ZXI+PEZPTlQgDQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9YmxhY2sg c2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBDT0xPUjogd2luZG93dGV4 dCI+DQogIDxIUiB0YWJJbmRleD0tMSBhbGlnbj1jZW50ZXIgd2lkdGg9IjEwMCUiIFNJWkU9Mj4N CiAgPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxGT05UIGZh Y2U9VGFob21hIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hU OiBib2xkOyBGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULUZBTUlMWTog VGFob21hIj5Gcm9tOjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICBmYWNlPVRhaG9tYSBjb2xv cj1ibGFjayBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiB3 aW5kb3d0ZXh0OyBGT05ULUZBTUlMWTogVGFob21hIj4gUm9iZXJ0IEhhYXMgDQogIFttYWlsdG86 cmhhQHp1cmljaC5pYm0uY29tXSA8QlI+PEI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVdFSUdIVDog Ym9sZCI+U2VudDo8L1NQQU4+PC9CPiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMDQgMTI6MzkgDQog IEFNPEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+VG86PC9TUEFOPjwvQj4g S2hvc3JhdmksIEhvcm11emQgDQogIE08QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBi b2xkIj5DYzo8L1NQQU4+PC9CPiBMaWdhbmcgRG9uZzsgDQogIGhhZGlAem55eC5jb207IGF2cmlA cHNnLmNvbTsgcmFtLmdvcGFsQG5va2lhLmNvbTsgV2VpbWluZyBXYW5nOyANCiAgZm9yY2VzLXBy b3RvY29sQGlldGYub3JnPEJSPjxCPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQi PlN1YmplY3Q6PC9TUEFOPjwvQj4gUmU6IEFwcGx5aW5nIGNoYW5nZXMgdG8gU2VjdGlvbiANCiAg NiAoUHJvdG9jb2wgTWVzc2FnZXMpPC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPWJsYWNrIHNpemU9 Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8 L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNv bG9yPWJsYWNrIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+SG9ybXV6 ZCw8QlI+Q291bGQgeW91IHBsZWFzZSBwYXNzIHRoZSB0b2tlbiBvbiBzZWN0aW9uIA0KICA2IHRv Z2V0aGVyIHdpdGggeW91ciBsYXRlc3QgdmVyc2lvbiBzbyBJIGNhbiBzdGFydCBlZGl0aW5nIGl0 IA0KICA/PEJSPlRoYW5rcyw8QlI+LVJvYmVydDxCUj48QlI+S2hvc3JhdmksIEhvcm11emQgTSAN CiAgd3JvdGU6PEJSPjxCUj48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFs PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPlJvYmVydCw8L1NQ QU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgY29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MnB0Ij48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPkFzIEkgc2FpZCwgeW91ciBu b3RlIA0KICBtb3N0bHkgbG9va3MuLi5JIGhhdmUgcHV0IHNvbWUgbW9yZSBjb21tZW50cyBiZWxv dy4uLjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Q09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+KEl0Jm5ic3A7d291bGQmbmJzcDtoZWxw Jm5ic3A7YSZuYnNwO2xvdCZuYnNwO2lmJm5ic3A7eW91Jm5ic3A7c3RhcnQmbmJzcDtkZWZpbmlu ZyZuYnNwO3RoZSZuYnNwO0ZFLCZuYnNwO1Byb3RvY29sJm5ic3A7TEZCcy4uLik8L1NQQU4+PC9G T05UPjwvUD4NCiAgPERJViBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046IGNlbnRl ciIgYWxpZ249Y2VudGVyPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPWJs YWNrIHNpemU9Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4NCiAgPEhSIHRhYkluZGV4 PS0xIGFsaWduPWNlbnRlciB3aWR0aD0iMTAwJSIgU0laRT0yPg0KICA8L1NQQU4+PC9GT05UPjwv RElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PEZPTlQgZmFjZT1UYWhvbWEgY29sb3I9Ymxh Y2sgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTog MTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+RnJvbTo8L1NQQU4+PC9GT05UPjwvQj48Rk9OVCAN CiAgZmFjZT1UYWhvbWEgc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBUYWhvbWEiPiBSb2JlcnQgDQogIEhhYXMgWzxBIGhyZWY9Im1haWx0bzpyaGFAenVy aWNoLmlibS5jb20iPm1haWx0bzpyaGFAenVyaWNoLmlibS5jb208L0E+XSANCiAgPC9TUEFOPjwv Rk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIGNvbG9yPWJsYWNrIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ PEJSPkFsbDogYmVsb3cgaXMgYSByb3VnaCBsaXN0IG9mIGNoYW5nZXMgYW5kIHBlbmRpbmcgDQog IGlzc3VlcyByZWdhcmRpbmcgc2VjdGlvbiA2LiBQbGVhc2UgcmV2aWV3LjxCUj48QlI+Jm5ic3A7 Ni4xLjEgQXNzb2NpYXRpb246IFRoZSANCiAgQ0UgY291bGQgb2J0YWluIHRoZSBIQkkgd2l0aCBh IFF1ZXJ5LVNHVC1GRVByb3RvY29sTEZQLUhlYXJ0YmVhdEludGVydmFsLiANCiAgR2l2ZW4gdGhl IG5ldyBBc3NvYyBtc2cgc3RyY3V0cnVlLCB3ZSBoYXZlIHRvIHJlbW92ZSBIQkkgZnJvbSB0aGUg QXNzb2MgU2V0dXAgDQogIG1zZy48L1NQQU4+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 Ymx1ZSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVl OyBGT05ULUZBTUlMWTogQXJpYWwiPiZuYnNwOyBbQWdyZWVkLCB0aGlzIA0KICB3b3VsZCBiZSBw YXJ0IG9mIFByb3RvY29sTEZCIGV2ZW4gaWYgaXQgaXMgaW4gdGhpcyANCiAgbWVzc2FnZV0mbmJz cDs8L1NQQU4+PC9GT05UPjxCUj48QlI+Jm5ic3A7Ni4xLjIgSG93IGhhcyB0aGUgc3JjSUQ9MCBj YXNlIGJlZW4gDQogIGhhbmRsZWQgaW4gdGhlIGludGVyb3AgdGVzdHMgPyBJcyB0aGlzIHJlYWxs eSBmZWFzaWJsZSA/PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJp YWwiPiZuYnNwOyBbWWVzIGl0IHdvcmtlZCANCiAgZmluZSBkdXJpbmcgSW50ZXJvcF0mbmJzcDs8 L1NQQU4+PC9GT05UPjxCUj48QlI+Jm5ic3A7Ni4yIFF1ZXJ5OiBjb2Fyc2UgRkUgDQogIGluZm8g KGludGVyL2ludHJhLUZFIHRvcG9sb2d5LCBldGMpIGdvZXMgaW50byB0aGUgRkVQcm90b2NvbExG Qi48Rk9OVCANCiAgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7 IFtBZ3JlZWQgaXQgDQogIHdvdWxkIGJlIGluIHNvbWUgTEZCLCBidXQgbm90IHN1cmUgd2hpY2gg TEZCIHRoaXMgd291bGQgYmUgcGFydCANCiAgb2YuLi4/XSZuYnNwOzwvU1BBTj48L0ZPTlQ+PEJS PjxCUj4mbmJzcDs2LjQ6IEV2ZW50czogY29hcnNlIENFIGFuZCBGRSBldmVudHMgDQogIGdvIGlu dG8gQ0UvRkVQcm90b2NvbExGQi4gTm90ZSB0aGF0IGZvciB0aGUgc2FrZSBvZiBzeW1tZXRyeSwg d2Ugc2hvdWxkIA0KICBpbnRyb2R1Y2UgYSBDRVByb3RvY29sTEZCLjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPiZuYnNwOyBbU3VyZSwgd2h5IA0KICBkb250IHlv dSBzdGFydCBkZWZpbmluZyBzb21lIG9mIHRoZXNlIG9iamVjdHMuLi50aGVuIHdlIGNhbiBkaXNj dXNzIG1vcmUgaW4gDQogIGRldGFpbF0mbmJzcDs8L1NQQU4+PC9GT05UPjxCUj48QlI+Jm5ic3A7 Ni42IFN0YXRlIE1haW50ZW5hbmNlOiBGRSANCiAgQWN0aXZhdGUvRGVhY3RpdmF0ZS9TaHV0ZG93 biBiZWNvbWUgc2V0dGFibGUgYXR0cmlidXRlcyBpbiB0aGUgDQogIEZFUHJvdG9jb2xMRkIuPEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7Jm5ic3A7W1ll cywgDQogIHRoZXNlIG1lc3NhZ2VzIHdpbGwgYmUgcGFydCBvZiBFdmVudHMgb3IgQ29uZmlnLi4u d2UgbmVlZCB0byBzcGVjaWZ5IA0KICB0aGlzXSZuYnNwOzwvU1BBTj48L0ZPTlQ+PEJSPjxCUj4m bmJzcDs2LjcgSEIgcmVtYWlucyBhcyBpcy48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj1ibHVl IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZP TlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7IA0KICBbQWdyZWVkXSZuYnNwOzwvU1BBTj48L0ZPTlQ+ PEJSPjxCUj5JbiBzdW1tYXJ5LCB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcgDQogIG9wZXJhdGlvbnMg ZGVmaW5lZCBmb3IgZWFjaCBtZXNzYWdlIHR5cGUgKCBJIGJyb2tlIHRoZSB0YWJsZSBpbnRvIDMg DQogIHBhcnRzKTo8QlI+PFRUPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQ QU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTog QXJpYWwiPiZuYnNwO1tsb29rcyANCiAgZ29vZCFdJm5ic3A7PC9TUEFOPjwvRk9OVD48L1RUPjxG T05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnIj48QlI+PFRUPjxGT05UIA0KICBmYWNl PSJDb3VyaWVyIE5ldyI+T1BFUkFUSU9OJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEFQUExJQ0FCTEUgDQogIE1FU1NBR0UgVFlQRVM8L0ZPTlQ+PC9UVD48QlI+PEJSPjxUVD48 Rk9OVCANCiAgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyANCiAgJm5ic3A7Jm5ic3A7IEFzc29jLVNldHVw Jm5ic3A7IEFzc29jLVNldHVwLVJlc3AgQXNzb2MtVGVhcmRvd24gDQogIEhlYXJ0YmVhdDwvRk9O VD48L1RUPjxCUj48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5ubyANCiAgb3BlcmF0 aW9uczwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3Ij5kZWZp bmVkPC9GT05UPjwvVFQ+PEJSPjxCUj48QlI+PFRUPjxGT05UIA0KICBmYWNlPSJDb3VyaWVyIE5l dyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7IA0KICAmbmJzcDsmbmJzcDsgUXVlcnkmbmJzcDsgUXVlcnktUmVzcCZuYnNwOyBDb25maWcm bmJzcDsgDQogIENvbmZpZy1SZXNwPC9GT05UPjwvVFQ+PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+U0VULCBERUwsIFVQREFURSANCiAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IA0KICAmbmJzcDsmbmJzcDsgeCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgeDwvRk9OVD48L1RUPjxCUj48VFQ+PEZP TlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3Ij5HRVQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg DQogIHgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeDwv Rk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3Ij5FVl9TLCBFVl9V IA0KICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgDQogICZuYnNwOyAmbmJzcDsmbmJzcDsgeCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgeDwvRk9OVD48L1RUPjxCUj48 QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4oZm9yIGV2ZW50IA0KICBzdWJzY3JpYmUv dW5zdWJzY3JpYmUpPC9GT05UPjwvVFQ+PEJSPjxCUj48QlI+PFRUPjxGT05UIA0KICBmYWNlPSJD b3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsgDQogICZuYnNwOyZuYnNwOyAmbmJzcDsgUGFja2V0LVJlZGlyPC9GT05UPjwvVFQ+PEJS PjxCUj48VFQ+PEZPTlQgDQogIGZhY2U9IkNvdXJpZXIgTmV3Ij5QQVlMT0FEJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K ICB4PC9GT05UPjwvVFQ+PEJSPjxCUj48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4m bmJzcDsgJm5ic3A7ICZuYnNwOyANCiAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7 Jm5ic3A7IEV2ZW50LU5vdGlmJm5ic3A7IA0KICBFdmVudC1Ob3RpZi1SZXNwPC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+RVZFTlQgJm5ic3A7IA0KICAmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICB4Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICB4PC9GT05UPjwvVFQ+PEJSPjwvU1BB Tj48L0ZPTlQ+PEJSPk5vdGUgdGhhdCBmb3IgUXVlcnkoLVJlc3ApLCBQYWNrZXQtUmVkaXIsIA0K ICBhbmQgRXZlbnQtTm90aWYoLVJlc3ApLCB3ZSBoYXZlIGVhY2ggdGltZSBvbmx5IG9uZSBvcGVy YXRpb24uIExvb2tzIGEgYml0IA0KICByZWR1bmRhbnQuIElkZWFzID88Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xP UjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDsgW1RoZXNlIGFyZSBhbGwgDQogIHZl cnkgZGlmZmVyZW50LCBsZXRzIGxlYXZlIHRoZW0gYXMgaXMsIGl0cyBub3QgbmVjZXNzYXJ5IHRv IGhhdmUgbXVsdGlwbGUgDQogIG9wZXJhdGlvbnMgaW4gYWxsIG1lc3NhZ2VzXSZuYnNwOzwvU1BB Tj48L0ZPTlQ+PEJSPjxCUj5SZWdhcmRzLDxCUj4tUm9iZXJ0PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibGFjayBzaXplPTM+PFNQ QU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxCUj48QlI+PC9TUEFOPjwvRk9OVD48L1A+ PFBSRT48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQiPi0tIDwvU1BBTj48L0ZPTlQ+PC9QUkU+PFBSRT48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyIgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQiPlJvYmVydCBIYWFzPC9TUEFOPjwvRk9OVD48L1BSRT48UFJFPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3IiBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTog MTBwdCI+SUJNIFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5PC9TUEFOPjwvRk9OVD48L1BSRT48 UFJFPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gc3R5 bGU9IkZPTlQtU0laRTogMTBwdCI+U+R1bWVyc3RyYXNzZSA0PC9TUEFOPjwvRk9OVD48L1BSRT48 UFJFPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gc3R5 bGU9IkZPTlQtU0laRTogMTBwdCI+Q0gtODgwMyBS/HNjaGxpa29uL1N3aXR6ZXJsYW5kPC9TUEFO PjwvRk9OVD48L1BSRT48UFJFPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBjb2xvcj1ibGFjayBz aXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+cGhvbmUgKzQxLTEtNzI0LTg2OTgm bmJzcDsgZmF4ICs0MS0xLTcyNC04NTc4Jm5ic3A7IDxBIGhyZWY9Imh0dHA6Ly93d3cuenVyaWNo LmlibS5jb20vfnJoYSI+aHR0cDovL3d3dy56dXJpY2guaWJtLmNvbS9+cmhhPC9BPjwvU1BBTj48 L0ZPTlQ+PC9QUkU+PC9ESVY+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0FE3_01C4B859.E35B0610-- --===============1665359423== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1665359423==-- From forces-protocol-bounces@ietf.org Fri Oct 22 05:41:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15822 for ; Fri, 22 Oct 2004 05:41:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKw8L-00023J-W7 for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 05:54:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKvtB-0007QZ-Aw; Fri, 22 Oct 2004 05:39:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKvjL-0004An-By for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 05:29:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15182 for ; Fri, 22 Oct 2004 05:29:00 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKvw5-0001qx-KW for forces-protocol@ietf.org; Fri, 22 Oct 2004 05:42:15 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9M9SSJ8478996 for ; Fri, 22 Oct 2004 05:28:28 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9M9SSAm155670 for ; Fri, 22 Oct 2004 03:28:28 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9M9SRLg024198 for ; Fri, 22 Oct 2004 03:28:28 -0600 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9M9SPpl024151; Fri, 22 Oct 2004 03:28:25 -0600 Received: from [9.145.128.188] (sig-9-145-128-188.de.ibm.com [9.145.128.188]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA29634; Fri, 22 Oct 2004 11:28:21 +0200 Message-ID: <4178D2A9.3040207@zurich.ibm.com> Date: Fri, 22 Oct 2004 11:28:09 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E0257920D@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0257920D@orsmsx408> X-Spam-Score: 0.5 (/) X-Scan-Signature: a7b3e2e89e2e73a6185808e636222e06 Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Weiming Wang Subject: [Forces-protocol] Re: Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1318190653==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 53b2663681a067d6bc137eb1242b2dac This is a multi-part message in MIME format. --===============1318190653== Content-Type: multipart/alternative; boundary="------------000805020300080201070002" This is a multi-part message in MIME format. --------------000805020300080201070002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id i9M9SSJ8478996 Content-Transfer-Encoding: quoted-printable Hi Hormuzd, Yes, I will take care of the FE, CE, and Protocol LFBs. In-line are some comments to your updates. Good job to you and Weiming.=20 We still need to refine a few things. Please review and let me know. -Robert Khosravi, Hormuzd M wrote: > 6. Protocol Messages > >The general structure of most messages is as follows in BNF format: > >PL level PDU : =3D MAINHDR+=20 >LFBselect :=3D LFBCLASSID LFBInstance + >OPER:=3D ]*>+ > > =20 > I think we should now make our terminology consistent and use "FE LFB"=20 and "FE Protocol LFB" instead of Object or Managed Object. I know it=20 will make Weiming unhappy, but I find it less confusing. The reason is=20 that we treat regular LFBs and the FE Object and FE Protocol Object in=20 the same manner in the protocol ("Everything is an LFB"). >- MAINHDR defines msg type, Target FE/CE ID etc. >the MAINHDR also defines the content. As an example the content of >a "config" message would be different from an "association" message. >- LFBCLASSID is a 32 bit unique identifier per LFB class defined >at class creation time. >- LFBInstance is a 32 bit unique instance identifier of an LFB class >- OPERATION is one of {ADD,DEL,etc.} depending on the message type > >The path-data identifies the exact element targeted. >It may have zero or more data values associated. > >In summary this approach has the following characteristic: >- there can be one or more LFB Class + InstanceId combo >targeted in a message (batch) >- There can one or more operation on an addressed LFB=20 >classid+instanceid combo(batch)=20 >- There can be one or more path targets per operation (batch) >- paths may have zero or more data values associated (flexibility >and operation specific) > >It should be noted that the above is optimized for the case of a >a single classid+instance targeting. To target multiple instances >within the same class, multiple LFBselect are needed.=20 > > >6.1 Association Messages > > The ForCES Association messages are used to establish and teardown > associations between FEs and CEs. > >6.1.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 'Association > Setup'. 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 setup message body consists of LFBSelect & FE Name TLV, the fo= rmat of > which is as follows: > >main hdr (eg type =3D Association setup) > | > | > +--- T =3D LFBselect > | | > | +-- LFBCLASSID =3D FE object > | | > | | > | +-- LFBInstance =3D 0x1 > | =20 > +--- T =3D FENAME > | > +-- "myname" > > > =20 > To me, FE Name is an attribute of the FE Protocol Object/LFB (not the FE=20 Object/LFB) that can be advertised by the FE. Let's define a new "SHOW"=20 operation for that purpose. The message would therefore look like: main hdr (eg type =3D Association setup) | | +--- T =3D LFBselect | +-- LFBCLASSID =3D FE object | | +-- LFBInstance =3D 0x1 | | +-- T =3D operation SHOW | +-- FE NAME (path target) What do you think ? A better name than "SHOW" ? > 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 LFB select | Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID =3D FE Object = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > | FE Object LFB (including HBI, etc) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D FE Name | Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > | FE Name string | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 8 > > Type (16 bits): > LFB Select. > Length (16 bits): > Length of the TLV including the T and L fields, in bytes. > FE Object LFB: > The FE parameters e.g. HBI will be exchanged with the CE using thi= s LFB. > =20 > > FE Name String: > This is a variable length string which contains the FE name and > is encoded in a TLV. > > Editorial Note: In certain situations (such as use of multicast > IDs), it might not be possible to make use of the > procedure described above for the FE to > dynamically obtain an ID from the CE. Such > situations need to be identified. > >6.1.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. > > Message transfer direction: > CE to FE > Message Header: > The Message Type in the header is set MessageType=3D 'Setup > Response'. 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 setup response message body consists of LFBSelect & Result TL= V, the format > of which is as follows: > > >main hdr (eg type =3D Association setup response) > | > | > +--- T =3D LFBselect > | | > | +-- LFBCLASSID =3D FE object > | | > | | > | +-- LFBInstance =3D 0x1 > | =20 > +--- T =3D FEResult > | > +-- resultvalue > > > 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 LFB select | Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID =3D FE Object = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > | FE Object LFB (including HBI, etc) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D Result | Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 9 > > Type (16 bits): > LFB Select. > Length (16 bits): > Length of the TLV including the T and L fields, in bytes. > FE Object LFB: > The FE parameters e.g. HBI may be exchanged using this LFB. > Result (16 bits): > This indicates whether the setup msg was successful or whether > the FE request was rejected by the CE. > >6.1.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. > > 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 "Asso. > Teardown". 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 consists of LFBSelect & FER= eason TLV, the > format of which is as follows: > >main hdr (eg type =3D Association tear) > | > | > +--- T =3D LFBselect > | | > | +-- LFBCLASSID =3D FE object > | | > | | > | +-- LFBInstance =3D 0x1 > | =20 > +--- T =3D FEReason > | > +-- "myreason" > > > > 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 LFB select | Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID =3D FE Object = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > | FE Object LFB (including HBI, etc) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D T.reason | Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reason | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 10 > > Type (16 bits): > LFB Select. > Length (16 bits): > Length of the TLV including the T and L fields, in bytes. > FE Object LFB: > The FE parameters may be exchanged using this LFB. > T.reason (32 bits): > This indicates the reason why the association is being > terminated. > > >6.3 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.3.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, LFB events. > > Message transfer direction: > CE to FE > Message Header: > The Message Type in the header is set MessageType=3D 'Config'. T= he > 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 one or more TLVs, the format > of the TLVs/message is as follows: > > >main hdr (eg type =3D config) > | > | > +--- T =3D LFBselect > | | > | +-- LFBCLASSID =3D target LFB class > | | > | | > | +-- LFBInstance =3D target LFB instance=20 > | | > | | > | +-- T =3D operation { ADD, DEL, etc} > | | | > | | +-- // one or more path targets=20 > | | // under discussion > | | > | +-- T =3D operation { ADD, DEL, etc} > | | | > | | +-- // one or more path targets=20 > | | // under discussion > | | > | +-- T =3D operation { ADD, DEL, etc} > | | | > | | +-- // one or more path targets=20 > | | // under discussion > | | > > > 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 LFB select | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D Operations (ADD) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Event Type | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Config data | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D Operations (DEL) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Event Type | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Config data | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 16 > > Type (16 bits): > LFB Select. > Length (16 bits): > Length of the TLV including the T and L fields, in bytes. > LFB Class ID (16 bits): > This field uniquely recognizes the LFB class/type. > LFB Instance ID (16 bits): > This field uniquely identifies the LFB instance. > > Type (16 bits): > The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, SUBSCR= IBE, > UNSUBSCRIBE, CANCEL. The following Types are defined for this > TLV: > * Add, Del, Update, Del All, Cancel, Subscribe, Unsubscribe > events > Length (16 bits): > Length of the TLV including the T and L fields, in bytes. > Event Type (16 bits): > For SUBSCRIBE, UNSUBSCRIBE Events Type TLVs, an Event Type field > will define the Events of interest. Examples of Event Type > include, All Events, FE Events, LFB Events, Packets, Packet > Mirroring. > =20 > I am not comfortable with these Event Type flags that appear for every=20 operation (ADD, GET, DEL, etc) but are only used for EV_S and EV_U. I propose to do this differently: main hdr (eg type =3D config) | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D target LFB class | | | | | +-- LFBInstance =3D target LFB instance=20 | | | | | +-- T =3D operation =3D EV_S | | | | | +-- // one or more path targets (i.e., events to subsc= ribe)=20 | | // under discussion And define the following attributes in their respective LFB/Objects: - in each specific LFB (including the FE Object), an attribute for each=20 event it can fire, and possibly an attribute for "AllLFBEvents" that can=20 be subscribed to and corresponds to subscribing to all events of that=20 LFB (model team should look at this). I don't know what a "Packets", or "Packet Mirroring" event corresponds=20 to. If this is a redirected packet, then we have already a special=20 message type for it. > Config Data (variable length): > This will carry LFB specific data (,single or Array LFB spe= cific > entries). The config data might itself be of the form of a TLV. > >*Note: FE Activate/Deactivate, Shutdown FE commands for State Maintenanc= e will > be sent using Config messages. >=20 > >6.3.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). > Message body: > The Config response message body consists of one or more TLVs, > the format of the TLVs/message 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 LFB select | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D Operations (ADD) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Overall Result | reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Config Result | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D Operations (DEL) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Overall Result | reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Config Result | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 17 > > Type (16 bits): > LFB Select. > Length (16 bits): > Length of the TLV including the T and L fields, in bytes. > LFB Class ID (16 bits): > This field uniquely recognizes the LFB class/type. > LFB Instance ID (16 bits): > This field uniquely identifies the LFB instance. > > Type (16 bits): > The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, SUBSCR= IBE, > UNSUBSCRIBE, CANCEL. The following Types are defined for this > TLV: > * Add, Del, Update, Del All, Cancel, Subscribe, Unsubscribe > events > Length (16 bits): > Length of the TLV including the T and L fields, in bytes. > Overall Result (16 bits): > This indicates the overall result of the config message, whether > it was successful or it failed. > =20 > But you have multiple overall results in the same config message. This=20 should be fixed. > Config Result (variable length): > This will carry LFB specific results (single or Array LFB > specific result entries). The config result might itself be of > the form of a TLV. > > >6.6. -> Remove this section > > =20 > and I will put the necessary things in the FE Object/LFB or FE Protocol=20 Object/LFB. >6.7 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 to send the message is set by the Association Setup > Message described in Section 6.1.1. A little different from other > protocol messages, a Heartbeat messge is only composed of a common > header, withe the message body left empty. Detailed description of > =20 > Typo above (withe). > 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. > Message Body: > The message body is empty for the Heartbeat Message, so as to > grasp more efficiency for message transportation and processing. > > > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------000805020300080201070002 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Hormuzd,
Yes, I will take care of the FE, CE, and Protocol LFBs.
In-line are some comments to your updates. Good job to you and Weiming. We still need to refine a few things. Please review and let me know.
-Robert

Khosravi, Hormuzd M wrote:
6. Protocol Messages
The general structure of most messages is as follows in BNF format:

PL level PDU : = MAINHDR<LFBselect>+ 
LFBselect := LFBCLASSID LFBInstance <OPER>+
OPER:= <OPERATION [<path-data>]*>+
I think we should now make our terminology consistent and use "FE LFB" and "FE Protocol LFB" instead of Object or Managed Object. I know it will make Weiming unhappy, but I find it less confusing. The reason is that we treat regular LFBs and the FE Object and FE Protocol Object in the same manner in the protocol ("Everything is an LFB").

- MAINHDR defines msg type, Target FE/CE ID etc.
the MAINHDR also defines the content. As an example the content of
a "config" message would be different from an "association" message.
- LFBCLASSID is a 32 bit unique identifier per LFB class defined
at class creation time.
- LFBInstance is a 32 bit unique instance identifier of an LFB class
- OPERATION is one of {ADD,DEL,etc.} depending on the message type

The path-data identifies the exact element targeted.
It may have zero or more data values associated.

In summary this approach has the following characteristic:
- there can be one or more LFB Class + InstanceId combo
targeted in a message (batch)
- There can one or more operation on an addressed LFB 
classid+instanceid combo(batch) 
- There can be one or more path targets per operation (batch)
- paths may have zero or more data values associated (flexibility
and operation specific)

It should be noted that the above is optimized for the case of a
a single classid+instance targeting. To target multiple instances
within the same class, multiple LFBselect are needed. 


6.1  Association Messages

   The ForCES Association messages are used to establish and teardown
   associations between FEs and CEs.

6.1.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= 'Association
      Setup'.  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 setup message body consists of LFBSelect & FE Name TLV, the format of
      which is as follows:

main hdr (eg type =  Association setup)
     |
     |
     +--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = FE object
     |        |
     |        |
     |        +-- LFBInstance = 0x1
     |        
     +--- T = FENAME
              |
              +-- "myname"
To me, FE Name is an attribute of the FE Protocol Object/LFB (not the FE Object/LFB) that can be advertised by the FE. Let's define a new "SHOW" operation for that purpose.

The message would therefore look like:

main hdr (eg type =  Association setup)
     |
     |
     +--- T = LFBselect
              |
              +-- LFBCLASSID = FE object
              |
              |
              +-- LFBInstance = 0x1

              |
              |
              +-- T = operation SHOW
                  |
                  +-- FE NAME (path target)
What do you think ? A better name than "SHOW" ?

        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 = LFB select      |               Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 LFB Class ID = FE Object                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        LFB Instance ID                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       |                   FE Object LFB (including HBI, etc)          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Type = FE Name         |               Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       |                       FE Name string                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                Figure 8

   Type (16 bits):
      LFB Select.
   Length (16 bits):
      Length of the TLV including the T and L fields, in bytes.
   FE Object LFB:
      The FE parameters e.g. HBI will be exchanged with the CE using this LFB.
  
   FE Name String:
      This is a variable length string which contains the FE name and
      is encoded in a TLV.

      Editorial Note:  In certain situations (such as use of multicast
                       IDs), it might not be possible to make use of the
                       procedure described above for the FE to
                       dynamically obtain an ID from the CE.  Such
                       situations need to be identified.

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

   Message transfer direction:
       CE to FE
   Message Header:
       The Message Type in the header is set MessageType= 'Setup
       Response'.  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 = 0).
   Message body:
       The setup response message body consists of LFBSelect & Result TLV, the format
       of which is as follows:


main hdr (eg type =  Association setup response)
     |
     |
     +--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = FE object
     |        |
     |        |
     |        +-- LFBInstance = 0x1
     |        
     +--- T = FEResult
              |
              +-- resultvalue


         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 = LFB select      |               Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 LFB Class ID = FE Object                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        LFB Instance ID                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       |                   FE Object LFB (including HBI, etc)          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Type = Result           |               Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Result                |              Reserved         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                Figure 9

   Type (16 bits):
       LFB Select.
   Length (16 bits):
       Length of the TLV including the T and L fields, in bytes.
   FE Object LFB:
      The FE parameters e.g. HBI may be exchanged using this LFB.
   Result (16 bits):
       This indicates whether the setup msg was successful or whether
       the FE request was rejected by the CE.

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

   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= "Asso.
       Teardown".  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 consists of LFBSelect & FEReason TLV, the
       format of which is as follows:

main hdr (eg type =  Association tear)
     |
     |
     +--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = FE object
     |        |
     |        |
     |        +-- LFBInstance = 0x1
     |        
     +--- T = FEReason
              |
              +-- "myreason"



        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 = LFB select      |               Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 LFB Class ID = FE Object                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        LFB Instance ID                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       |                   FE Object LFB (including HBI, etc)          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Type = T.reason       |               Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Reason                                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                               Figure 10

   Type (16 bits):
       LFB Select.
   Length (16 bits):
       Length of the TLV including the T and L fields, in bytes.
   FE Object LFB:
      The FE parameters may be exchanged using this LFB.
   T.reason (32 bits):
       This indicates the reason why the association is being
       terminated.


6.3  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.3.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, LFB events.

   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
       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 one or more TLVs, the format
       of the TLVs/message is as follows:


main hdr (eg type = config)
     |
     |
     +--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = target LFB class
     |        |
     |        |
     |        +-- LFBInstance = target LFB instance 
     |        |
     |        |
     |        +-- T = operation { ADD, DEL,  etc}
     |        |   |
     |        |   +--  // one or more path targets 
     |        |        // under discussion
     |        |
     |        +-- T = operation { ADD, DEL,  etc}
     |        |   |
     |        |   +--  // one or more path targets 
     |        |        // under discussion
     |        |
     |        +-- T = operation { ADD, DEL,  etc}
     |        |   |
     |        |   +--  // one or more path targets 
     |        |        // under discussion
     |        |


      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 = LFB select      |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          LFB Class ID                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        LFB Instance ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type = Operations (ADD)    |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Event Type          |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Config data                           |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type = Operations (DEL)    |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Event Type          |             Reserved          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Config data                           |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               Figure 16

   Type (16 bits):
       LFB Select.
   Length (16 bits):
       Length of the TLV including the T and L fields, in bytes.
   LFB Class ID (16 bits):
       This field uniquely recognizes the LFB class/type.
   LFB Instance ID (16 bits):
       This field uniquely identifies the LFB instance.

   Type (16 bits):
       The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, SUBSCRIBE,
       UNSUBSCRIBE, CANCEL.  The following Types are defined for this
       TLV:
       *   Add, Del, Update, Del All, Cancel, Subscribe, Unsubscribe
           events
   Length (16 bits):
       Length of the TLV including the T and L fields, in bytes.
   Event Type (16 bits):
       For SUBSCRIBE, UNSUBSCRIBE Events Type TLVs, an Event Type field
       will define the Events of interest.  Examples of Event Type
       include, All Events, FE Events, LFB Events, Packets, Packet
       Mirroring.
I am not comfortable with these Event Type flags that appear for every operation (ADD, GET, DEL, etc) but are only used for EV_S and EV_U.

I propose to do this differently:

main hdr (eg type = config)
     |
     |
     +--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = target LFB class
     |        |
     |        |
     |        +-- LFBInstance = target LFB instance 
     |        |
     |        |
     |        +-- T = operation = EV_S
     |        |   |
     |        |   +--  // one or more path targets (i.e., events to subscribe) 
     |        |        // under discussion

And define the following attributes in their respective LFB/Objects:
 - in each specific LFB (including the FE Object), an attribute for each event it can fire, and possibly an attribute for "AllLFBEvents" that can be subscribed to and corresponds to subscribing to all events of that LFB (model team should look at this).
I don't know what a "Packets", or "Packet Mirroring" event corresponds to. If this is a redirected packet, then we have already a special message type for it.


   Config Data (variable length):
       This will carry LFB specific data (<path>,single or Array LFB specific
       entries).  The config data might itself be of the form of a TLV.

*Note: FE Activate/Deactivate, Shutdown FE commands for State Maintenance will
      be sent using Config messages.
 

6.3.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= '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).
   Message body:
       The Config response message body consists of one or more TLVs,
       the format of the TLVs/message 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 = LFB select      |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          LFB Class ID                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        LFB Instance ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type = Operations (ADD)    |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Overall Result            |           reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Config Result                         |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type = Operations (DEL)    |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Overall Result            |           reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Config Result                         |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               Figure 17

   Type (16 bits):
       LFB Select.
   Length (16 bits):
       Length of the TLV including the T and L fields, in bytes.
   LFB Class ID (16 bits):
       This field uniquely recognizes the LFB class/type.
   LFB Instance ID (16 bits):
       This field uniquely identifies the LFB instance.

   Type (16 bits):
       The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, SUBSCRIBE,
       UNSUBSCRIBE, CANCEL.  The following Types are defined for this
       TLV:
       *   Add, Del, Update, Del All, Cancel, Subscribe, Unsubscribe
           events
   Length (16 bits):
       Length of the TLV including the T and L fields, in bytes.
   Overall Result (16 bits):
       This indicates the overall result of the config message, whether
       it was successful or it failed.
But you have multiple overall results in the same config message. This should be fixed.
   Config Result (variable length):
       This will carry LFB specific results (single or Array LFB
       specific result entries).  The config result might itself be of
       the form of a TLV.


6.6. -> Remove this section
and I will put the necessary things in the FE Object/LFB or FE Protocol Object/LFB.
6.7  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 to send the message is set by the Association Setup
   Message described in Section 6.1.1.  A little different from other
   protocol messages, a Heartbeat messge is only composed of a common
   header, withe the message body left empty.  Detailed description of
Typo above (withe).
   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 =
       '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.
   Message Body:
       The message body is empty for the Heartbeat Message, so as to
       grasp more efficiency for message transportation and processing.




  

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------000805020300080201070002-- --===============1318190653== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1318190653==-- From forces-protocol-bounces@ietf.org Fri Oct 22 05:44:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16010 for ; Fri, 22 Oct 2004 05:44:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKwBH-00027x-16 for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 05:57:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKvtP-0007S8-M7; Fri, 22 Oct 2004 05:39:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKvo6-0005v1-Lt for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 05:33:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15352 for ; Fri, 22 Oct 2004 05:33:55 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKw0r-0001ur-Lj for forces-protocol@ietf.org; Fri, 22 Oct 2004 05:47:10 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9M9XOJ8552618 for ; Fri, 22 Oct 2004 05:33:24 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9M9XOSE361320 for ; Fri, 22 Oct 2004 03:33:24 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9M9XOv7027396 for ; Fri, 22 Oct 2004 03:33:24 -0600 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9M9XLeS027373; Fri, 22 Oct 2004 03:33:22 -0600 Received: from [9.145.128.188] (sig-9-145-128-188.de.ibm.com [9.145.128.188]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA56656; Fri, 22 Oct 2004 11:33:19 +0200 Message-ID: <4178D3D1.3080608@zurich.ibm.com> Date: Fri, 22 Oct 2004 11:33:05 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wang,Weiming" References: <468F3FDA28AA87429AD807992E22D07E0257920D@orsmsx408> <0fe601c4b816$d55930c0$845c21d2@Necom.hzic.edu.cn> In-Reply-To: <0fe601c4b816$d55930c0$845c21d2@Necom.hzic.edu.cn> X-Spam-Score: 0.8 (/) X-Scan-Signature: 539f8b288ab42db633e5c7cf1c34fca1 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Ligang Dong Subject: [Forces-protocol] Re: Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1518817690==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b271b9c4fc51b08326fa0949e61c0156 This is a multi-part message in MIME format. --===============1518817690== Content-Type: multipart/alternative; boundary="------------070608010508050101010906" This is a multi-part message in MIME format. --------------070608010508050101010906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id i9M9XOJ8552618 Content-Transfer-Encoding: quoted-printable Weiming. I suggest we make a new section "FE LFB and FE Protocol LFB" just=20 before Section 5 "Common Header", instead of leaving this to section=20 3.3.2. This will reflect the importance of those two LFBs in the=20 operation of the protocol. I'll post my text when ready, please do the same, and we'll merge. -Robert Wang,Weiming wrote: > Robert, > =20 > Don't worry too much about the FE LFB and Protocol LFB, I think it can=20 > be fit it well in the sections. > =20 > Actually I can do something for Protocol LFB and FE LFB if you think=20 > possible. > =20 > Regards, > Weiming > =20 > ----- Original Message ----- > > From: Khosravi, Hormuzd M > To: Robert Haas > Cc: Ligang Dong ; hadi@znyx.com > ; avri@psg.com ; > ram.gopal@nokia.com ; Weiming Wang > ; forces-protocol@ietf.org > > Sent: Friday, October 22, 2004 4:35 PM > Subject: Section 6 update > > Hi Robert, All > > =20 > > Here you go...I have updated sections 6.1, 6.3, 6.6 (remove), 6.7 > (same). I have directly used the text that Jamal sent out wherever > applicable. > > You can update sections 6.2, 6.4, 6.5 -> however, I would check > with Weiming first as courtesy since he is working on these section= s. > > =20 > > BTW, there were lots of things in the todo list I sent out... > > =20 > > Header Section - Jamal/Robert/Weiming? > > Protocol LFB - Robert/Others? > > FE LFB - Robert/Others? > > CE LFB - ? > > State Machine for Protocol - Ligang (taken) > > =20 > > Will you be working on any of these ?? > > =20 > > Pls do let us know...I will start working on whatever hasn't been > claimed by tomorrow morning my time. > > =20 > > Thanks > > Hormuzd > > =20 > > -------------------------------------------------------------------= ----- > > From: Robert Haas [mailto:rha@zurich.ibm.com] > Sent: Friday, October 22, 2004 12:39 AM > To: Khosravi, Hormuzd M > Cc: Ligang Dong; hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com; > Weiming Wang; forces-protocol@ietf.org > Subject: Re: Applying changes to Section 6 (Protocol Messages) > > =20 > > Hormuzd, > Could you please pass the token on section 6 together with your > latest version so I can start editing it ? > Thanks, > -Robert > > Khosravi, Hormuzd M wrote: > > Robert, > > =20 > > As I said, your note mostly looks...I have put some more comments > below... > > (It would help a lot if you start defining the FE, Protocol LFBs...= ) > > -------------------------------------------------------------------= ----- > > From: Robert Haas [mailto:rha@zurich.ibm.com] > > > All: below is a rough list of changes and pending issues regarding > section 6. Please review. > > 6.1.1 Association: The CE could obtain the HBI with a > Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg > strcutrue, we have to remove HBI from the Assoc Setup msg.=20 > [Agreed, this would be part of ProtocolLFB even if it is in this > message]=20 > > 6.1.2 How has the srcID=3D0 case been handled in the interop tests > ? Is this really feasible ? [Yes it worked fine during Interop]=20 > > 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes > into the FEProtocolLFB. [Agreed it would be in some LFB, but not > sure which LFB this would be part of...?]=20 > > 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. > Note that for the sake of symmetry, we should introduce a > CEProtocolLFB. [Sure, why dont you start defining some of these > objects...then we can discuss more in detail]=20 > > 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become > settable attributes in the FEProtocolLFB. [Yes, these messages > will be part of Events or Config...we need to specify this]=20 > > 6.7 HB remains as is. [Agreed]=20 > > In summary, we have the following operations defined for each > message type ( I broke the table into 3 parts): > [looks good!]=20 > OPERATION APPLICABLE MESSAGE TYPES > > Assoc-Setup Assoc-Setup-Resp Assoc-Teardown Heartb= eat > > no operations > defined > > > Query Query-Resp Config Config-Resp > SET, DEL, UPDATE x x > GET x x > EV_S, EV_U x x > > (for event subscribe/unsubscribe) > > > Packet-Redir > > PAYLOAD x > > > Event-Notif Event-Notif-Resp > EVENT x x > > Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), > we have each time only one operation. Looks a bit redundant. Ideas > ? [These are all very different, lets leave them as is, its not > necessary to have multiple operations in all messages]=20 > > Regards, > -Robert > > > >--=20 > >Robert Haas > >IBM Zurich Research Laboratory > >S=E4umerstrasse 4 > >CH-8803 R=FCschlikon/Switzerland > >phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha= > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------070608010508050101010906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Weiming.
I suggest we make a  new section "FE LFB and FE Protocol LFB" just before Section 5 "Common Header", instead of leaving this to section 3.3.2. This will reflect the importance of those two LFBs in the operation of the protocol.

I'll post my text when ready, please do the same, and we'll merge.

-Robert

Wang,Weiming wrote:
Robert,
 
Don't worry too much about the FE LFB and Protocol LFB, I think it can be fit it well in the sections.
 
Actually I can do something for Protocol LFB and FE LFB if you think possible.
 
Regards,
Weiming
 
----- Original Message -----
Sent: Friday, October 22, 2004 4:35 PM
Subject: Section 6 update

Hi Robert, All

 

Here you go…I have updated sections 6.1, 6.3, 6.6 (remove), 6.7 (same). I have directly used the text that Jamal sent out wherever applicable.

You can update sections 6.2, 6.4, 6.5 -> however, I would check with Weiming first as courtesy since he is working on these sections.

 

BTW, there were lots of things in the todo list I sent out…

 

Header Section - Jamal/Robert/Weiming?

Protocol LFB - Robert/Others?

FE LFB - Robert/Others?

CE LFB - ?

State Machine for Protocol – Ligang (taken)

 

Will you be working on any of these ??

 

Pls do let us know…I will start working on whatever hasn’t been claimed by tomorrow morning my time.

 

Thanks

Hormuzd

 

From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Friday, October 22, 2004 12:39 AM
To: Khosravi, Hormuzd M
Cc: Ligang Dong; hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com; Weiming Wang; forces-protocol@ietf.org
Subject: Re: Applying changes to Section 6 (Protocol Messages)

 

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

Khosravi, Hormuzd M wrote:

Robert,

 

As I said, your note mostly looks...I have put some more comments below...

(It would help a lot if you start defining the FE, Protocol LFBs...)

From: Robert Haas [mailto:rha@zurich.ibm.com]


All: below is a rough list of changes and pending issues regarding section 6. Please review.

 6.1.1 Association: The CE could obtain the HBI with a Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg strcutrue, we have to remove HBI from the Assoc Setup msg.  [Agreed, this would be part of ProtocolLFB even if it is in this message] 

 6.1.2 How has the srcID=0 case been handled in the interop tests ? Is this really feasible ?  [Yes it worked fine during Interop] 

 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into the FEProtocolLFB.  [Agreed it would be in some LFB, but not sure which LFB this would be part of...?] 

 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note that for the sake of symmetry, we should introduce a CEProtocolLFB.  [Sure, why dont you start defining some of these objects...then we can discuss more in detail] 

 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become settable attributes in the FEProtocolLFB.  [Yes, these messages will be part of Events or Config...we need to specify this] 

 6.7 HB remains as is.  [Agreed] 

In summary, we have the following operations defined for each message type ( I broke the table into 3 parts):
 [looks good!] 
OPERATION       APPLICABLE MESSAGE TYPES

                Assoc-Setup  Assoc-Setup-Resp Assoc-Teardown Heartbeat

no operations
defined


                Query  Query-Resp  Config  Config-Resp
SET, DEL, UPDATE                     x          x
GET               x         x
EV_S, EV_U                           x          x

(for event subscribe/unsubscribe)


                Packet-Redir

PAYLOAD            x


                Event-Notif  Event-Notif-Resp
EVENT              x                x

Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we have each time only one operation. Looks a bit redundant. Ideas ?  [These are all very different, lets leave them as is, its not necessary to have multiple operations in all messages] 

Regards,
-Robert



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

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------070608010508050101010906-- --===============1518817690== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1518817690==-- From forces-protocol-bounces@ietf.org Fri Oct 22 06:50:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21455 for ; Fri, 22 Oct 2004 06:50:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKxDD-0003K1-NG for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 07:04:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKx0D-0008Vs-2l; Fri, 22 Oct 2004 06:50:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKwx3-0007WN-UV for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 06:47:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21309 for ; Fri, 22 Oct 2004 06:47:14 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKx9c-0003Gg-Bg for forces-protocol@ietf.org; Fri, 22 Oct 2004 07:00:30 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CKwwc-0003ko-LK for forces-protocol@ietf.org; Fri, 22 Oct 2004 06:46:51 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Fri, 22 Oct 2004 19:05:54 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Fri, 22 Oct 2004 18:42:12 +0800 Message-ID: <102601c4b824$15a75dc0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Robert Haas" References: <468F3FDA28AA87429AD807992E22D07E0257920D@orsmsx408> <0fe601c4b816$d55930c0$845c21d2@Necom.hzic.edu.cn> <4178D3D1.3080608@zurich.ibm.com> Date: Fri, 22 Oct 2004 18:44:19 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Ligang Dong Subject: [Forces-protocol] Re: Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1240322945==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 3.6 (+++) X-Scan-Signature: dc7bd83d90806aed39f33478866e2683 This is a multi-part message in MIME format. --===============1240322945== Content-Type: multipart/alternative; boundary="----=_NextPart_000_1023_01C4B867.23A6E920" This is a multi-part message in MIME format. ------=_NextPart_000_1023_01C4B867.23A6E920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBSb2Jl cnQgSGFhcyANCiAgVG86IFdhbmcsV2VpbWluZyANCiAgQ2M6IEtob3NyYXZpLCBIb3JtdXpkIE0g OyBMaWdhbmcgRG9uZyA7IGhhZGlAem55eC5jb20gOyBhdnJpQHBzZy5jb20gOyByYW0uZ29wYWxA bm9raWEuY29tIDsgZm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0KICBTZW50OiBGcmlkYXksIE9j dG9iZXIgMjIsIDIwMDQgNTozMyBQTQ0KICBTdWJqZWN0OiBSZTogU2VjdGlvbiA2IHVwZGF0ZQ0K DQoNCiAgV2VpbWluZy4NCiAgSSBzdWdnZXN0IHdlIG1ha2UgYSAgbmV3IHNlY3Rpb24gIkZFIExG QiBhbmQgRkUgUHJvdG9jb2wgTEZCIiBqdXN0IGJlZm9yZSBTZWN0aW9uIDUgIkNvbW1vbiBIZWFk ZXIiLCBpbnN0ZWFkIG9mIGxlYXZpbmcgdGhpcyB0byBzZWN0aW9uIDMuMy4yLiANCiAgVGhpcyB3 aWxsIHJlZmxlY3QgdGhlIGltcG9ydGFuY2Ugb2YgdGhvc2UgdHdvIExGQnMgaW4gdGhlIG9wZXJh dGlvbiBvZiB0aGUgcHJvdG9jb2wuDQogIFtXZWltaW5nXUknbSBub3Qgb2JqZWN0aXZlIHRvIHRo aXMsIGp1c3QgYSBsaXR0bGUgd29ycnkgaWYgaXQgbWF5IG1ha2UgdGhlIHdob2VsIHRleHQgY2hh bmdlIHRvbyBtdWNoKHNvbWUgY3Jvc3MgcmVmZXJlbmNlcyBvZiBzZWN0aW9uIG51bWJlcikuIFdo YXQgSSBzZWUgbW9yZSBpcyBpZiB3ZSBuZWVkIHRvIGFkZCBhIHN1YiBzZWN0aW9uIHRvIGRldGFp bGVkbHkgZGVmaW5lIHRoZSBhdHRyaWJ1dGVzIG1lbnRpb25lZC4gVGFsa2luZyBhYm91dCB0aGlz LCBvbmUgdGhpbmcgSSdtIG5vdCB2ZXJ5IHN1cmUgb2YgeW91ciBpZGVhIGlzLCBkbyB5b3UgdGhp bmsgdGhlc2UgYXR0cmlidXRlcyBvZiBMRkJzIChvciBldmVuIHRoZSB3aG9sZSBMRkIgZGVmaW5p dGlvbiApIHNob3VsZCBiZSBkZWZpbmVkIGJ5IG91ciBwcm90b2NvbCBvciBieSBGRSBtb2RlbD8g SSBqdXN0IHNlZSB0aGF0IHRoZXJlIGlzIHNvbWUgbG9naWNhbCBwcm9ibGVtIGlmIGl0IGlzIGRl ZmluZWQgYnkgRkUgbW9kZWwuDQoNCiAgSSdsbCBwb3N0IG15IHRleHQgd2hlbiByZWFkeSwgcGxl YXNlIGRvIHRoZSBzYW1lLCBhbmQgd2UnbGwgbWVyZ2UuDQogIFtXZWltaW5nXUkgdGhpbmsgeW91 ciBjdXJyZW50IHZlcnNpb24gaGFzIGFscmVhZHkgZG9uZSB3ZWxsIGFuZCAgbWFkZSBnb29kIHN1 bW1hcnkgb24gdGhlIGlzc3VlLiBJJ2wgYmUgbW9yZSBpbnRlcmVzdGVkIGluIHRyeWluZyB0byBp bnB1dCBzb21ldGhpbmcgYmFzZWQgb24geW91ciB0ZXh0LiBUbyBqb2luIGluLCBiZWNhdXNlIGFz IHlvdSBrbm93IHRoaXMgcGFydCBpcyBvbmUgb2YgdGhhdCBJJ20gbW9zdCBpbnRlcmVzdGVkIGFu ZCBJIGhvcGUgdG8gaGF2ZSBtb3JlIGV4Y2hhbmdlIHdpdGggeW91IG9uIHRoaXMgbGF0ZXIuICBX ZSd2IGFjdHVhbGx5IGltcGxlbWVudGVkIHN1Y2ggbW9kZWwgaW4gb3VyIHRlc3RiZWQuIA0KICBC ZXN0IHJlZ2FyZHMsDQogIFdlaW1pbmcNCg0KICAtUm9iZXJ0DQoNCiAgV2FuZyxXZWltaW5nIHdy b3RlOg0KDQogICAgUm9iZXJ0LCANCg0KICAgIERvbid0IHdvcnJ5IHRvbyBtdWNoIGFib3V0IHRo ZSBGRSBMRkIgYW5kIFByb3RvY29sIExGQiwgSSB0aGluayBpdCBjYW4gYmUgZml0IGl0IHdlbGwg aW4gdGhlIHNlY3Rpb25zLg0KDQogICAgQWN0dWFsbHkgSSBjYW4gZG8gc29tZXRoaW5nIGZvciBQ cm90b2NvbCBMRkIgYW5kIEZFIExGQiBpZiB5b3UgdGhpbmsgcG9zc2libGUuDQoNCiAgICBSZWdh cmRzLA0KICAgIFdlaW1pbmcNCg0KICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQog ICAgICBGcm9tOiBLaG9zcmF2aSwgSG9ybXV6ZCBNIA0KICAgICAgVG86IFJvYmVydCBIYWFzIA0K ICAgICAgQ2M6IExpZ2FuZyBEb25nIDsgaGFkaUB6bnl4LmNvbSA7IGF2cmlAcHNnLmNvbSA7IHJh bS5nb3BhbEBub2tpYS5jb20gOyBXZWltaW5nIFdhbmcgOyBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5v cmcgDQogICAgICBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMDQgNDozNSBQTQ0KICAgICAg U3ViamVjdDogU2VjdGlvbiA2IHVwZGF0ZQ0KDQoNCiAgICAgIEhpIFJvYmVydCwgQWxsDQoNCg0K DQogICAgICBIZXJlIHlvdSBnby5JIGhhdmUgdXBkYXRlZCBzZWN0aW9ucyA2LjEsIDYuMywgNi42 IChyZW1vdmUpLCA2LjcgKHNhbWUpLiBJIGhhdmUgZGlyZWN0bHkgdXNlZCB0aGUgdGV4dCB0aGF0 IEphbWFsIHNlbnQgb3V0IHdoZXJldmVyIGFwcGxpY2FibGUuDQoNCiAgICAgIFlvdSBjYW4gdXBk YXRlIHNlY3Rpb25zIDYuMiwgNi40LCA2LjUgLT4gaG93ZXZlciwgSSB3b3VsZCBjaGVjayB3aXRo IFdlaW1pbmcgZmlyc3QgYXMgY291cnRlc3kgc2luY2UgaGUgaXMgd29ya2luZyBvbiB0aGVzZSBz ZWN0aW9ucy4NCg0KDQoNCiAgICAgIEJUVywgdGhlcmUgd2VyZSBsb3RzIG9mIHRoaW5ncyBpbiB0 aGUgdG9kbyBsaXN0IEkgc2VudCBvdXQuDQoNCg0KDQogICAgICBIZWFkZXIgU2VjdGlvbiAtIEph bWFsL1JvYmVydC9XZWltaW5nPw0KDQogICAgICBQcm90b2NvbCBMRkIgLSBSb2JlcnQvT3RoZXJz Pw0KDQogICAgICBGRSBMRkIgLSBSb2JlcnQvT3RoZXJzPw0KDQogICAgICBDRSBMRkIgLSA/DQoN CiAgICAgIFN0YXRlIE1hY2hpbmUgZm9yIFByb3RvY29sIC0gTGlnYW5nICh0YWtlbikNCg0KDQoN CiAgICAgIFdpbGwgeW91IGJlIHdvcmtpbmcgb24gYW55IG9mIHRoZXNlID8/DQoNCg0KDQogICAg ICBQbHMgZG8gbGV0IHVzIGtub3cuSSB3aWxsIHN0YXJ0IHdvcmtpbmcgb24gd2hhdGV2ZXIgaGFz bid0IGJlZW4gY2xhaW1lZCBieSB0b21vcnJvdyBtb3JuaW5nIG15IHRpbWUuDQoNCg0KDQogICAg ICBUaGFua3MNCg0KICAgICAgSG9ybXV6ZA0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQog ICAgICBGcm9tOiBSb2JlcnQgSGFhcyBbbWFpbHRvOnJoYUB6dXJpY2guaWJtLmNvbV0gDQogICAg ICBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMDQgMTI6MzkgQU0NCiAgICAgIFRvOiBLaG9z cmF2aSwgSG9ybXV6ZCBNDQogICAgICBDYzogTGlnYW5nIERvbmc7IGhhZGlAem55eC5jb207IGF2 cmlAcHNnLmNvbTsgcmFtLmdvcGFsQG5va2lhLmNvbTsgV2VpbWluZyBXYW5nOyBmb3JjZXMtcHJv dG9jb2xAaWV0Zi5vcmcNCiAgICAgIFN1YmplY3Q6IFJlOiBBcHBseWluZyBjaGFuZ2VzIHRvIFNl Y3Rpb24gNiAoUHJvdG9jb2wgTWVzc2FnZXMpDQoNCg0KDQogICAgICBIb3JtdXpkLA0KICAgICAg Q291bGQgeW91IHBsZWFzZSBwYXNzIHRoZSB0b2tlbiBvbiBzZWN0aW9uIDYgdG9nZXRoZXIgd2l0 aCB5b3VyIGxhdGVzdCB2ZXJzaW9uIHNvIEkgY2FuIHN0YXJ0IGVkaXRpbmcgaXQgPw0KICAgICAg VGhhbmtzLA0KICAgICAgLVJvYmVydA0KDQogICAgICBLaG9zcmF2aSwgSG9ybXV6ZCBNIHdyb3Rl Og0KDQoNCg0KICAgICAgUm9iZXJ0LA0KDQoNCg0KICAgICAgQXMgSSBzYWlkLCB5b3VyIG5vdGUg bW9zdGx5IGxvb2tzLi4uSSBoYXZlIHB1dCBzb21lIG1vcmUgY29tbWVudHMgYmVsb3cuLi4NCg0K ICAgICAgKEl0IHdvdWxkIGhlbHAgYSBsb3QgaWYgeW91IHN0YXJ0IGRlZmluaW5nIHRoZSBGRSwg UHJvdG9jb2wgTEZCcy4uLikNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICAgICBGcm9tOiBS b2JlcnQgSGFhcyBbbWFpbHRvOnJoYUB6dXJpY2guaWJtLmNvbV0gDQoNCg0KICAgICAgQWxsOiBi ZWxvdyBpcyBhIHJvdWdoIGxpc3Qgb2YgY2hhbmdlcyBhbmQgcGVuZGluZyBpc3N1ZXMgcmVnYXJk aW5nIHNlY3Rpb24gNi4gUGxlYXNlIHJldmlldy4NCg0KICAgICAgIDYuMS4xIEFzc29jaWF0aW9u OiBUaGUgQ0UgY291bGQgb2J0YWluIHRoZSBIQkkgd2l0aCBhIFF1ZXJ5LVNHVC1GRVByb3RvY29s TEZQLUhlYXJ0YmVhdEludGVydmFsLiBHaXZlbiB0aGUgbmV3IEFzc29jIG1zZyBzdHJjdXRydWUs IHdlIGhhdmUgdG8gcmVtb3ZlIEhCSSBmcm9tIHRoZSBBc3NvYyBTZXR1cCBtc2cuICBbQWdyZWVk LCB0aGlzIHdvdWxkIGJlIHBhcnQgb2YgUHJvdG9jb2xMRkIgZXZlbiBpZiBpdCBpcyBpbiB0aGlz IG1lc3NhZ2VdIA0KDQogICAgICAgNi4xLjIgSG93IGhhcyB0aGUgc3JjSUQ9MCBjYXNlIGJlZW4g aGFuZGxlZCBpbiB0aGUgaW50ZXJvcCB0ZXN0cyA/IElzIHRoaXMgcmVhbGx5IGZlYXNpYmxlID8g IFtZZXMgaXQgd29ya2VkIGZpbmUgZHVyaW5nIEludGVyb3BdIA0KDQogICAgICAgNi4yIFF1ZXJ5 OiBjb2Fyc2UgRkUgaW5mbyAoaW50ZXIvaW50cmEtRkUgdG9wb2xvZ3ksIGV0YykgZ29lcyBpbnRv IHRoZSBGRVByb3RvY29sTEZCLiAgW0FncmVlZCBpdCB3b3VsZCBiZSBpbiBzb21lIExGQiwgYnV0 IG5vdCBzdXJlIHdoaWNoIExGQiB0aGlzIHdvdWxkIGJlIHBhcnQgb2YuLi4/XSANCg0KICAgICAg IDYuNDogRXZlbnRzOiBjb2Fyc2UgQ0UgYW5kIEZFIGV2ZW50cyBnbyBpbnRvIENFL0ZFUHJvdG9j b2xMRkIuIE5vdGUgdGhhdCBmb3IgdGhlIHNha2Ugb2Ygc3ltbWV0cnksIHdlIHNob3VsZCBpbnRy b2R1Y2UgYSBDRVByb3RvY29sTEZCLiAgW1N1cmUsIHdoeSBkb250IHlvdSBzdGFydCBkZWZpbmlu ZyBzb21lIG9mIHRoZXNlIG9iamVjdHMuLi50aGVuIHdlIGNhbiBkaXNjdXNzIG1vcmUgaW4gZGV0 YWlsXSANCg0KICAgICAgIDYuNiBTdGF0ZSBNYWludGVuYW5jZTogRkUgQWN0aXZhdGUvRGVhY3Rp dmF0ZS9TaHV0ZG93biBiZWNvbWUgc2V0dGFibGUgYXR0cmlidXRlcyBpbiB0aGUgRkVQcm90b2Nv bExGQi4gIFtZZXMsIHRoZXNlIG1lc3NhZ2VzIHdpbGwgYmUgcGFydCBvZiBFdmVudHMgb3IgQ29u ZmlnLi4ud2UgbmVlZCB0byBzcGVjaWZ5IHRoaXNdIA0KDQogICAgICAgNi43IEhCIHJlbWFpbnMg YXMgaXMuICBbQWdyZWVkXSANCg0KICAgICAgSW4gc3VtbWFyeSwgd2UgaGF2ZSB0aGUgZm9sbG93 aW5nIG9wZXJhdGlvbnMgZGVmaW5lZCBmb3IgZWFjaCBtZXNzYWdlIHR5cGUgKCBJIGJyb2tlIHRo ZSB0YWJsZSBpbnRvIDMgcGFydHMpOg0KICAgICAgIFtsb29rcyBnb29kIV0gDQogICAgICBPUEVS QVRJT04gICAgICAgQVBQTElDQUJMRSBNRVNTQUdFIFRZUEVTDQoNCiAgICAgICAgICAgICAgICAg ICAgICBBc3NvYy1TZXR1cCAgQXNzb2MtU2V0dXAtUmVzcCBBc3NvYy1UZWFyZG93biBIZWFydGJl YXQNCg0KICAgICAgbm8gb3BlcmF0aW9ucw0KICAgICAgZGVmaW5lZA0KDQoNCiAgICAgICAgICAg ICAgICAgICAgICBRdWVyeSAgUXVlcnktUmVzcCAgQ29uZmlnICBDb25maWctUmVzcA0KICAgICAg U0VULCBERUwsIFVQREFURSAgICAgICAgICAgICAgICAgICAgIHggICAgICAgICAgeA0KICAgICAg R0VUICAgICAgICAgICAgICAgeCAgICAgICAgIHgNCiAgICAgIEVWX1MsIEVWX1UgICAgICAgICAg ICAgICAgICAgICAgICAgICB4ICAgICAgICAgIHgNCg0KICAgICAgKGZvciBldmVudCBzdWJzY3Jp YmUvdW5zdWJzY3JpYmUpDQoNCg0KICAgICAgICAgICAgICAgICAgICAgIFBhY2tldC1SZWRpcg0K DQogICAgICBQQVlMT0FEICAgICAgICAgICAgeA0KDQoNCiAgICAgICAgICAgICAgICAgICAgICBF dmVudC1Ob3RpZiAgRXZlbnQtTm90aWYtUmVzcA0KICAgICAgRVZFTlQgICAgICAgICAgICAgIHgg ICAgICAgICAgICAgICAgeA0KDQogICAgICBOb3RlIHRoYXQgZm9yIFF1ZXJ5KC1SZXNwKSwgUGFj a2V0LVJlZGlyLCBhbmQgRXZlbnQtTm90aWYoLVJlc3ApLCB3ZSBoYXZlIGVhY2ggdGltZSBvbmx5 IG9uZSBvcGVyYXRpb24uIExvb2tzIGEgYml0IHJlZHVuZGFudC4gSWRlYXMgPyAgW1RoZXNlIGFy ZSBhbGwgdmVyeSBkaWZmZXJlbnQsIGxldHMgbGVhdmUgdGhlbSBhcyBpcywgaXRzIG5vdCBuZWNl c3NhcnkgdG8gaGF2ZSBtdWx0aXBsZSBvcGVyYXRpb25zIGluIGFsbCBtZXNzYWdlc10gDQoNCiAg ICAgIFJlZ2FyZHMsDQogICAgICAtUm9iZXJ0DQoNCg0KDQoNCg0KLS0gDQpSb2JlcnQgSGFhcw0K SUJNIFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5DQpT5HVtZXJzdHJhc3NlIDQNCkNILTg4MDMg UvxzY2hsaWtvbi9Td2l0emVybGFuZA0KcGhvbmUgKzQxLTEtNzI0LTg2OTggIGZheCArNDEtMS03 MjQtODU3OCAgaHR0cDovL3d3dy56dXJpY2guaWJtLmNvbS9+cmhhDQoNCg0KLS0gDQpSb2JlcnQg SGFhcw0KSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5DQpT5HVtZXJzdHJhc3NlIDQNCkNI LTg4MDMgUvxzY2hsaWtvbi9Td2l0emVybGFuZA0KcGhvbmUgKzQxLTEtNzI0LTg2OTggIGZheCAr NDEtMS03MjQtODU3OCAgaHR0cDovL3d3dy56dXJpY2guaWJtLmNvbS9+cmhhDQoNCg== ------=_NextPart_000_1023_01C4B867.23A6E920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD10ZXh0L2h0bWw7Y2hhcnNldD1JU08tODg1OS0xPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjYwMC4wIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSB0 ZXh0PSMwMDAwMDAgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj5IaSBSb2JlcnQsPC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQ QURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBC T1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJ ViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8 L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDEwcHQg YXJpYWw7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPXJoYUB6 dXJpY2guaWJtLmNvbSBocmVmPSJtYWlsdG86cmhhQHp1cmljaC5pYm0uY29tIj5Sb2JlcnQgSGFh czwvQT4gDQogIDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0IGFyaWFsIj48Qj5Ubzo8 L0I+IDxBIHRpdGxlPXdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuIA0KICBocmVmPSJtYWlsdG86d213 YW5nQG1haWwuaHppYy5lZHUuY24iPldhbmcsV2VpbWluZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPkNjOjwvQj4gPEEgdGl0bGU9aG9ybXV6ZC5tLmtob3Ny YXZpQGludGVsLmNvbSANCiAgaHJlZj0ibWFpbHRvOmhvcm11emQubS5raG9zcmF2aUBpbnRlbC5j b20iPktob3NyYXZpLCBIb3JtdXpkIE08L0E+IDsgPEEgDQogIHRpdGxlPWRvbmdsZ0BtYWlsLmh6 aWMuZWR1LmNuIGhyZWY9Im1haWx0bzpkb25nbGdAbWFpbC5oemljLmVkdS5jbiI+TGlnYW5nIA0K ICBEb25nPC9BPiA7IDxBIHRpdGxlPWhhZGlAem55eC5jb20gDQogIGhyZWY9Im1haWx0bzpoYWRp QHpueXguY29tIj5oYWRpQHpueXguY29tPC9BPiA7IDxBIHRpdGxlPWF2cmlAcHNnLmNvbSANCiAg aHJlZj0ibWFpbHRvOmF2cmlAcHNnLmNvbSI+YXZyaUBwc2cuY29tPC9BPiA7IDxBIHRpdGxlPXJh bS5nb3BhbEBub2tpYS5jb20gDQogIGhyZWY9Im1haWx0bzpyYW0uZ29wYWxAbm9raWEuY29tIj5y YW0uZ29wYWxAbm9raWEuY29tPC9BPiA7IDxBIA0KICB0aXRsZT1mb3JjZXMtcHJvdG9jb2xAaWV0 Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmciPmZvcmNlcy1w cm90b2NvbEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJp YWwiPjxCPlNlbnQ6PC9CPiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMDQgNTozMyANCiAgUE08L0RJ Vj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+U3ViamVjdDo8L0I+IFJlOiBT ZWN0aW9uIDYgdXBkYXRlPC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9G T05UPjxCUj48L0RJVj4NCiAgPERJVj5XZWltaW5nLjxCUj5JIHN1Z2dlc3Qgd2UgbWFrZSBhJm5i c3A7IG5ldyBzZWN0aW9uICJGRSBMRkIgYW5kIEZFIFByb3RvY29sIA0KICBMRkIiIGp1c3QgYmVm b3JlIFNlY3Rpb24gNSAiQ29tbW9uIEhlYWRlciIsIGluc3RlYWQgb2YgbGVhdmluZyB0aGlzIHRv IHNlY3Rpb24gDQogIDMuMy4yLiA8L0RJVj4NCiAgPERJVj5UaGlzIHdpbGwgcmVmbGVjdCB0aGUg aW1wb3J0YW5jZSBvZiB0aG9zZSB0d28gTEZCcyBpbiB0aGUgb3BlcmF0aW9uIG9mIA0KICB0aGUg cHJvdG9jb2wuPC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+W1dlaW1pbmdd SSdtIG5vdCBvYmplY3RpdmUgdG8gdGhpcywganVzdCBhIGxpdHRsZSANCiAgd29ycnkgaWYgaXQg bWF5IG1ha2UgdGhlIHdob2VsIHRleHQgY2hhbmdlJm5ic3A7dG9vIG11Y2goc29tZSBjcm9zcyBy ZWZlcmVuY2VzIA0KICBvZiBzZWN0aW9uIG51bWJlcikuIFdoYXQgSSBzZWUgbW9yZSBpcyBpZiB3 ZSBuZWVkIHRvIGFkZCBhIHN1YiBzZWN0aW9uIHRvIA0KICBkZXRhaWxlZGx5IGRlZmluZSB0aGUg YXR0cmlidXRlcyBtZW50aW9uZWQuIFRhbGtpbmcgYWJvdXQgdGhpcywgb25lIHRoaW5nIEknbSAN CiAgbm90IHZlcnkgc3VyZSBvZiB5b3VyIGlkZWEgaXMsIGRvIHlvdSB0aGluayB0aGVzZSBhdHRy aWJ1dGVzIG9mIExGQnMgKG9yIGV2ZW4gDQogIHRoZSB3aG9sZSBMRkIgZGVmaW5pdGlvbiApIHNo b3VsZCBiZSBkZWZpbmVkIGJ5IG91ciBwcm90b2NvbCBvciBieSBGRSBtb2RlbD8gSSANCiAganVz dCBzZWUgdGhhdCB0aGVyZSBpcyBzb21lIGxvZ2ljYWwgcHJvYmxlbSBpZiBpdCBpcyBkZWZpbmVk IGJ5IEZFIA0KICBtb2RlbC48L0ZPTlQ+PEJSPjxCUj5JJ2xsIHBvc3QgbXkgdGV4dCB3aGVuIHJl YWR5LCBwbGVhc2UgZG8gdGhlIHNhbWUsIGFuZCANCiAgd2UnbGwgbWVyZ2UuPC9ESVY+DQogIDxE SVY+W1dlaW1pbmddSSB0aGluayB5b3VyIGN1cnJlbnQgdmVyc2lvbiBoYXMgYWxyZWFkeSBkb25l IHdlbGwgYW5kIA0KICAmbmJzcDttYWRlIGdvb2Qgc3VtbWFyeSBvbiB0aGUgaXNzdWUuIEknbCBi ZSBtb3JlIGludGVyZXN0ZWQgaW4gdHJ5aW5nIHRvIA0KICBpbnB1dCBzb21ldGhpbmcgYmFzZWQg b24geW91ciB0ZXh0LiBUbyZuYnNwO2pvaW4gaW4sJm5ic3A7YmVjYXVzZSBhcyB5b3Uga25vdyAN CiAgdGhpcyBwYXJ0IGlzIG9uZSBvZiB0aGF0IEknbSBtb3N0IGludGVyZXN0ZWQgYW5kIEkgaG9w ZSB0byBoYXZlIG1vcmUgZXhjaGFuZ2UgDQogIHdpdGggeW91IG9uIHRoaXMgbGF0ZXIuJm5ic3A7 IFdlJ3YgYWN0dWFsbHkgaW1wbGVtZW50ZWQgc3VjaCBtb2RlbCBpbiBvdXIgDQogIHRlc3RiZWQu Jm5ic3A7PC9ESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPjwvQkxPQ0tRVU9URT4N CjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1SSUdIVDogMHB4OyBQQURESU5H LUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNv bGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+ QmVzdCByZWdhcmRzLDwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj5XZWltaW5nPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwv Rk9OVD48QlI+LVJvYmVydDxCUj48QlI+V2FuZyxXZWltaW5nIA0KICB3cm90ZTo8QlI+PC9ESVY+ DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkMGZlNjAxYzRiODE2JGQ1NTkzMGMwJDg0NWMyMWQyQE5l Y29tLmh6aWMuZWR1LmNuIA0KICB0eXBlPSJjaXRlIj4NCiAgICA8TUVUQSBjb250ZW50PSJNU0hU TUwgNi4wMC4yNjAwLjAiIG5hbWU9R0VORVJBVE9SPg0KICAgIDxTVFlMRT5AZm9udC1mYWNlIHsN Cglmb250LWZhbWlseTogVGFob21hOw0KfQ0KQHBhZ2UgU2VjdGlvbjEge3NpemU6IDguNWluIDEx LjBpbjsgbWFyZ2luOiAxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluOyB9DQpQLk1zb05vcm1hbCB7 DQoJRk9OVC1TSVpFOiAxMnB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBDT0xPUjogYmxhY2s7IEZP TlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIg0KfQ0KTEkuTXNvTm9ybWFsIHsNCglGT05ULVNJ WkU6IDEycHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6 ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpESVYuTXNvTm9ybWFsIHsNCglGT05ULVNJWkU6IDEycHQ7 IE1BUkdJTjogMGluIDBpbiAwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICJUaW1lcyBO ZXcgUm9tYW4iDQp9DQpBOmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09SQVRJT046IHVu ZGVybGluZQ0KfQ0KU1BBTi5Nc29IeXBlcmxpbmsgew0KCUNPTE9SOiBibHVlOyBURVhULURFQ09S QVRJT046IHVuZGVybGluZQ0KfQ0KQTp2aXNpdGVkIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNP UkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0KCUNPTE9S OiBibHVlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KUFJFIHsNCglGT05ULVNJWkU6 IDEwcHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6ICJD b3VyaWVyIE5ldyINCn0NClRUIHsNCglGT05ULUZBTUlMWTogIkNvdXJpZXIgTmV3Ig0KfQ0KU1BB Ti5FbWFpbFN0eWxlMTkgew0KCUNPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwNCn0NCkRJ Vi5TZWN0aW9uMSB7DQoJcGFnZTogU2VjdGlvbjENCn0NCjwvU1RZTEU+DQoNCiAgICA8RElWPjxG T05UIGZhY2U9QXJpYWwgc2l6ZT0yPlJvYmVydCwgPC9GT05UPjwvRElWPg0KICAgIDxESVY+Jm5i c3A7PC9ESVY+DQogICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Eb24ndCB3b3JyeSB0 b28gbXVjaCBhYm91dCB0aGUgRkUgTEZCIGFuZCANCiAgICBQcm90b2NvbCBMRkIsIEkgdGhpbmsg aXQgY2FuIGJlIGZpdCBpdCB3ZWxsIGluIHRoZSBzZWN0aW9ucy48L0ZPTlQ+PC9ESVY+DQogICAg PERJVj4mbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkFjdHVh bGx5IEkgY2FuIGRvIHNvbWV0aGluZyBmb3IgUHJvdG9jb2wgTEZCIA0KICAgIGFuZCBGRSBMRkIg aWYgeW91IHRoaW5rIHBvc3NpYmxlLjwvRk9OVD48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElW Pg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+UmVnYXJkcyw8L0ZPTlQ+PC9ESVY+ DQogICAgPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5XZWltaW5nPC9GT05UPjwvRElWPg0K ICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tIDwvRElWPg0KICAgIDxCTE9DS1FVT1RFIGRpcj1sdHIgDQogICAgc3R5bGU9IlBBRERJTkct UklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1M RUZUOiByZ2IoMCwwLDApIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgICAgPERJ ViANCiAgICAgIHN0eWxlPSJCQUNLR1JPVU5EOiByZ2IoMjI4LDIyOCwyMjgpIDAlIDUwJTsgRk9O VDogMTBwdCBhcmlhbDsgbW96LWJhY2tncm91bmQtY2xpcDogaW5pdGlhbDsgbW96LWJhY2tncm91 bmQtb3JpZ2luOiBpbml0aWFsOyBtb3otYmFja2dyb3VuZC1pbmxpbmUtcG9saWN5OiBpbml0aWFs OyBmb250LXNpemUtYWRqdXN0OiBub25lOyBmb250LXN0cmV0Y2g6IG5vcm1hbCI+PEI+RnJvbTo8 L0I+IA0KICAgICAgPEEgdGl0bGU9aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbSANCiAgICAg IGhyZWY9Im1haWx0bzpob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tIj5LaG9zcmF2aSwgSG9y bXV6ZCBNPC9BPiA8L0RJVj4NCiAgICAgIDxESVYgDQogICAgICBzdHlsZT0iRk9OVDogMTBwdCBh cmlhbDsgZm9udC1zaXplLWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNoOiBub3JtYWwiPjxCPlRv OjwvQj4gDQogICAgICA8QSB0aXRsZT1yaGFAenVyaWNoLmlibS5jb20gaHJlZj0ibWFpbHRvOnJo YUB6dXJpY2guaWJtLmNvbSI+Um9iZXJ0IA0KICAgICAgSGFhczwvQT4gPC9ESVY+DQogICAgICA8 RElWIA0KICAgICAgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWw7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5v bmU7IGZvbnQtc3RyZXRjaDogbm9ybWFsIj48Qj5DYzo8L0I+IA0KICAgICAgPEEgdGl0bGU9ZG9u Z2xnQG1haWwuaHppYy5lZHUuY24gDQogICAgICBocmVmPSJtYWlsdG86ZG9uZ2xnQG1haWwuaHpp Yy5lZHUuY24iPkxpZ2FuZyBEb25nPC9BPiA7IDxBIA0KICAgICAgdGl0bGU9aGFkaUB6bnl4LmNv bSBocmVmPSJtYWlsdG86aGFkaUB6bnl4LmNvbSI+aGFkaUB6bnl4LmNvbTwvQT4gOyA8QSANCiAg ICAgIHRpdGxlPWF2cmlAcHNnLmNvbSBocmVmPSJtYWlsdG86YXZyaUBwc2cuY29tIj5hdnJpQHBz Zy5jb208L0E+IDsgPEEgDQogICAgICB0aXRsZT1yYW0uZ29wYWxAbm9raWEuY29tIA0KICAgICAg aHJlZj0ibWFpbHRvOnJhbS5nb3BhbEBub2tpYS5jb20iPnJhbS5nb3BhbEBub2tpYS5jb208L0E+ IDsgPEEgDQogICAgICB0aXRsZT13bXdhbmdAbWFpbC5oemljLmVkdS5jbiANCiAgICAgIGhyZWY9 Im1haWx0bzp3bXdhbmdAbWFpbC5oemljLmVkdS5jbiI+V2VpbWluZyBXYW5nPC9BPiA7IDxBIA0K ICAgICAgdGl0bGU9Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0KICAgICAgaHJlZj0ibWFpbHRv OmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyI+Zm9yY2VzLXByb3RvY29sQGlldGYub3JnPC9BPiA8 L0RJVj4NCiAgICAgIDxESVYgDQogICAgICBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbDsgZm9udC1z aXplLWFkanVzdDogbm9uZTsgZm9udC1zdHJldGNoOiBub3JtYWwiPjxCPlNlbnQ6PC9CPiANCiAg ICAgIEZyaWRheSwgT2N0b2JlciAyMiwgMjAwNCA0OjM1IFBNPC9ESVY+DQogICAgICA8RElWIA0K ICAgICAgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWw7IGZvbnQtc2l6ZS1hZGp1c3Q6IG5vbmU7IGZv bnQtc3RyZXRjaDogbm9ybWFsIj48Qj5TdWJqZWN0OjwvQj4gDQogICAgICBTZWN0aW9uIDYgdXBk YXRlPC9ESVY+DQogICAgICA8RElWPjxCUj48L0RJVj4NCiAgICAgIDxESVYgY2xhc3M9U2VjdGlv bjE+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5 IHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5 OyBGT05ULUZBTUlMWTogQXJpYWwiPkhpIFJvYmVydCwgDQogICAgICBBbGw8L1NQQU4+PC9GT05U PjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5h dnkgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5h dnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogICAgICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BB TiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlM WTogQXJpYWwiPkhlcmUgeW91IGdvhUkgDQogICAgICBoYXZlIHVwZGF0ZWQgc2VjdGlvbnMgNi4x LCA2LjMsIDYuNiAocmVtb3ZlKSwgNi43IChzYW1lKS4gSSBoYXZlIGRpcmVjdGx5IA0KICAgICAg dXNlZCB0aGUgdGV4dCB0aGF0IEphbWFsIHNlbnQgb3V0IHdoZXJldmVyIGFwcGxpY2FibGUuPC9T UEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPllvdSBjYW4gdXBkYXRlIA0KICAgICAg c2VjdGlvbnMgNi4yLCA2LjQsIDYuNSAtJmd0OyBob3dldmVyLCBJIHdvdWxkIGNoZWNrIHdpdGgg V2VpbWluZyBmaXJzdCBhcyANCiAgICAgIGNvdXJ0ZXN5IHNpbmNlIGhlIGlzIHdvcmtpbmcgb24g dGhlc2Ugc2VjdGlvbnMuPC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjwvU1BB Tj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5CVFcsIHRoZXJlIHdlcmUgDQog ICAgICBsb3RzIG9mIHRoaW5ncyBpbiB0aGUgdG9kbyBsaXN0IEkgc2VudCBvdXSFPC9TUEFOPjwv Rk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICAg ICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+ PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1G QU1JTFk6IEFyaWFsIj5IZWFkZXIgU2VjdGlvbiAtIA0KICAgICAgSmFtYWwvUm9iZXJ0L1dlaW1p bmc/PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPlByb3RvY29sIExGQiAtIA0K ICAgICAgUm9iZXJ0L090aGVycz88L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgICAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+ RkUgTEZCIC0gDQogICAgICBSb2JlcnQvT3RoZXJzPzwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAg PFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQ QU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1J TFk6IEFyaWFsIj5DRSBMRkIgLSANCiAgICAgID88L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQ IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFO IA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+U3RhdGUmbmJzcDtNYWNoaW5lJm5ic3A7Zm9yJm5ic3A7UHJvdG9jb2wmbmJzcDuW Jm5ic3A7TGlnYW5nIA0KICAgICAgKHRha2VuKTwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4g DQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6 IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+V2lsbCB5 b3UgYmUgDQogICAgICB3b3JraW5nIG9uIGFueSBvZiB0aGVzZSA/PzwvU1BBTj48L0ZPTlQ+PC9Q Pg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBz aXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsg Rk9OVC1GQU1JTFk6IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgICAgIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0K ICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBB cmlhbCI+UGxzIGRvIGxldCB1cyANCiAgICAgIGtub3eFSSB3aWxsIHN0YXJ0IHdvcmtpbmcgb24g d2hhdGV2ZXIgaGFzbpJ0IGJlZW4gY2xhaW1lZCBieSB0b21vcnJvdyANCiAgICAgIG1vcm5pbmcg bXkgdGltZS48L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PC9TUEFOPjwvRk9O VD4mbmJzcDs8L1A+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPlRoYW5rczwvU1BBTj48L0ZPTlQ+PC9QPg0K ICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXpl PTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9O VC1GQU1JTFk6IEFyaWFsIj5Ib3JtdXpkPC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAg ICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJp YWwiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICAgICAgPERJVj4NCiAgICAgIDxESVYgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUFMSUdOOiBjZW50ZXIiIGFsaWduPWNlbnRlcj48Rk9O VCANCiAgICAgIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFO IA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgQ09MT1I6IHdpbmRvd3RleHQiPg0KICAg ICAgPEhSIHRhYkluZGV4PS0xIGFsaWduPWNlbnRlciB3aWR0aD0iMTAwJSIgU0laRT0yPg0KICAg ICAgPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Qj48Rk9O VCBmYWNlPVRhaG9tYSBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9O VC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQt RkFNSUxZOiBUYWhvbWEiPkZyb206PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogICAgICBmYWNl PVRhaG9tYSBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogd2luZG93dGV4dDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+IFJvYmVydCAN CiAgICAgIEhhYXMgWzxBIGNsYXNzPW1vei10eHQtbGluay1mcmVldGV4dCANCiAgICAgIGhyZWY9 Im1haWx0bzpyaGFAenVyaWNoLmlibS5jb20iPm1haWx0bzpyaGFAenVyaWNoLmlibS5jb208L0E+ XSANCiAgICAgIDxCUj48Qj48U1BBTiBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlNlbnQ6PC9T UEFOPjwvQj4gRnJpZGF5LCBPY3RvYmVyIA0KICAgICAgMjIsIDIwMDQgMTI6MzkgQU08QlI+PEI+ PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5Ubzo8L1NQQU4+PC9CPiANCiAgICAgIEto b3NyYXZpLCBIb3JtdXpkIE08QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5D Yzo8L1NQQU4+PC9CPiANCiAgICAgIExpZ2FuZyBEb25nOyA8QSBjbGFzcz1tb3otdHh0LWxpbmst YWJicmV2aWF0ZWQgDQogICAgICBocmVmPSJtYWlsdG86aGFkaUB6bnl4LmNvbSI+aGFkaUB6bnl4 LmNvbTwvQT47IDxBIA0KICAgICAgY2xhc3M9bW96LXR4dC1saW5rLWFiYnJldmlhdGVkIA0KICAg ICAgaHJlZj0ibWFpbHRvOmF2cmlAcHNnLmNvbSI+YXZyaUBwc2cuY29tPC9BPjsgPEEgDQogICAg ICBjbGFzcz1tb3otdHh0LWxpbmstYWJicmV2aWF0ZWQgDQogICAgICBocmVmPSJtYWlsdG86cmFt LmdvcGFsQG5va2lhLmNvbSI+cmFtLmdvcGFsQG5va2lhLmNvbTwvQT47IFdlaW1pbmcgV2FuZzsg DQogICAgICA8QSBjbGFzcz1tb3otdHh0LWxpbmstYWJicmV2aWF0ZWQgDQogICAgICBocmVmPSJt YWlsdG86Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIj5mb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc8 L0E+PEJSPjxCPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TdWJqZWN0 OjwvU1BBTj48L0I+IFJlOiBBcHBseWluZyBjaGFuZ2VzIHRvIA0KICAgICAgU2VjdGlvbiA2IChQ cm90b2NvbCBNZXNzYWdlcyk8L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICAgIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPWJsYWNrIHNpemU9 Mz48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjwvU1BBTj48L0ZPTlQ+Jm5i c3A7PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgY29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTog MTJwdCI+SG9ybXV6ZCw8QlI+Q291bGQgeW91IHBsZWFzZSBwYXNzIHRoZSB0b2tlbiBvbiANCiAg ICAgIHNlY3Rpb24gNiB0b2dldGhlciB3aXRoIHlvdXIgbGF0ZXN0IHZlcnNpb24gc28gSSBjYW4g c3RhcnQgZWRpdGluZyBpdCANCiAgICAgID88QlI+VGhhbmtzLDxCUj4tUm9iZXJ0PEJSPjxCUj5L aG9zcmF2aSwgSG9ybXV6ZCBNIA0KICAgICAgd3JvdGU6PEJSPjxCUj48L1NQQU4+PC9GT05UPjwv UD4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUg c2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7 IEZPTlQtRkFNSUxZOiBBcmlhbCI+Um9iZXJ0LDwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9YmxhY2sg c2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PC9TUEFOPjwvRk9O VD4mbmJzcDs8L1A+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENP TE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPkFzIEkgc2FpZCwgeW91ciANCiAgICAgIG5v dGUgbW9zdGx5IGxvb2tzLi4uSSBoYXZlIHB1dCBzb21lIG1vcmUgY29tbWVudHMgDQogICAgICBi ZWxvdy4uLjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4oSXQmbmJzcDt3b3Vs ZCZuYnNwO2hlbHAmbmJzcDthJm5ic3A7bG90Jm5ic3A7aWYmbmJzcDt5b3UmbmJzcDtzdGFydCZu YnNwO2RlZmluaW5nJm5ic3A7dGhlJm5ic3A7RkUsJm5ic3A7UHJvdG9jb2wmbmJzcDtMRkJzLi4u KTwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPERJViBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRF WFQtQUxJR046IGNlbnRlciIgYWxpZ249Y2VudGVyPjxGT05UIA0KICAgICAgZmFjZT0iVGltZXMg TmV3IFJvbWFuIiBjb2xvcj1ibGFjayBzaXplPTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJw dCI+DQogICAgICA8SFIgdGFiSW5kZXg9LTEgYWxpZ249Y2VudGVyIHdpZHRoPSIxMDAlIiBTSVpF PTI+DQogICAgICA8L1NQQU4+PC9GT05UPjwvRElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFs PjxCPjxGT05UIGZhY2U9VGFob21hIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiANCiAgICAgIHN0 eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogVGFo b21hIj5Gcm9tOjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICAgICAgZmFjZT1UYWhvbWEgc2l6 ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiPiAN CiAgICAgIFJvYmVydCBIYWFzIFs8QSANCiAgICAgIGhyZWY9Im1haWx0bzpyaGFAenVyaWNoLmli bS5jb20iPm1haWx0bzpyaGFAenVyaWNoLmlibS5jb208L0E+XSANCiAgICAgIDwvU1BBTj48L0ZP TlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgY29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTog MTJwdCI+PEJSPkFsbDogYmVsb3cgaXMgYSByb3VnaCBsaXN0IG9mIGNoYW5nZXMgYW5kIA0KICAg ICAgcGVuZGluZyBpc3N1ZXMgcmVnYXJkaW5nIHNlY3Rpb24gNi4gUGxlYXNlIHJldmlldy48QlI+ PEJSPiZuYnNwOzYuMS4xIA0KICAgICAgQXNzb2NpYXRpb246IFRoZSBDRSBjb3VsZCBvYnRhaW4g dGhlIEhCSSB3aXRoIGEgDQogICAgICBRdWVyeS1TR1QtRkVQcm90b2NvbExGUC1IZWFydGJlYXRJ bnRlcnZhbC4gR2l2ZW4gdGhlIG5ldyBBc3NvYyBtc2cgDQogICAgICBzdHJjdXRydWUsIHdlIGhh dmUgdG8gcmVtb3ZlIEhCSSBmcm9tIHRoZSBBc3NvYyBTZXR1cCANCiAgICAgIG1zZy48L1NQQU4+ PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4m bmJzcDsgW0FncmVlZCwgDQogICAgICB0aGlzIHdvdWxkIGJlIHBhcnQgb2YgUHJvdG9jb2xMRkIg ZXZlbiBpZiBpdCBpcyBpbiB0aGlzIA0KICAgICAgbWVzc2FnZV0mbmJzcDs8L1NQQU4+PC9GT05U PjxCUj48QlI+Jm5ic3A7Ni4xLjIgSG93IGhhcyB0aGUgc3JjSUQ9MCBjYXNlIA0KICAgICAgYmVl biBoYW5kbGVkIGluIHRoZSBpbnRlcm9wIHRlc3RzID8gSXMgdGhpcyByZWFsbHkgZmVhc2libGUg PzxGT05UIA0KICAgICAgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAg IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwi PiZuYnNwOyBbWWVzIGl0IA0KICAgICAgd29ya2VkIGZpbmUgZHVyaW5nIEludGVyb3BdJm5ic3A7 PC9TUEFOPjwvRk9OVD48QlI+PEJSPiZuYnNwOzYuMiBRdWVyeTogDQogICAgICBjb2Fyc2UgRkUg aW5mbyAoaW50ZXIvaW50cmEtRkUgdG9wb2xvZ3ksIGV0YykgZ29lcyBpbnRvIHRoZSANCiAgICAg IEZFUHJvdG9jb2xMRkIuPEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiAN CiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTog QXJpYWwiPiZuYnNwOyBbQWdyZWVkIGl0IA0KICAgICAgd291bGQgYmUgaW4gc29tZSBMRkIsIGJ1 dCBub3Qgc3VyZSB3aGljaCBMRkIgdGhpcyB3b3VsZCBiZSBwYXJ0IA0KICAgICAgb2YuLi4/XSZu YnNwOzwvU1BBTj48L0ZPTlQ+PEJSPjxCUj4mbmJzcDs2LjQ6IEV2ZW50czogY29hcnNlIENFIGFu ZCBGRSANCiAgICAgIGV2ZW50cyBnbyBpbnRvIENFL0ZFUHJvdG9jb2xMRkIuIE5vdGUgdGhhdCBm b3IgdGhlIHNha2Ugb2Ygc3ltbWV0cnksIHdlIA0KICAgICAgc2hvdWxkIGludHJvZHVjZSBhIENF UHJvdG9jb2xMRkIuPEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAg ICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJp YWwiPiZuYnNwOyBbU3VyZSwgd2h5IA0KICAgICAgZG9udCB5b3Ugc3RhcnQgZGVmaW5pbmcgc29t ZSBvZiB0aGVzZSBvYmplY3RzLi4udGhlbiB3ZSBjYW4gZGlzY3VzcyBtb3JlIA0KICAgICAgaW4g ZGV0YWlsXSZuYnNwOzwvU1BBTj48L0ZPTlQ+PEJSPjxCUj4mbmJzcDs2LjYgU3RhdGUgTWFpbnRl bmFuY2U6IEZFIA0KICAgICAgQWN0aXZhdGUvRGVhY3RpdmF0ZS9TaHV0ZG93biBiZWNvbWUgc2V0 dGFibGUgYXR0cmlidXRlcyBpbiB0aGUgDQogICAgICBGRVByb3RvY29sTEZCLjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDsmbmJzcDtbWWVzLCAN CiAgICAgIHRoZXNlIG1lc3NhZ2VzIHdpbGwgYmUgcGFydCBvZiBFdmVudHMgb3IgQ29uZmlnLi4u d2UgbmVlZCB0byBzcGVjaWZ5IA0KICAgICAgdGhpc10mbmJzcDs8L1NQQU4+PC9GT05UPjxCUj48 QlI+Jm5ic3A7Ni43IEhCIHJlbWFpbnMgYXMgaXMuPEZPTlQgDQogICAgICBmYWNlPUFyaWFsIGNv bG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7IA0KICAgICAgW0FncmVlZF0mbmJz cDs8L1NQQU4+PC9GT05UPjxCUj48QlI+SW4gc3VtbWFyeSwgd2UgaGF2ZSB0aGUgZm9sbG93aW5n IA0KICAgICAgb3BlcmF0aW9ucyBkZWZpbmVkIGZvciBlYWNoIG1lc3NhZ2UgdHlwZSAoIEkgYnJv a2UgdGhlIHRhYmxlIGludG8gMyANCiAgICAgIHBhcnRzKTo8QlI+PFRUPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDtbbG9va3MgDQogICAgICBn b29kIV0mbmJzcDs8L1NQQU4+PC9GT05UPjwvVFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNp emU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiAn Q291cmllciBOZXcnIj48QlI+PFRUPjxGT05UIA0KICAgICAgZmFjZT0iQ291cmllciBOZXciPk9Q RVJBVElPTiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgIEFQUExJ Q0FCTEUgTUVTU0FHRSBUWVBFUzwvRk9OVD48L1RUPjxCUj48QlI+PFRUPjxGT05UIA0KICAgICAg ZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7IA0KICAgICAgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyBBc3NvYy1TZXR1cCZuYnNw OyBBc3NvYy1TZXR1cC1SZXNwIA0KICAgICAgQXNzb2MtVGVhcmRvd24gSGVhcnRiZWF0PC9GT05U PjwvVFQ+PEJSPjxCUj48VFQ+PEZPTlQgDQogICAgICBmYWNlPSJDb3VyaWVyIE5ldyI+bm8gb3Bl cmF0aW9uczwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgDQogICAgICBmYWNlPSJDb3VyaWVyIE5l dyI+ZGVmaW5lZDwvRk9OVD48L1RUPjxCUj48QlI+PEJSPjxUVD48Rk9OVCANCiAgICAgIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyANCiAgICAgICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgUXVlcnkmbmJzcDsgUXVlcnktUmVz cCZuYnNwOyBDb25maWcmbmJzcDsgDQogICAgICBDb25maWctUmVzcDwvRk9OVD48L1RUPjxCUj48 VFQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPlNFVCwgREVMLCBVUERBVEUgDQogICAgICAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgICAmbmJzcDsmbmJzcDsg eCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgICAgIHg8L0ZPTlQ+PC9UVD48QlI+PFRUPjxGT05UIA0KICAgICAgZmFjZT0iQ291cmllciBO ZXciPkdFVCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgIHgmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgICB4PC9GT05UPjwvVFQ+ PEJSPjxUVD48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+RVZfUywgRVZfVSANCiAgICAgICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCiAgICAgICZuYnNwOyAmbmJzcDsmbmJzcDsgDQogICAgICB4Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICAgICAgeDwvRk9OVD48L1RU PjxCUj48QlI+PFRUPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4oZm9yIGV2ZW50IA0KICAgICAg c3Vic2NyaWJlL3Vuc3Vic2NyaWJlKTwvRk9OVD48L1RUPjxCUj48QlI+PEJSPjxUVD48Rk9OVCAN CiAgICAgIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgICZuYnNwOyZuYnNwOyAmbmJzcDsgUGFja2V0LVJl ZGlyPC9GT05UPjwvVFQ+PEJSPjxCUj48VFQ+PEZPTlQgDQogICAgICBmYWNlPSJDb3VyaWVyIE5l dyI+UEFZTE9BRCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgICAgIHg8L0ZPTlQ+PC9UVD48QlI+PEJSPjxCUj48VFQ+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7IA0KICAgICAgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IEV2ZW50LU5vdGlmJm5ic3A7IA0K ICAgICAgRXZlbnQtTm90aWYtUmVzcDwvRk9OVD48L1RUPjxCUj48VFQ+PEZPTlQgZmFjZT0iQ291 cmllciBOZXciPkVWRU5UICZuYnNwOyANCiAgICAgICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogICAgICB4Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IA0KICAgICAgeDwvRk9OVD48L1RUPjxCUj48L1NQQU4+PC9GT05UPjxC Uj5Ob3RlIHRoYXQgZm9yIFF1ZXJ5KC1SZXNwKSwgDQogICAgICBQYWNrZXQtUmVkaXIsIGFuZCBF dmVudC1Ob3RpZigtUmVzcCksIHdlIGhhdmUgZWFjaCB0aW1lIG9ubHkgb25lIA0KICAgICAgb3Bl cmF0aW9uLiBMb29rcyBhIGJpdCByZWR1bmRhbnQuIElkZWFzID88Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPWJsdWUgDQogICAgICBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj4mbmJzcDsgW1RoZXNlIGFyZSAN CiAgICAgIGFsbCB2ZXJ5IGRpZmZlcmVudCwgbGV0cyBsZWF2ZSB0aGVtIGFzIGlzLCBpdHMgbm90 IG5lY2Vzc2FyeSB0byBoYXZlIA0KICAgICAgbXVsdGlwbGUgb3BlcmF0aW9ucyBpbiBhbGwgDQog ICAgICBtZXNzYWdlc10mbmJzcDs8L1NQQU4+PC9GT05UPjxCUj48QlI+UmVnYXJkcyw8QlI+LVJv YmVydDwvUD4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iIGNvbG9yPWJsYWNrIHNpemU9Mz48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPjxCUj48QlI+PC9TUEFOPjwvRk9OVD48L1A+PFBSRT48Rk9OVCBmYWNlPSJDb3VyaWVy IE5ldyIgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPi0t IDwvU1BBTj48L0ZPTlQ+PC9QUkU+PFBSRT48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgY29sb3I9 YmxhY2sgc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPlJvYmVydCBIYWFzPC9T UEFOPjwvRk9OVD48L1BSRT48UFJFPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBjb2xvcj1ibGFj ayBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+SUJNIFp1cmljaCBSZXNlYXJj aCBMYWJvcmF0b3J5PC9TUEFOPjwvRk9OVD48L1BSRT48UFJFPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3IiBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+U+R1 bWVyc3RyYXNzZSA0PC9TUEFOPjwvRk9OVD48L1BSRT48UFJFPjxGT05UIGZhY2U9IkNvdXJpZXIg TmV3IiBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdCI+Q0gt ODgwMyBS/HNjaGxpa29uL1N3aXR6ZXJsYW5kPC9TUEFOPjwvRk9OVD48L1BSRT48UFJFPjxGT05U IGZhY2U9IkNvdXJpZXIgTmV3IiBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQt U0laRTogMTBwdCI+cGhvbmUgKzQxLTEtNzI0LTg2OTgmbmJzcDsgZmF4ICs0MS0xLTcyNC04NTc4 Jm5ic3A7IDxBIGhyZWY9Imh0dHA6Ly93d3cuenVyaWNoLmlibS5jb20vJTdFcmhhIj5odHRwOi8v d3d3Lnp1cmljaC5pYm0uY29tL35yaGE8L0E+PC9TUEFOPjwvRk9OVD48L1BSRT48L0RJVj48L0JM T0NLUVVPVEU+PC9CTE9DS1FVT1RFPjxCUj48UFJFIGNsYXNzPW1vei1zaWduYXR1cmUgY29scz0i NzIiPi0tIA0KUm9iZXJ0IEhhYXMNCklCTSBadXJpY2ggUmVzZWFyY2ggTGFib3JhdG9yeQ0KU+R1 bWVyc3RyYXNzZSA0DQpDSC04ODAzIFL8c2NobGlrb24vU3dpdHplcmxhbmQNCnBob25lICs0MS0x LTcyNC04Njk4ICBmYXggKzQxLTEtNzI0LTg1NzggIDxBIGNsYXNzPW1vei10eHQtbGluay1mcmVl dGV4dCBocmVmPSJodHRwOi8vd3d3Lnp1cmljaC5pYm0uY29tL35yaGEiPmh0dHA6Ly93d3cuenVy aWNoLmlibS5jb20vfnJoYTwvQT48L1BSRT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_1023_01C4B867.23A6E920-- --===============1240322945== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1240322945==-- From forces-protocol-bounces@ietf.org Fri Oct 22 07:13:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23445 for ; Fri, 22 Oct 2004 07:13:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKxYs-0003hG-MU for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 07:26:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKxGc-0005U3-Tu; Fri, 22 Oct 2004 07:07:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKxAb-0003qF-Os for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 07:01:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22175 for ; Fri, 22 Oct 2004 07:01:14 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKxNN-0003TV-PC for forces-protocol@ietf.org; Fri, 22 Oct 2004 07:14:30 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102204034346:37403 ; Fri, 22 Oct 2004 04:03:43 -0700 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: Ligang Dong In-Reply-To: <00dd01c4b803$806bd620$8401a8c0@dlg> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> <1098383190.2883.386.camel@localhost.localdomain> <00dd01c4b803$806bd620$8401a8c0@dlg> Organization: ZNYX Networks Message-Id: <1098442868.1112.38.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Oct 2004 07:01:08 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/22/2004 04:03:44 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/22/2004 04:03:47 AM, Serialize complete at 10/22/2004 04:03:47 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Yang, Lily L" , "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, Zsolt Haraszti , "Joel M. Halpern" , Alan DeKok , Ellen M Deleganes , "Wang, Weiming" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Content-Transfer-Encoding: 7bit Ligang, Lets continue this discussion assuming we dont need to update anything in the draft for now. Can you explain under which circumstances it was desirable to do multicast to several instances? I can give you an example where this would be valuable to me: Two of the (commodity) ASICs we use have a table per set of ports ranging from 1-8 ports per table. So I could have anywhere 6-24 LPM tables for example on the same FE - depending on the chip port enumeration or board layout. To me these are 6-48 instances of the same (LPM) LFB. when i look at all of them as part of a single NE, I have done some rough calculation and anywhere between 90-80% of the time i would send the _same_ table values. The rest of the time they will vary. So to me the mutlicast/broadcast/port range is valuable. I dont think this is only valuable to me or you (Sorry i missed the reasoning on your and Weiming part in the email thread), rather these are commodity ASICs which i expcte to be used a lot to help ForCES become ubiquitous. Folks, We cant just ignore the fact they exist and hope they will go away. My opinion, since we are discussing this post draft release: To bring back old discussions (Apologies in advance), to meet the above requirements, one would need to split the grammar so we have a Instance selector level where we could have specific instances within a class; as well ability to select multiple in one instance selection; i.e something along the lines of (hopefully diagrams look right): +--- T = LFBselect | | | | | +-- LFBCLASSID = 0x45 | | | +---T = LFBTARGET_UNICAST | | | | | +-- LFBInstance = 0x4321 | | | | | +-- T = ADD | | | | | | | +-- // path-data | | | | | | +---T = LFBTARGET_MCAST | | | | | +-- LFBInstance = 0x1234 | | | | | | | | +-- LFBInstanceMask = 0xf | | | | | +-- T = ADD | | | | | | | +-- // path-data | | | | | | | | | +---T = LFBTARGET_UNICAST | | | | | +-- LFBInstance = 0x5678 | | | | | +-- T = DEL | | | | | | | +-- // path-data | | | | | | Apologies if this is what is being discussed already in thread involving Steve/Robert/Weiming. Again, I may have miscontrued your need, but please chip in. cheers, jamal On Fri, 2004-10-22 at 02:51, Ligang Dong wrote: > hi, > > The following is my opinion about the debate whether multicast (i.e., multiple addressing) of LFB Instance is required or not. > > (1) In past several months, I am engaged in the implementation of ForCES & GRMP. Till now, a basic prototype is already constructed. Also it has been shown to several guys in this research field. From the view of implementation, the multicast of LFB instance is easy. > (2) Furthermore, multicast of LFB instance is more efficient than the "unicast" approach and the "virtualID" approach. Therefore, why not adopt multicast of LFB instance in the protocol. > best regards > Ligang > ----- Original Message ----- > From: "Zsolt Haraszti" > To: "Wang,Weiming" > Cc: "Khosravi, Hormuzd M" ; "Joel M. Halpern" ; ; "Steven Blake (petri-meat)" ; "Alan DeKok" ; "Jamal Hadi Salim" ; ; "Ellen M Deleganes" ; "Yang,Lily L" > Sent: Friday, October 22, 2004 2:26 AM > Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? > > > > Weiming, > > > > I have a very hard time to resonate with your examples, and therefore > > with your reasoning. > > > > For one, if you end up needing 64k LFBs from the same class, I think > > you or we did something wrong with the model. Sure you mean it an > > extreme case, but I think it is a misleading one. I envision > > practical LFB models having up to a few hundred LFB instances, where > > multiple instances of the same class will be in very different roles > > (e.g., a Classifier LFB supporting Diffserv versus a Classifier > > LFB supporting IPsec, etc.), hence more often not sharing any config > > data than sharing some. > > > > For two, displacing the two parts of the LFB address (class ID and > > instance ID) in the protocol is a much bigger concern to me than to > > allow ad-hoc/state-less multicast addressing. It would be in some > > sense similar to if in the IP header the (sub-)network address and > > host-address part of the IP address were placed in distant offsets. > > > > For three, on state-less versus state-ful multicast: Your example > > below is based on the very extreme case when you have a SINGLE > > config message addressed to a VERY LARGE number of LFB instances > > of the same class. I have not yet seen a practical case for this > > scenario. I reiterate that multicast groups are not ad-hoc, and > > there will be typically a large number of config updates sent to a > > group after the group is formed. > > > > Regards, > > Zsolt > > > > On Wed, 2004-10-20 at 01:56, Wang,Weiming wrote: > > > Joel, > > > > > > ----- Original Message ----- > > > From: "Joel M. Halpern" > > > Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? > > > > > > > > > > I do think that there may be thousands of instances. > > > > I do not think that this requires multiple addressing. > > > > > > > > I think that there are some interesting cases prompted by the possibility > > > > of very large numbers of LFBs, but they do not drive multiple addressing. > > > > > > > > My reasoning is based on the following premise. > > > > Firstly, if there are many LFBinstances s of a class, then it is likely > > > > that many fields of the LFB instances will be the same, but it is extremely > > > > unlikely that all fields of the LFB instances will be the same. > > > [Weiming]That's just why explicit multipul addressing is needed. For the case of > > > fields of all LFBinsatnces are the same, we can simply use a broadcast to do so. > > > Let me try to show a scenario why multipul addressing is needed for different > > > fields case. > > > > > > Firstly, because we have assumed the 16bit insatnce Id is not enough, we can > > > reasonably assmue there is a case where there are 64k or more instances (say > > > 64k). Further, we suppose Id1 to Id32k need to config parameter 1, Id(32k+1) to > > > Id 64k to set parameter2. > > > > > > Then, by using single instance addressing, the protocol becomes horrible, either > > > using one message or using separate messages. I just show the one message case. > > > The message format would like like: > > > > > > Msghdr > > > LFBselect > > > LFBClassID > > > Instance ID1 > > > Parameter1 > > > Instance ID2 > > > Parameter1 > > > ... > > > ... > > > Instance ID 32k > > > Parameter1 > > > Insatnce ID (32k+1) > > > Parameter2 > > > .... > > > Instance ID 64k > > > Parameter 2 > > > > > > Remember we then have 64k pair of instance and parameter in the protocol text. > > > In some cases, I'm just worried this make protocol unpractical. > > > > > > By using multipul addressing, the only text is as: > > > Msghdr > > > LFBselect > > > LFBClassID > > > Instance ID1 to ID 32k > > > Parameter1 > > > Instance ID (32k+1) to ID 64k > > > Parameter2 > > > > > > By using multicast scheme supposed by Zsolt, I suppose we need following steps: > > > 1. send a FE attribute to FE object to setup a virtualID1 for Instance 1 to > > > Instance 32k > > > 2. send a FE attribute to FE object to setup a virtualID2 for Instance (32k+1) > > > to Instance 64k > > > 3. config: > > > Msghdr > > > LFBselect > > > LFBClassID > > > Virtual ID1 > > > Parameter1 > > > Virtual ID2 > > > Parameter2 > > > 4. send a message to release virtual ID1 > > > 5. send a message to release virtual ID2 > > > > > > I can see the advatage of above explicit multipul addressing scheme very > > > clearly. > > > > > > > The simplest case to understand when one would need to setup all those LFBs > > > > at once is in a power recovery situation (the FE lost power, then > > > > recovered to an empty state.) The CE needs to send the configuration > > > > information to the FE. > > > [Weiming]Yes, that's the one case but not the only. > > > > > > > Secondly, I believe that transaction count is much more important than data > > > > volume. The FE is going to have to set every field in every LFB. Encoding > > > > is not going to change that. > > > [Weiming]I'm not sure if you mean for every operation, we should maintain a > > > transaction count. If is, then I have to say our current one message with > > > multiple Operation definitions has already be against the requirement. My > > > opinion is transaction maintenance is moderate, while multicast and multiple > > > operation are more important. > > > > > > > Given that there are distinct values in each LFB instance, there must be an > > > > operation against each LFB instance. > > > I don't think multicast will loose operation individuality. > > > > > > > > The marginal gain from having a single transaction to update the identical > > > > fields, and then individual transactions for the distinct fields is very > > > > small. It does not reduce the number of IOs or the core transaction rate. > > > [Weiming]At least it saves bits greatly and makes protocol practical. Remember > > > the capability between CE and FE are quite limited, especially in muli-hop > > > ForCES application. > > > > > > > > If it is desired to optimize for this case, we may want to introduce (in a > > > > future version of the protocol) some kind of block checkpoint / restart > > > > mechanism. The CE would record its full state about the FE, and then ask > > > > the FE for a dump suitable for restoral of the FE state. Upon restart, the > > > > CE would rebuild its state from its stored representation, and would ship > > > > the dump back to the FE to enable efficient rebuilding there. I can see > > > > significant value in such a mechanism. I do not however see a need to > > > > include this in the first deliverable of the protocol. > > > [Weiming]I suppose this is only for restart case, I can see many cases where > > > multiple addressing can apply, such as delete, change of LFB parameter, load and > > > unload of LFBs, etc. And also I think the scheme above is much more complex than > > > multiple addressing. So, my conclusion is, with a little bit expansion, we can > > > gain much, then why not we adpot it? > > > > > > Best regards, > > > Weiming > > > > > > > > Yours, > > > > Joel M. Halpern > > > > > -- > > Zsolt Haraszti Phone: +1 919-765-0027/2017 > > Modular Networks Mobile: +1 919-522-2337 > > Email: zsolt@modularnet.com > > > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 07:15:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23966 for ; Fri, 22 Oct 2004 07:15:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKxb6-0003l1-Tp for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 07:28:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKxM2-0007v8-5q; Fri, 22 Oct 2004 07:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKxFG-0005Nn-Nh for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 07:06:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22612 for ; Fri, 22 Oct 2004 07:06:03 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKxS2-0003Y3-UI for forces-protocol@ietf.org; Fri, 22 Oct 2004 07:19:19 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102204083377:37407 ; Fri, 22 Oct 2004 04:08:33 -0700 Subject: Re: [Forces-protocol] Re: Section 6 update From: Jamal Hadi Salim To: "Wang,Weiming" In-Reply-To: <102601c4b824$15a75dc0$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E0257920D@orsmsx408> <0fe601c4b816$d55930c0$845c21d2@Necom.hzic.edu.cn> <4178D3D1.3080608@zurich.ibm.com> <102601c4b824$15a75dc0$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1098443159.1112.43.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Oct 2004 07:05:59 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/22/2004 04:08:35 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/22/2004 04:08:36 AM X-Spam-Score: 2.2 (++) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092567049==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: d9238570526f12788af3d33c67f37625 --===============0092567049== Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 V2VpbWluZy9Sb2JlcnQsDQoNCkFsc28gZG9udCBmb3JnZXQgdG8gbG9vayBhdCB0aGUgb3ZlcnZp ZXcgc2VjdGlvbiBpbiB0aGUgbGF0ZXN0IGRyYWZ0DQpwb3N0ZWQgYnkgQXZyaS4gVGhlcmVzIGEg bGl0dGxlIHJlZmluZW1lbnQgb2YgdGhlIHNwbGl0IG9mIHRoZSB0d28gTEZCcw0KKGVhY2ggaW4g aXRzIG93biBzZWN0aW9uKS4NCkFzIHRvIHdoYXQgdG8gZG8gYWJvdXQgdGhlIEZFIE9iamVjdCBh bmQgRkUgUHJvdG9jb2wgb2JqZWN0LCBNeSBvcGluaW9uDQppcyB3ZSBzaG91bGQgZGVmaW5lIGV2 ZXJ5dGhpbmcgdGFodCB3ZSB0aGluayB3ZSB3aWxsIG5lZWQuIA0KSSB3b3VsZCB0aGluayB0aGUg bW9kZWwgdGVhbSB3aWxsIHRha2UgdGhvc2UgbmVlZHMgYW5kIG1ha2Ugc3VyZSBpdHMNCnBhcnQg b2YgdGhlIFhNTCBzcGVjLiBXZWltaW5nLCBhcmUgeW91IHN1Z2dlc3RpbmcgdG8gZG8gdGhlIHht bCBmcm9tIHVzPw0KDQpjaGVlcnMsDQpqYW1hbA0KDQpPbiBGcmksIDIwMDQtMTAtMjIgYXQgMDY6 NDQsIFdhbmcsV2VpbWluZyB3cm90ZToNCj4gSGkgUm9iZXJ0LA0KPiAgICAgICAgIC0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+ICAgICAgICAgRnJvbTogUm9iZXJ0IEhhYXMNCj4gICAg ICAgICBUbzogV2FuZyxXZWltaW5nDQo+ICAgICAgICAgQ2M6IEtob3NyYXZpLCBIb3JtdXpkIE0g OyBMaWdhbmcgRG9uZyA7IGhhZGlAem55eC5jb20gOw0KPiAgICAgICAgIGF2cmlAcHNnLmNvbSA7 IHJhbS5nb3BhbEBub2tpYS5jb20gOyBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcNCj4gICAgICAg ICBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMDQgNTozMyBQTQ0KPiAgICAgICAgIFN1Ympl Y3Q6IFJlOiBTZWN0aW9uIDYgdXBkYXRlDQo+ICAgICAgICAgDQo+ICAgICAgICAgV2VpbWluZy4N Cj4gICAgICAgICBJIHN1Z2dlc3Qgd2UgbWFrZSBhICBuZXcgc2VjdGlvbiAiRkUgTEZCIGFuZCBG RSBQcm90b2NvbCBMRkIiDQo+ICAgICAgICAganVzdCBiZWZvcmUgU2VjdGlvbiA1ICJDb21tb24g SGVhZGVyIiwgaW5zdGVhZCBvZiBsZWF2aW5nIHRoaXMNCj4gICAgICAgICB0byBzZWN0aW9uIDMu My4yLiANCj4gICAgICAgICBUaGlzIHdpbGwgcmVmbGVjdCB0aGUgaW1wb3J0YW5jZSBvZiB0aG9z ZSB0d28gTEZCcyBpbiB0aGUNCj4gICAgICAgICBvcGVyYXRpb24gb2YgdGhlIHByb3RvY29sLg0K PiAgICAgICAgIFtXZWltaW5nXUknbSBub3Qgb2JqZWN0aXZlIHRvIHRoaXMsIGp1c3QgYSBsaXR0 bGUgd29ycnkgaWYgaXQNCj4gICAgICAgICBtYXkgbWFrZSB0aGUgd2hvZWwgdGV4dCBjaGFuZ2Ug dG9vIG11Y2goc29tZSBjcm9zcyByZWZlcmVuY2VzDQo+ICAgICAgICAgb2Ygc2VjdGlvbiBudW1i ZXIpLiBXaGF0IEkgc2VlIG1vcmUgaXMgaWYgd2UgbmVlZCB0byBhZGQgYSBzdWINCj4gICAgICAg ICBzZWN0aW9uIHRvIGRldGFpbGVkbHkgZGVmaW5lIHRoZSBhdHRyaWJ1dGVzIG1lbnRpb25lZC4g VGFsa2luZw0KPiAgICAgICAgIGFib3V0IHRoaXMsIG9uZSB0aGluZyBJJ20gbm90IHZlcnkgc3Vy ZSBvZiB5b3VyIGlkZWEgaXMsIGRvDQo+ICAgICAgICAgeW91IHRoaW5rIHRoZXNlIGF0dHJpYnV0 ZXMgb2YgTEZCcyAob3IgZXZlbiB0aGUgd2hvbGUgTEZCDQo+ICAgICAgICAgZGVmaW5pdGlvbiAp IHNob3VsZCBiZSBkZWZpbmVkIGJ5IG91ciBwcm90b2NvbCBvciBieSBGRSBtb2RlbD8NCj4gICAg ICAgICBJIGp1c3Qgc2VlIHRoYXQgdGhlcmUgaXMgc29tZSBsb2dpY2FsIHByb2JsZW0gaWYgaXQg aXMgZGVmaW5lZA0KPiAgICAgICAgIGJ5IEZFIG1vZGVsLg0KPiAgICAgICAgIA0KPiAgICAgICAg IEknbGwgcG9zdCBteSB0ZXh0IHdoZW4gcmVhZHksIHBsZWFzZSBkbyB0aGUgc2FtZSwgYW5kIHdl J2xsDQo+ICAgICAgICAgbWVyZ2UuDQo+ICAgICAgICAgW1dlaW1pbmddSSB0aGluayB5b3VyIGN1 cnJlbnQgdmVyc2lvbiBoYXMgYWxyZWFkeSBkb25lIHdlbGwNCj4gICAgICAgICBhbmQgIG1hZGUg Z29vZCBzdW1tYXJ5IG9uIHRoZSBpc3N1ZS4gSSdsIGJlIG1vcmUgaW50ZXJlc3RlZCBpbg0KPiAg ICAgICAgIHRyeWluZyB0byBpbnB1dCBzb21ldGhpbmcgYmFzZWQgb24geW91ciB0ZXh0LiBUbyBq b2luDQo+ICAgICAgICAgaW4sIGJlY2F1c2UgYXMgeW91IGtub3cgdGhpcyBwYXJ0IGlzIG9uZSBv ZiB0aGF0IEknbSBtb3N0DQo+ICAgICAgICAgaW50ZXJlc3RlZCBhbmQgSSBob3BlIHRvIGhhdmUg bW9yZSBleGNoYW5nZSB3aXRoIHlvdSBvbiB0aGlzDQo+ICAgICAgICAgbGF0ZXIuICBXZSd2IGFj dHVhbGx5IGltcGxlbWVudGVkIHN1Y2ggbW9kZWwgaW4gb3VyIHRlc3RiZWQuIA0KPiAgICAgICAg IEJlc3QgcmVnYXJkcywNCj4gICAgICAgICBXZWltaW5nDQo+ICAgICAgICAgLVJvYmVydA0KPiAg ICAgICAgIA0KPiAgICAgICAgIFdhbmcsV2VpbWluZyB3cm90ZToNCj4gICAgICAgICANCj4gICAg ICAgICA+IFJvYmVydCwgDQo+ICAgICAgICAgPiAgDQo+ICAgICAgICAgPiBEb24ndCB3b3JyeSB0 b28gbXVjaCBhYm91dCB0aGUgRkUgTEZCIGFuZCBQcm90b2NvbCBMRkIsIEkNCj4gICAgICAgICA+ IHRoaW5rIGl0IGNhbiBiZSBmaXQgaXQgd2VsbCBpbiB0aGUgc2VjdGlvbnMuDQo+ICAgICAgICAg PiAgDQo+ICAgICAgICAgPiBBY3R1YWxseSBJIGNhbiBkbyBzb21ldGhpbmcgZm9yIFByb3RvY29s IExGQiBhbmQgRkUgTEZCIGlmDQo+ICAgICAgICAgPiB5b3UgdGhpbmsgcG9zc2libGUuDQo+ICAg ICAgICAgPiAgDQo+ICAgICAgICAgPiBSZWdhcmRzLA0KPiAgICAgICAgID4gV2VpbWluZw0KPiAg ICAgICAgID4gIA0KPiAgICAgICAgID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4g ICAgICAgICA+ICAgICAgICAgRnJvbTogS2hvc3JhdmksIEhvcm11emQgTQ0KPiAgICAgICAgID4g ICAgICAgICBUbzogUm9iZXJ0IEhhYXMNCj4gICAgICAgICA+ICAgICAgICAgQ2M6IExpZ2FuZyBE b25nIDsgaGFkaUB6bnl4LmNvbSA7IGF2cmlAcHNnLmNvbSA7DQo+ICAgICAgICAgPiAgICAgICAg IHJhbS5nb3BhbEBub2tpYS5jb20gOyBXZWltaW5nIFdhbmcgOw0KPiAgICAgICAgID4gICAgICAg ICBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcNCj4gICAgICAgICA+ICAgICAgICAgU2VudDogRnJp ZGF5LCBPY3RvYmVyIDIyLCAyMDA0IDQ6MzUgUE0NCj4gICAgICAgICA+ICAgICAgICAgU3ViamVj dDogU2VjdGlvbiA2IHVwZGF0ZQ0KPiAgICAgICAgID4gICAgICAgICANCj4gICAgICAgICA+ICAg ICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIEhpIFJvYmVydCwgQWxsDQo+ICAgICAgICAgPiAg ICAgICAgIA0KPiAgICAgICAgID4gICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIA0KPiAg ICAgICAgID4gICAgICAgICBIZXJlIHlvdSBnb0kgaGF2ZSB1cGRhdGVkIHNlY3Rpb25zIDYuMSwg Ni4zLCA2LjYNCj4gICAgICAgICA+ICAgICAgICAgKHJlbW92ZSksIDYuNyAoc2FtZSkuIEkgaGF2 ZSBkaXJlY3RseSB1c2VkIHRoZSB0ZXh0DQo+ICAgICAgICAgPiAgICAgICAgIHRoYXQgSmFtYWwg c2VudCBvdXQgd2hlcmV2ZXIgYXBwbGljYWJsZS4NCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAg ICAgICAgPiAgICAgICAgIFlvdSBjYW4gdXBkYXRlIHNlY3Rpb25zIDYuMiwgNi40LCA2LjUgLT4g aG93ZXZlciwgSQ0KPiAgICAgICAgID4gICAgICAgICB3b3VsZCBjaGVjayB3aXRoIFdlaW1pbmcg Zmlyc3QgYXMgY291cnRlc3kgc2luY2UgaGUNCj4gICAgICAgICA+ICAgICAgICAgaXMgd29ya2lu ZyBvbiB0aGVzZSBzZWN0aW9ucy4NCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAg ICAgICAgICANCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIEJUVywg dGhlcmUgd2VyZSBsb3RzIG9mIHRoaW5ncyBpbiB0aGUgdG9kbyBsaXN0IEkNCj4gICAgICAgICA+ ICAgICAgICAgc2VudCBvdXQNCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAgICAg ICAgICANCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIEhlYWRlciBT ZWN0aW9uIC0gSmFtYWwvUm9iZXJ0L1dlaW1pbmc/DQo+ICAgICAgICAgPiAgICAgICAgIA0KPiAg ICAgICAgID4gICAgICAgICBQcm90b2NvbCBMRkIgLSBSb2JlcnQvT3RoZXJzPw0KPiAgICAgICAg ID4gICAgICAgICANCj4gICAgICAgICA+ICAgICAgICAgRkUgTEZCIC0gUm9iZXJ0L090aGVycz8N Cj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIENFIExGQiAtID8NCj4g ICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIFN0YXRlIE1hY2hpbmUgZm9y IFByb3RvY29sICBMaWdhbmcgKHRha2VuKQ0KPiAgICAgICAgID4gICAgICAgICANCj4gICAgICAg ICA+ICAgICAgICAgIA0KPiAgICAgICAgID4gICAgICAgICANCj4gICAgICAgICA+ICAgICAgICAg V2lsbCB5b3UgYmUgd29ya2luZyBvbiBhbnkgb2YgdGhlc2UgPz8NCj4gICAgICAgICA+ICAgICAg ICAgDQo+ICAgICAgICAgPiAgICAgICAgICANCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAg ICAgPiAgICAgICAgIFBscyBkbyBsZXQgdXMga25vd0kgd2lsbCBzdGFydCB3b3JraW5nIG9uIHdo YXRldmVyDQo+ICAgICAgICAgPiAgICAgICAgIGhhc250IGJlZW4gY2xhaW1lZCBieSB0b21vcnJv dyBtb3JuaW5nIG15IHRpbWUuDQo+ICAgICAgICAgPiAgICAgICAgIA0KPiAgICAgICAgID4gICAg ICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIA0KPiAgICAgICAgID4gICAgICAgICBUaGFua3MN Cj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIEhvcm11emQNCj4gICAg ICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgICANCj4gICAgICAgICA+ICAgICAg ICAgDQo+ICAgICAgICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ICAg ICAgICAgPiAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIEZy b206IFJvYmVydCBIYWFzIFttYWlsdG86cmhhQHp1cmljaC5pYm0uY29tXSANCj4gICAgICAgICA+ ICAgICAgICAgU2VudDogRnJpZGF5LCBPY3RvYmVyIDIyLCAyMDA0IDEyOjM5IEFNDQo+ICAgICAg ICAgPiAgICAgICAgIFRvOiBLaG9zcmF2aSwgSG9ybXV6ZCBNDQo+ICAgICAgICAgPiAgICAgICAg IENjOiBMaWdhbmcgRG9uZzsgaGFkaUB6bnl4LmNvbTsgYXZyaUBwc2cuY29tOw0KPiAgICAgICAg ID4gICAgICAgICByYW0uZ29wYWxAbm9raWEuY29tOyBXZWltaW5nIFdhbmc7DQo+ICAgICAgICAg PiAgICAgICAgIGZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZw0KPiAgICAgICAgID4gICAgICAgICBT dWJqZWN0OiBSZTogQXBwbHlpbmcgY2hhbmdlcyB0byBTZWN0aW9uIDYgKFByb3RvY29sDQo+ICAg ICAgICAgPiAgICAgICAgIE1lc3NhZ2VzKQ0KPiAgICAgICAgID4gICAgICAgICANCj4gICAgICAg ICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgICANCj4gICAgICAgICA+ICAgICAgICAg DQo+ICAgICAgICAgPiAgICAgICAgIEhvcm11emQsDQo+ICAgICAgICAgPiAgICAgICAgIENvdWxk IHlvdSBwbGVhc2UgcGFzcyB0aGUgdG9rZW4gb24gc2VjdGlvbiA2DQo+ICAgICAgICAgPiAgICAg ICAgIHRvZ2V0aGVyIHdpdGggeW91ciBsYXRlc3QgdmVyc2lvbiBzbyBJIGNhbiBzdGFydA0KPiAg ICAgICAgID4gICAgICAgICBlZGl0aW5nIGl0ID8NCj4gICAgICAgICA+ICAgICAgICAgVGhhbmtz LA0KPiAgICAgICAgID4gICAgICAgICAtUm9iZXJ0DQo+ICAgICAgICAgPiAgICAgICAgIA0KPiAg ICAgICAgID4gICAgICAgICBLaG9zcmF2aSwgSG9ybXV6ZCBNIHdyb3RlOg0KPiAgICAgICAgID4g ICAgICAgICANCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIA0KPiAg ICAgICAgID4gICAgICAgICBSb2JlcnQsDQo+ICAgICAgICAgPiAgICAgICAgIA0KPiAgICAgICAg ID4gICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIA0KPiAgICAgICAgID4gICAgICAgICBB cyBJIHNhaWQsIHlvdXIgbm90ZSBtb3N0bHkgbG9va3MuLi5JIGhhdmUgcHV0IHNvbWUNCj4gICAg ICAgICA+ICAgICAgICAgbW9yZSBjb21tZW50cyBiZWxvdy4uLg0KPiAgICAgICAgID4gICAgICAg ICANCj4gICAgICAgICA+ICAgICAgICAgKEl0IHdvdWxkIGhlbHAgYSBsb3QgaWYgeW91IHN0YXJ0 IGRlZmluaW5nIHRoZSBGRSwgUHJvdG9jb2wgTEZCcy4uLikNCj4gICAgICAgICA+ICAgICAgICAg DQo+ICAgICAgICAgPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+ICAgICAg ICAgPiAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIEZyb206 IFJvYmVydCBIYWFzIFttYWlsdG86cmhhQHp1cmljaC5pYm0uY29tXSANCj4gICAgICAgICA+ICAg ICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgIA0KPiAgICAgICAgID4gICAgICAgICBBbGw6IGJl bG93IGlzIGEgcm91Z2ggbGlzdCBvZiBjaGFuZ2VzIGFuZCBwZW5kaW5nDQo+ICAgICAgICAgPiAg ICAgICAgIGlzc3VlcyByZWdhcmRpbmcgc2VjdGlvbiA2LiBQbGVhc2UgcmV2aWV3Lg0KPiAgICAg ICAgID4gICAgICAgICANCj4gICAgICAgICA+ICAgICAgICAgIDYuMS4xIEFzc29jaWF0aW9uOiBU aGUgQ0UgY291bGQgb2J0YWluIHRoZSBIQkkgd2l0aA0KPiAgICAgICAgID4gICAgICAgICBhIFF1 ZXJ5LVNHVC1GRVByb3RvY29sTEZQLUhlYXJ0YmVhdEludGVydmFsLiBHaXZlbg0KPiAgICAgICAg ID4gICAgICAgICB0aGUgbmV3IEFzc29jIG1zZyBzdHJjdXRydWUsIHdlIGhhdmUgdG8gcmVtb3Zl IEhCSQ0KPiAgICAgICAgID4gICAgICAgICBmcm9tIHRoZSBBc3NvYyBTZXR1cCBtc2cuICBbQWdy ZWVkLCB0aGlzIHdvdWxkIGJlDQo+ICAgICAgICAgPiAgICAgICAgIHBhcnQgb2YgUHJvdG9jb2xM RkIgZXZlbiBpZiBpdCBpcyBpbiB0aGlzIG1lc3NhZ2VdIA0KPiAgICAgICAgID4gICAgICAgICAN Cj4gICAgICAgICA+ICAgICAgICAgIDYuMS4yIEhvdyBoYXMgdGhlIHNyY0lEPTAgY2FzZSBiZWVu IGhhbmRsZWQgaW4gdGhlDQo+ICAgICAgICAgPiAgICAgICAgIGludGVyb3AgdGVzdHMgPyBJcyB0 aGlzIHJlYWxseSBmZWFzaWJsZSA/ICBbWWVzIGl0DQo+ICAgICAgICAgPiAgICAgICAgIHdvcmtl ZCBmaW5lIGR1cmluZyBJbnRlcm9wXSANCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAg PiAgICAgICAgICA2LjIgUXVlcnk6IGNvYXJzZSBGRSBpbmZvIChpbnRlci9pbnRyYS1GRSB0b3Bv bG9neSwNCj4gICAgICAgICA+ICAgICAgICAgZXRjKSBnb2VzIGludG8gdGhlIEZFUHJvdG9jb2xM RkIuICBbQWdyZWVkIGl0IHdvdWxkDQo+ICAgICAgICAgPiAgICAgICAgIGJlIGluIHNvbWUgTEZC LCBidXQgbm90IHN1cmUgd2hpY2ggTEZCIHRoaXMgd291bGQgYmUNCj4gICAgICAgICA+ICAgICAg ICAgcGFydCBvZi4uLj9dIA0KPiAgICAgICAgID4gICAgICAgICANCj4gICAgICAgICA+ICAgICAg ICAgIDYuNDogRXZlbnRzOiBjb2Fyc2UgQ0UgYW5kIEZFIGV2ZW50cyBnbyBpbnRvDQo+ICAgICAg ICAgPiAgICAgICAgIENFL0ZFUHJvdG9jb2xMRkIuIE5vdGUgdGhhdCBmb3IgdGhlIHNha2Ugb2YN Cj4gICAgICAgICA+ICAgICAgICAgc3ltbWV0cnksIHdlIHNob3VsZCBpbnRyb2R1Y2UgYSBDRVBy b3RvY29sTEZCLiANCj4gICAgICAgICA+ICAgICAgICAgW1N1cmUsIHdoeSBkb250IHlvdSBzdGFy dCBkZWZpbmluZyBzb21lIG9mIHRoZXNlDQo+ICAgICAgICAgPiAgICAgICAgIG9iamVjdHMuLi50 aGVuIHdlIGNhbiBkaXNjdXNzIG1vcmUgaW4gZGV0YWlsXSANCj4gICAgICAgICA+ICAgICAgICAg DQo+ICAgICAgICAgPiAgICAgICAgICA2LjYgU3RhdGUgTWFpbnRlbmFuY2U6IEZFDQo+ICAgICAg ICAgPiAgICAgICAgIEFjdGl2YXRlL0RlYWN0aXZhdGUvU2h1dGRvd24gYmVjb21lIHNldHRhYmxl DQo+ICAgICAgICAgPiAgICAgICAgIGF0dHJpYnV0ZXMgaW4gdGhlIEZFUHJvdG9jb2xMRkIuICBb WWVzLCB0aGVzZQ0KPiAgICAgICAgID4gICAgICAgICBtZXNzYWdlcyB3aWxsIGJlIHBhcnQgb2Yg RXZlbnRzIG9yIENvbmZpZy4uLndlIG5lZWQNCj4gICAgICAgICA+ICAgICAgICAgdG8gc3BlY2lm eSB0aGlzXSANCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAgICAgICAgICA2Ljcg SEIgcmVtYWlucyBhcyBpcy4gIFtBZ3JlZWRdIA0KPiAgICAgICAgID4gICAgICAgICANCj4gICAg ICAgICA+ICAgICAgICAgSW4gc3VtbWFyeSwgd2UgaGF2ZSB0aGUgZm9sbG93aW5nIG9wZXJhdGlv bnMgZGVmaW5lZA0KPiAgICAgICAgID4gICAgICAgICBmb3IgZWFjaCBtZXNzYWdlIHR5cGUgKCBJ IGJyb2tlIHRoZSB0YWJsZSBpbnRvIDMNCj4gICAgICAgICA+ICAgICAgICAgcGFydHMpOg0KPiAg ICAgICAgID4gICAgICAgICAgW2xvb2tzIGdvb2QhXSANCj4gICAgICAgICA+ICAgICAgICAgT1BF UkFUSU9OICAgICAgIEFQUExJQ0FCTEUgTUVTU0FHRSBUWVBFUw0KPiAgICAgICAgID4gICAgICAg ICANCj4gICAgICAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgIEFzc29jLVNldHVwICBBc3Nv Yy1TZXR1cC1SZXNwDQo+ICAgICAgICAgPiAgICAgICAgIEFzc29jLVRlYXJkb3duIEhlYXJ0YmVh dA0KPiAgICAgICAgID4gICAgICAgICANCj4gICAgICAgICA+ICAgICAgICAgbm8gb3BlcmF0aW9u cw0KPiAgICAgICAgID4gICAgICAgICBkZWZpbmVkDQo+ICAgICAgICAgPiAgICAgICAgIA0KPiAg ICAgICAgID4gICAgICAgICANCj4gICAgICAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgIFF1 ZXJ5ICBRdWVyeS1SZXNwICBDb25maWcgDQo+ICAgICAgICAgPiAgICAgICAgIENvbmZpZy1SZXNw DQo+ICAgICAgICAgPiAgICAgICAgIFNFVCwgREVMLCBVUERBVEUgICAgICAgICAgICAgICAgICAg ICB4ICAgICAgICAgIHgNCj4gICAgICAgICA+ICAgICAgICAgR0VUICAgICAgICAgICAgICAgeCAg ICAgICAgIHgNCj4gICAgICAgICA+ICAgICAgICAgRVZfUywgRVZfVSAgICAgICAgICAgICAgICAg ICAgICAgICAgIHggICAgICAgICAgeA0KPiAgICAgICAgID4gICAgICAgICANCj4gICAgICAgICA+ ICAgICAgICAgKGZvciBldmVudCBzdWJzY3JpYmUvdW5zdWJzY3JpYmUpDQo+ICAgICAgICAgPiAg ICAgICAgIA0KPiAgICAgICAgID4gICAgICAgICANCj4gICAgICAgICA+ICAgICAgICAgICAgICAg ICAgICAgICAgIFBhY2tldC1SZWRpcg0KPiAgICAgICAgID4gICAgICAgICANCj4gICAgICAgICA+ ICAgICAgICAgUEFZTE9BRCAgICAgICAgICAgIHgNCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAg ICAgICAgPiAgICAgICAgIA0KPiAgICAgICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgRXZl bnQtTm90aWYgIEV2ZW50LU5vdGlmLVJlc3ANCj4gICAgICAgICA+ICAgICAgICAgRVZFTlQgICAg ICAgICAgICAgIHggICAgICAgICAgICAgICAgeA0KPiAgICAgICAgID4gICAgICAgICANCj4gICAg ICAgICA+ICAgICAgICAgTm90ZSB0aGF0IGZvciBRdWVyeSgtUmVzcCksIFBhY2tldC1SZWRpciwg YW5kDQo+ICAgICAgICAgPiAgICAgICAgIEV2ZW50LU5vdGlmKC1SZXNwKSwgd2UgaGF2ZSBlYWNo IHRpbWUgb25seSBvbmUNCj4gICAgICAgICA+ICAgICAgICAgb3BlcmF0aW9uLiBMb29rcyBhIGJp dCByZWR1bmRhbnQuIElkZWFzID8gIFtUaGVzZQ0KPiAgICAgICAgID4gICAgICAgICBhcmUgYWxs IHZlcnkgZGlmZmVyZW50LCBsZXRzIGxlYXZlIHRoZW0gYXMgaXMsIGl0cw0KPiAgICAgICAgID4g ICAgICAgICBub3QgbmVjZXNzYXJ5IHRvIGhhdmUgbXVsdGlwbGUgb3BlcmF0aW9ucyBpbiBhbGwN Cj4gICAgICAgICA+ICAgICAgICAgbWVzc2FnZXNdIA0KPiAgICAgICAgID4gICAgICAgICANCj4g ICAgICAgICA+ICAgICAgICAgUmVnYXJkcywNCj4gICAgICAgICA+ICAgICAgICAgLVJvYmVydA0K PiAgICAgICAgID4gICAgICAgICANCj4gICAgICAgICA+ICAgICAgICAgDQo+ICAgICAgICAgPiAg ICAgICAgIA0KPiAgICAgICAgID4gICAgICAgICANCj4gICAgICAgICA+ICAgICAgICAgLS0gDQo+ ICAgICAgICAgPiAgICAgICAgIFJvYmVydCBIYWFzDQo+ICAgICAgICAgPiAgICAgICAgIElCTSBa dXJpY2ggUmVzZWFyY2ggTGFib3JhdG9yeQ0KPiAgICAgICAgID4gICAgICAgICBT5HVtZXJzdHJh c3NlIDQNCj4gICAgICAgICA+ICAgICAgICAgQ0gtODgwMyBS/HNjaGxpa29uL1N3aXR6ZXJsYW5k DQo+ICAgICAgICAgPiAgICAgICAgIHBob25lICs0MS0xLTcyNC04Njk4ICBmYXggKzQxLTEtNzI0 LTg1NzggIGh0dHA6Ly93d3cuenVyaWNoLmlibS5jb20vfnJoYQ0KPiAgICAgICAgIA0KPiAgICAg ICAgIA0KPiAgICAgICAgIC0tIA0KPiAgICAgICAgIFJvYmVydCBIYWFzDQo+ICAgICAgICAgSUJN IFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5DQo+ICAgICAgICAgU+R1bWVyc3RyYXNzZSA0DQo+ ICAgICAgICAgQ0gtODgwMyBS/HNjaGxpa29uL1N3aXR6ZXJsYW5kDQo+ICAgICAgICAgcGhvbmUg KzQxLTEtNzI0LTg2OTggIGZheCArNDEtMS03MjQtODU3OCAgaHR0cDovL3d3dy56dXJpY2guaWJt LmNvbS9+cmhhDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRm9yY2VzLXByb3RvY29sIG1haWxp bmcgbGlzdA0KPiBGb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzLXByb3RvY29sDQoNCg== --===============0092567049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0092567049==-- From forces-protocol-bounces@ietf.org Fri Oct 22 07:48:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25690 for ; Fri, 22 Oct 2004 07:48:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKy7J-0004Nx-TD for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 08:01:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKxnb-0005R5-Oy; Fri, 22 Oct 2004 07:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKxkH-0004HH-12 for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 07:38:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25115 for ; Fri, 22 Oct 2004 07:38:07 -0400 (EDT) From: ram.gopal@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKxx2-00044Q-Ft for forces-protocol@ietf.org; Fri, 22 Oct 2004 07:51:21 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9MBbge24530; Fri, 22 Oct 2004 14:37:42 +0300 (EET DST) X-Scanned: Fri, 22 Oct 2004 14:33:50 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9MBXoKC004698; Fri, 22 Oct 2004 14:33:50 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00QHnA53; Fri, 22 Oct 2004 14:33:49 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9MBXja11007; Fri, 22 Oct 2004 14:33:45 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 22 Oct 2004 06:33:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Forces-protocol] Re: protocol draft editing? Date: Fri, 22 Oct 2004 07:33:42 -0400 Message-ID: Thread-Topic: [Forces-protocol] Re: protocol draft editing? thread-index: AcS3qtii9vXRNEFHTMaB+7E4kn9n6wADCswwABz5mGA= To: , X-OriginalArrivalTime: 22 Oct 2004 11:33:43.0750 (UTC) FILETIME=[FC7E7660:01C4B82A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: avri@psg.com, rha@zurich.ibm.com, wmwang@mail.hzic.edu.cn, donglg@mail.hzic.edu.cn, forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Good, BTW i will not be attending due to travel restrictions and other = issues. regards ramg -----Original Message----- From: forces-protocol-bounces@ietf.org [mailto:forces-protocol-bounces@ietf.org]On Behalf Of ext Khosravi, Hormuzd M Sent: Thursday, October 21, 2004 5:44 PM To: hadi@znyx.com Cc: Gopal Ram (Nokia-NRC/Boston); Ligang Dong; forces-protocol@ietf.org; avri@psg.com; Weiming Wang; Robert Haas Subject: RE: [Forces-protocol] Re: protocol draft editing? Jamal,=20 Pls go ahead...it would be great if you present the protocol. Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 BTW, folks I would like to volunteer to present on the protocol this time if people are OK with it. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 11:30:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14159 for ; Fri, 22 Oct 2004 11:30:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1aI-0000VF-Qe for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 11:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1MM-0000TW-Fe; Fri, 22 Oct 2004 11:29:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1GB-0006eY-A2 for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 11:23:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13327 for ; Fri, 22 Oct 2004 11:23:15 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CL1Rx-0000I5-MP for forces-protocol@ietf.org; Fri, 22 Oct 2004 11:36:33 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Fri, 22 Oct 2004 23:40:57 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Fri, 22 Oct 2004 23:17:13 +0800 Message-ID: <108701c4b84a$8028ba60$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E02579209@orsmsx408> <420441FF-23F7-11D9-9DB1-000393CC2112@acm.org> Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Date: Fri, 22 Oct 2004 23:19:17 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 2.0 (++) X-Scan-Signature: 6d231d878f8d68d85cf12b60d23450ce Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Robert Haas , Ligang Dong , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: afbb91703506ab43c817903f0dd6f23d Hi Avri, I'v updated the RedirectMsg, QueryMsg, and EventMsg as XML file in the attachments. It's a pity that I just find I can not pass to parse the file by xml2rfc because it included some of the format defined by you, therefore it seems I can not verify the correctness of the file for the xml format. I really want to save some of your work but it seems I'm not able to. If you like, next time I would just use txt like Hormuzd did. There is no change to the definition part. Hormuzd, I have mostly tried best to follow your format, but still there are some places that I prefer my style. Anyway, it matters less. thank you. Weiming ----- Original Message ----- From: > > On 22 okt 2004, at 02.19, Khosravi, Hormuzd M wrote: > > > I sent you the entire section so you can just put it in. You don't have > > to find any diffs. I have attached it again for your convenience. > > doesn't quite work like that. > but i have put in the changes as far as i can tell. check to make sure > i got it right. > > http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-1.txt > > > > > BTW, where are you at this moment? in the US or Europe? Just curious in > > case we need to setup some conference calls. > > this week in the us - east coast. > > a. > begin 666 RedirectMsg.xml M/#]X;6P@=F5R6=E;B\^6$U,(&5D:71O2!M87D@2!O=&AE2!M87D@#0H@(" @ M;V-C87-I;VYA;&QY(&)E(&]T:&5R('!R;W1O8V]L('!A8VME=',L('=H:6-H M('5S=6%L;'D@:&%P<&5N( T*(" @('=H96X@0T4@86YD($9%(&%R92!J;VEN M=&QY(&EM<&QE;65N=&EN9R!S;VUE(&AI9V@M=&]U8V@@#0H@(" @;W!E2!R961I M2X@/"]T/@T*#0H\=G-P86-E(&)L86YK3&EN97,](C$B("\^#0H\;&ES="!S M='EL93TB:&%N9VEN9R(@:&%N9TEN9&5N=#TB,3'0@ M/2 B161I=&]R:6%L($YO=&4Z("(^( T*5&AE'0@/2(@(" @(%1H;W5G:'0@,3H@(CX-"E1O M(&1E9FEN92!,1D)S(&-A;&QE9" G4F5D:7)E8W13:6YK)R!A;F0@)U)E9&ER M96-T5&%P)R!F;W(-"G!A8VME="!R961I2!O=&AE2P@ M=&AE("=2961I2!T:&4@#0H@(" @)U)E8VER M96-T5&%P)R!,1D(@86-T2!A(%-C:&5D=6QE2!B>2!A(&9O65R(&]R(&5V96X@ M;F5T=V]R:R!L979E;"!H96%D97(@:7,@96YO=6=H+B!4:&4@2!M;W)E(&]R(&QE3H@(CX\=G-P86-E("\^#0I#;VYS:7-T'0]("));G-T86YC92!)1#H@(CX\=G-P86-E("\^#0I);G-T M86YC92!)1"!F;W(@=&AE("=2961I2!&12!M;V1E;"P@;W(@8F%S960@;VX@=F5N9&]R('-P96-I9FEC871I;VYS M( T*(" @(&EF('1H92!R961I2!796EM:6YG M(%=A;F<@,C P-"\Q,"\R,@T*/"$M+2!);F-O6=E;B\^6$U,(&5D:71O4US9U8Q+C$L(#(P,#0M,#8M,3@-"B @(" @+2!C:&%N9V4@16YC M;V1I;F=4>7!E('1O(%1Y<&4-"B @(" @*BHJ(%%U97)Y37-G5C$N,BP@,C P M-"TQ,"TR, T*(" @(" M(&9O4US9R(@=&ET;&4](E%U97)Y(&%N9"!2 M97-P;VYS92!-97-S86=E2!-97-S86=E(CX-"@T*/'0^07,@ M=7-U86PL(&$@<75E2!F'0](")-97-S86=E($AE861E7!E(&EN('1H92!H96%D97(@:7,@7!E/2 G475E2!M97-S86=E(&ES(&%L M=V%Y'!E8W1E9"X@268@=&AE( T*(" @($%#2R!F;&%G(&ES('-E="!O M=&AE'0@/2 B365S2!M97-S86=E(&)O9'D@8V]N6QE/2)N=6UB97)S(B!H86YG26YD96YT/2(S(CX-"CQT M/E5N9&5R(&1I7!E($QE;F=T:"!6 M86QU90T*(" @(" @("!4>7!E(#H]($E.4W-E;&5C= T*(" @(" @("!686QU M92 Z/2!);G-T86YC94E$("A286YG94UA&9F9F9F9F9F)RP@=&AE('9A;'5E(&]F('=H:6-H(&ES('1H M92!S86UE(&%S( T*(" @($EN2!H97)E+CPO=#X-"CPO;&ES=#X@(" -"CPO;&ES=#X-"CQV M2(^#0H\87)T=V]R:SX@(" @#0H@(" @ M("LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM M*RTK+2LM*RTK+2LM*RTK+2LM*RTK#0H@(" @('P@(" @5'EP92 ]($]P97)A M=&EO;G,@*$=%5"D@(" @?" @(" @(" @(" @(" @($QE;F=T:" @(" @(" @ M("!\#0H@(" @("LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK M+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK#0H@(" @('P@(" @(" @ M(" @(" @(" @(" @(" @("!0871H*&]R($%T=')I8G5T92!)1#\I(" @(" @ M(" @(" @(" @("!\#0H@(" @("LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM M*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK#0H@(" @ M('P@(" @(" @(" @(" @(" @(" @(" @(" @(" @475E'0@ M/2 B161I=&]R:6%L($YO=&4Z(CX@#0I4:&5R92!I"!T;R!B92!I;F-L=61E9"!I;B!F;VQL;W=E9" -"B @("!D871A+@T*/"]T M/@T*/"]L:7-T/@T*/'9S<&%C92!B;&%N:TQI;F5S/2(Q(B O/@T*/'0@:&%N M9U1E>'0](")1=65R>2!$871A.B B/CQV2D-"B @ M(" @? T*(" @("!\#0H@(" @("LM+2T@5" ]($Q&0G-E;&5C= T*(" @("!\ M(" @(" @("!\#0H@(" @('P@(" @(" @("LM+2!,1D)#3$%34TE$(#T@=&%R M9V5T($Q&0B!C;&%S5)E2!R97-U;'0@ M8V%N(&)E('1H92!I;F9O2!O<&5R871I;VX@:7,@'0](")-97-S86=E('1R M86YS9F5R(&1I2!R97-P;VYS92!M97-S86=E('1R86YS9F5R M(&1I7!E(&EN('1H92!H96%D97(@:7,@7!E/2 G475E2!M97-S86=E( T*(" @('-E;F1E2!R97-U;'1S(&9O2!$871A)RP-"B @("!A5]297-P;VYS92(^#0H\87)T=V]R:SX-"B @ M(" @*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM M*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2L-"B @(" @?" @("!4>7!E(#T@3W!E M2!297-P;VYS92!$ M871A(" @(" @(" @(" @(" @(" @("!\#0H@(" @("X@(" @(" @(" @(" @ M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @ M(" @(" N#0H@(" @("LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM M*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK#0H\+V%R='=O7!E('1O(%1Y<&4@*&9R;VT@ M5U2!796EM:6YG(%=A;F<@)DQI9V%N M9R!$;VYG( T*(" @(" J*BH@475E6=E;B\^6$U,(&5D:71O7!E('1O(%1Y<&4N#0HM+3X-"@T*/'-E8W1I;VX@86YC:&]R/2)% M=F5N=$US9R(@=&ET;&4](D5V96YT($YO=&EF:6-A=&EO;B!A;F0@4F5S<&]N M6YC:')O;F]U2!O;F4@;W(@;6]R92!O=&AE6QE/2)S>6UB;VQS(CX- M"CQT/D5V96YT2!&;W)#15,@ M<')O=&]C;VPL($9O6QE/2)H86YG:6YG(B!H86YG26YD96YT/2(Q-R(@/@T*/'0@:&%N9U1E M>'0](D5D:71O6QE/2)H86YG:6YG(B!H86YG26YD M96YT/2(Q(CX-"CQT(&AA;F=497AT/2 B365S2!M96%N2!R96-E M:79E9"!T:&4@;65S3H@(CX\=G-P86-E("\^#0I4:&4@;65S'0](")/ M<&5R871I;VX@5$Q6.B B/CQV7!E(#T@3W!E'0](")%=F5N="!$871A.B B/CQV2 -"B @ M("!B92!I;G1E2!T:&4@6QE/2)H86YG:6YG(B!H86YG26YD96YT/2(Q(CX-"CQT M(&AA;F=497AT/2 B365S'0](")-97-S86=E($)O9'DZ("(^/'9S<&%C92 O M/@T*5&AE(&UE2!F;W(@86X@979E;G0@;F]T:69I8V%T:6]N M(&UE'0](")297-U;'0Z("(^/'9S<&%C92 O/@T*5&AI'0](")296%S;VXL($-O9&4Z M("(^/'9S<&%C92 O/@T*5&AI65R( T*(" @(&-A;B!B92!A;&QO8V%T M960@:&5R92P@=&AA="!I2!B92!I;G1E2!R96-E:79E9"!O M6=E;B\^6$U,(&5D:71O; Fri, 22 Oct 2004 11:43:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1mE-0000gn-UE for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 11:56:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1Td-0002va-JY; Fri, 22 Oct 2004 11:37:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1NO-00018X-ID for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 11:30:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14147 for ; Fri, 22 Oct 2004 11:30:42 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CL1Zz-0000UF-As for forces-protocol@ietf.org; Fri, 22 Oct 2004 11:44:01 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Fri, 22 Oct 2004 23:49:32 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Fri, 22 Oct 2004 23:25:48 +0800 Message-ID: <10ae01c4b84b$b3991ab0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E0257920D@orsmsx408><0fe601c4b816$d55930c0$845c21d2@Necom.hzic.edu.cn><4178D3D1.3080608@zurich.ibm.com><102601c4b824$15a75dc0$845c21d2@Necom.hzic.edu.cn> <1098443159.1112.43.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Re: Section 6 update Date: Fri, 22 Oct 2004 23:27:54 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Hi Jamal, Robert, ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: [Forces-protocol] Re: Section 6 update > Weiming/Robert, > > Also dont forget to look at the overview section in the latest draft > posted by Avri. Theres a little refinement of the split of the two LFBs > (each in its own section). > As to what to do about the FE Object and FE Protocol object, My opinion > is we should define everything taht we think we will need. > I would think the model team will take those needs and make sure its > part of the XML spec. Weiming, are you suggesting to do the xml from us? [Weiming] Yes, but I'm not sure if it should be defined inside this protocol text or just by another draft. I remember you also mentioned such thought before. We actually have the same question on Redirect LFBs, anyway any LFB like things that between FE model and protocol. Now it seems very popular to summarize everything as LFB, I even think of TML layer as LFBs from PL layer, but not sure. cheers, weiming > > cheers, > jamal > > On Fri, 2004-10-22 at 06:44, Wang,Weiming wrote: > > Hi Robert, > > ----- Original Message ----- > > From: Robert Haas > > To: Wang,Weiming > > Cc: Khosravi, Hormuzd M ; Ligang Dong ; hadi@znyx.com ; > > avri@psg.com ; ram.gopal@nokia.com ; forces-protocol@ietf.org > > Sent: Friday, October 22, 2004 5:33 PM > > Subject: Re: Section 6 update > > > > Weiming. > > I suggest we make a new section "FE LFB and FE Protocol LFB" > > just before Section 5 "Common Header", instead of leaving this > > to section 3.3.2. > > This will reflect the importance of those two LFBs in the > > operation of the protocol. > > [Weiming]I'm not objective to this, just a little worry if it > > may make the whoel text change too much(some cross references > > of section number). What I see more is if we need to add a sub > > section to detailedly define the attributes mentioned. Talking > > about this, one thing I'm not very sure of your idea is, do > > you think these attributes of LFBs (or even the whole LFB > > definition ) should be defined by our protocol or by FE model? > > I just see that there is some logical problem if it is defined > > by FE model. > > > > I'll post my text when ready, please do the same, and we'll > > merge. > > [Weiming]I think your current version has already done well > > and made good summary on the issue. I'l be more interested in > > trying to input something based on your text. To join > > in, because as you know this part is one of that I'm most > > interested and I hope to have more exchange with you on this > > later. We'v actually implemented such model in our testbed. > > Best regards, > > Weiming > > -Robert > > > > Wang,Weiming wrote: > > > > > Robert, > > > > > > Don't worry too much about the FE LFB and Protocol LFB, I > > > think it can be fit it well in the sections. > > > > > > Actually I can do something for Protocol LFB and FE LFB if > > > you think possible. > > > > > > Regards, > > > Weiming > > > > > > ----- Original Message ----- > > > From: Khosravi, Hormuzd M > > > To: Robert Haas > > > Cc: Ligang Dong ; hadi@znyx.com ; avri@psg.com ; > > > ram.gopal@nokia.com ; Weiming Wang ; > > > forces-protocol@ietf.org > > > Sent: Friday, October 22, 2004 4:35 PM > > > Subject: Section 6 update > > > > > > > > > Hi Robert, All > > > > > > > > > > > > Here you goI have updated sections 6.1, 6.3, 6.6 > > > (remove), 6.7 (same). I have directly used the text > > > that Jamal sent out wherever applicable. > > > > > > You can update sections 6.2, 6.4, 6.5 -> however, I > > > would check with Weiming first as courtesy since he > > > is working on these sections. > > > > > > > > > > > > BTW, there were lots of things in the todo list I > > > sent out > > > > > > > > > > > > Header Section - Jamal/Robert/Weiming? > > > > > > Protocol LFB - Robert/Others? > > > > > > FE LFB - Robert/Others? > > > > > > CE LFB - ? > > > > > > State Machine for Protocol Ligang (taken) > > > > > > > > > > > > Will you be working on any of these ?? > > > > > > > > > > > > Pls do let us knowI will start working on whatever > > > hasnt been claimed by tomorrow morning my time. > > > > > > > > > > > > Thanks > > > > > > Hormuzd > > > > > > > > > > > > > > > ____________________________________________________ > > > > > > From: Robert Haas [mailto:rha@zurich.ibm.com] > > > Sent: Friday, October 22, 2004 12:39 AM > > > To: Khosravi, Hormuzd M > > > Cc: Ligang Dong; hadi@znyx.com; avri@psg.com; > > > ram.gopal@nokia.com; Weiming Wang; > > > forces-protocol@ietf.org > > > Subject: Re: Applying changes to Section 6 (Protocol > > > Messages) > > > > > > > > > > > > > > > Hormuzd, > > > Could you please pass the token on section 6 > > > together with your latest version so I can start > > > editing it ? > > > Thanks, > > > -Robert > > > > > > Khosravi, Hormuzd M wrote: > > > > > > > > > > > > Robert, > > > > > > > > > > > > As I said, your note mostly looks...I have put some > > > more comments below... > > > > > > (It would help a lot if you start defining the FE, Protocol LFBs...) > > > > > > > > > ____________________________________________________ > > > > > > From: Robert Haas [mailto:rha@zurich.ibm.com] > > > > > > > > > All: below is a rough list of changes and pending > > > issues regarding section 6. Please review. > > > > > > 6.1.1 Association: The CE could obtain the HBI with > > > a Query-SGT-FEProtocolLFP-HeartbeatInterval. Given > > > the new Assoc msg strcutrue, we have to remove HBI > > > from the Assoc Setup msg. [Agreed, this would be > > > part of ProtocolLFB even if it is in this message] > > > > > > 6.1.2 How has the srcID=0 case been handled in the > > > interop tests ? Is this really feasible ? [Yes it > > > worked fine during Interop] > > > > > > 6.2 Query: coarse FE info (inter/intra-FE topology, > > > etc) goes into the FEProtocolLFB. [Agreed it would > > > be in some LFB, but not sure which LFB this would be > > > part of...?] > > > > > > 6.4: Events: coarse CE and FE events go into > > > CE/FEProtocolLFB. Note that for the sake of > > > symmetry, we should introduce a CEProtocolLFB. > > > [Sure, why dont you start defining some of these > > > objects...then we can discuss more in detail] > > > > > > 6.6 State Maintenance: FE > > > Activate/Deactivate/Shutdown become settable > > > attributes in the FEProtocolLFB. [Yes, these > > > messages will be part of Events or Config...we need > > > to specify this] > > > > > > 6.7 HB remains as is. [Agreed] > > > > > > In summary, we have the following operations defined > > > for each message type ( I broke the table into 3 > > > parts): > > > [looks good!] > > > OPERATION APPLICABLE MESSAGE TYPES > > > > > > Assoc-Setup Assoc-Setup-Resp > > > Assoc-Teardown Heartbeat > > > > > > no operations > > > defined > > > > > > > > > Query Query-Resp Config > > > Config-Resp > > > SET, DEL, UPDATE x x > > > GET x x > > > EV_S, EV_U x x > > > > > > (for event subscribe/unsubscribe) > > > > > > > > > Packet-Redir > > > > > > PAYLOAD x > > > > > > > > > Event-Notif Event-Notif-Resp > > > EVENT x x > > > > > > Note that for Query(-Resp), Packet-Redir, and > > > Event-Notif(-Resp), we have each time only one > > > operation. Looks a bit redundant. Ideas ? [These > > > are all very different, lets leave them as is, its > > > not necessary to have multiple operations in all > > > messages] > > > > > > Regards, > > > -Robert > > > > > > > > > > > > > > > -- > > > Robert Haas > > > IBM Zurich Research Laboratory > > > Säumerstrasse 4 > > > CH-8803 Rüschlikon/Switzerland > > > phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha > > > > > > -- > > Robert Haas > > IBM Zurich Research Laboratory > > Säumerstrasse 4 > > CH-8803 Rüschlikon/Switzerland > > phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha > > > > > > ______________________________________________________________________ > > > > _______________________________________________ > > Forces-protocol mailing list > > Forces-protocol@ietf.org > > https://www1.ietf.org/mailman/listinfo/forces-protocol > > -------------------------------------------------------------------------------- > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 12:30:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18429 for ; Fri, 22 Oct 2004 12:30:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2WN-0001gD-85 for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 12:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2J1-0003Mk-Db; Fri, 22 Oct 2004 12:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2AY-0001EH-QP for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 12:21:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17776 for ; Fri, 22 Oct 2004 12:21:30 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2NL-0001Y2-Ol for forces-protocol@ietf.org; Fri, 22 Oct 2004 12:34:49 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9MGLV06028759; Fri, 22 Oct 2004 16:21:32 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9MGOJmf018207; Fri, 22 Oct 2004 16:24:31 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102209204703085 ; Fri, 22 Oct 2004 09:20:48 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 09:20:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Oct 2004 09:20:45 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02FD8F10@orsmsx408> Thread-Topic: Section 6 update Thread-Index: AcS4GjZ5rm0THe/cRAObkIUM36YDVgAOLwcQ From: "Khosravi, Hormuzd M" To: "Robert Haas" , "Wang,Weiming" X-OriginalArrivalTime: 22 Oct 2004 16:20:47.0131 (UTC) FILETIME=[166DD6B0:01C4B853] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.9 (/) X-Scan-Signature: 76fee95f697ac1bd4d0bfe58b40699d9 Cc: ram.gopal@nokia.com, avri@psg.com, hadi@znyx.com, Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] RE: Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1251629541==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 8a9672ae1970aa20cd94e880017fa9b4 This is a multi-part message in MIME format. --===============1251629541== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B853.15F32613" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B853.15F32613 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, having a new section for FE LFB, etc is a good idea. Also, we can have a new section for the protocol State Machine (after = Protocol Messages) =20 regards Hormuzd ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Friday, October 22, 2004 2:33 AM To: Wang,Weiming Cc: Khosravi, Hormuzd M; Ligang Dong; hadi@znyx.com; avri@psg.com; = ram.gopal@nokia.com; forces-protocol@ietf.org Subject: Re: Section 6 update Weiming. I suggest we make a new section "FE LFB and FE Protocol LFB" just = before Section 5 "Common Header", instead of leaving this to section = 3.3.2. This will reflect the importance of those two LFBs in the = operation of the protocol. I'll post my text when ready, please do the same, and we'll merge. -Robert Wang,Weiming wrote: Robert,=20 =20 Don't worry too much about the FE LFB and Protocol LFB, I think it can = be fit it well in the sections. =20 Actually I can do something for Protocol LFB and FE LFB if you think = possible. =20 Regards, Weiming =20 ----- Original Message -----=20 From: Khosravi, Hormuzd M =20 To: Robert Haas =20 Cc: Ligang Dong ; hadi@znyx.com ; = avri@psg.com ; ram.gopal@nokia.com ; Weiming Wang = ; forces-protocol@ietf.org=20 Sent: Friday, October 22, 2004 4:35 PM Subject: Section 6 update Hi Robert, All =20 Here you go...I have updated sections 6.1, 6.3, 6.6 (remove), 6.7 = (same). I have directly used the text that Jamal sent out wherever = applicable. You can update sections 6.2, 6.4, 6.5 -> however, I would check with = Weiming first as courtesy since he is working on these sections. =20 BTW, there were lots of things in the todo list I sent out... =20 Header Section - Jamal/Robert/Weiming? Protocol LFB - Robert/Others? FE LFB - Robert/Others? CE LFB - ? State Machine for Protocol - Ligang (taken) =20 Will you be working on any of these ?? =20 Pls do let us know...I will start working on whatever hasn't been = claimed by tomorrow morning my time. =20 Thanks Hormuzd =20 =09 ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Friday, October 22, 2004 12:39 AM To: Khosravi, Hormuzd M Cc: Ligang Dong; hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com; = Weiming Wang; forces-protocol@ietf.org Subject: Re: Applying changes to Section 6 (Protocol Messages) =20 Hormuzd, Could you please pass the token on section 6 together with your latest = version so I can start editing it ? Thanks, -Robert =09 Khosravi, Hormuzd M wrote: =09 =09 Robert, =20 As I said, your note mostly looks...I have put some more comments = below... (It would help a lot if you start defining the FE, Protocol LFBs...) =09 ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 =09 All: below is a rough list of changes and pending issues regarding = section 6. Please review. =09 6.1.1 Association: The CE could obtain the HBI with a = Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg = strcutrue, we have to remove HBI from the Assoc Setup msg. [Agreed, = this would be part of ProtocolLFB even if it is in this message]=20 =09 6.1.2 How has the srcID=3D0 case been handled in the interop tests ? = Is this really feasible ? [Yes it worked fine during Interop]=20 =09 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into = the FEProtocolLFB. [Agreed it would be in some LFB, but not sure which = LFB this would be part of...?]=20 =09 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note = that for the sake of symmetry, we should introduce a CEProtocolLFB. = [Sure, why dont you start defining some of these objects...then we can = discuss more in detail]=20 =09 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become = settable attributes in the FEProtocolLFB. [Yes, these messages will be = part of Events or Config...we need to specify this]=20 =09 6.7 HB remains as is. [Agreed]=20 =09 In summary, we have the following operations defined for each message = type ( I broke the table into 3 parts): [looks good!]=20 OPERATION APPLICABLE MESSAGE TYPES =09 Assoc-Setup Assoc-Setup-Resp Assoc-Teardown Heartbeat =09 no operations defined =09 =09 Query Query-Resp Config Config-Resp SET, DEL, UPDATE x x GET x x EV_S, EV_U x x =09 (for event subscribe/unsubscribe) =09 =09 Packet-Redir =09 PAYLOAD x =09 =09 Event-Notif Event-Notif-Resp EVENT x x =09 Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we = have each time only one operation. Looks a bit redundant. Ideas ? = [These are all very different, lets leave them as is, its not necessary = to have multiple operations in all messages]=20 =09 Regards, -Robert =09 =09 =09 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 = http://www.zurich.ibm.com/~rha =20 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha ------_=_NextPart_001_01C4B853.15F32613 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes, having a new section for FE LFB, etc is a = good=20 idea.
Also, we can have a new section for the = protocol State=20 Machine (after Protocol Messages)
 
regards
Hormuzd

From: Robert Haas = [mailto:rha@zurich.ibm.com]=20
Sent: Friday, October 22, 2004 2:33 AM
To:=20 Wang,Weiming
Cc: Khosravi, Hormuzd M; Ligang Dong; = hadi@znyx.com;=20 avri@psg.com; ram.gopal@nokia.com; = forces-protocol@ietf.org
Subject:=20 Re: Section 6 update

Weiming.
I suggest we make a  new section "FE LFB and = FE=20 Protocol LFB" just before Section 5 "Common Header", instead of leaving = this to=20 section 3.3.2. This will reflect the importance of those two LFBs in the = operation of the protocol.

I'll post my text when ready, please = do the=20 same, and we'll merge.

-Robert

Wang,Weiming wrote:
Robert,
 
Don't worry too much about the FE LFB = and=20 Protocol LFB, I think it can be fit it well in the = sections.
 
Actually I can do something for = Protocol LFB and=20 FE LFB if you think possible.
 
Regards,
Weiming
 
----- Original Message -----
From:=20 Khosravi, Hormuzd M = To:=20 Robert Haas=20 Cc:=20 Ligang Dong ; hadi@znyx.com ; avri@psg.com ; = ram.gopal@nokia.com ; Weiming=20 Wang ; forces-protocol@ietf.org = Sent:=20 Friday, October 22, 2004 4:35 PM Subject:=20 Section 6 update

Hi = Robert,=20 All

 

Here you = go=85I have=20 updated sections 6.1, 6.3, 6.6 (remove), 6.7 (same). I have directly = used=20 the text that Jamal sent out wherever applicable.

You can = update=20 sections 6.2, 6.4, 6.5 -> however, I would check with Weiming = first as=20 courtesy since he is working on these sections.

 

BTW, = there were=20 lots of things in the todo list I sent out=85

 

Header = Section -=20 Jamal/Robert/Weiming?

Protocol = LFB -=20 Robert/Others?

FE LFB -=20 Robert/Others?

CE LFB -=20 ?

State Machine for Protocol =96 Ligang=20 (taken)

 

Will you = be working=20 on any of these ??

 

Pls do = let us=20 know=85I will start working on whatever hasn=92t been claimed by = tomorrow=20 morning my time.

 

Thanks

Hormuzd

 

From: = Robert Haas=20 [mailto:rha@zurich.ibm.com] =
Sent: Friday, October 22, = 2004 12:39=20 AM
To: Khosravi, = Hormuzd=20 M
Cc: Ligang = Dong; hadi@znyx.com; avri@psg.com;=20 ram.gopal@nokia.com; Weiming = Wang; forces-protocol@ietf.org
= Subject: Re: Applying changes = to=20 Section 6 (Protocol Messages)

 

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

Khosravi, Hormuzd M=20 wrote:

Robert,

 

As I = said, your=20 note mostly looks...I have put some more comments = below...

(It would help a lot if you sta= rt defining the FE, Protocol LFBs...)

From:=20 Robert Haas [mailto:rha@zurich.ibm.com]=20


All: below is a rough list of changes = and=20 pending issues regarding section 6. Please = review.

 6.1.1=20 Association: The CE could obtain the HBI with a=20 Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg=20 strcutrue, we have to remove HBI from the Assoc Setup=20 msg.  = [Agreed,=20 this would be part of ProtocolLFB even if it is in this=20 message] 

 6.1.2 How has the = srcID=3D0 case=20 been handled in the interop tests ? Is this really feasible ?  = [Yes it=20 worked fine during Interop] 

 6.2 = Query:=20 coarse FE info (inter/intra-FE topology, etc) goes into the=20 FEProtocolLFB.  = [Agreed it=20 would be in some LFB, but not sure which LFB this would be part=20 of...?] 

 6.4: Events: coarse CE and = FE=20 events go into CE/FEProtocolLFB. Note that for the sake of symmetry, = we=20 should introduce a CEProtocolLFB.  = [Sure, why=20 dont you start defining some of these objects...then we can discuss = more in=20 detail] 

 6.6 State Maintenance: FE=20 Activate/Deactivate/Shutdown become settable attributes in the=20 FEProtocolLFB.  [Yes,=20 these messages will be part of Events or Config...we need to specify = this] 

 6.7 HB remains as is. =20 [Agreed] 

In summary, we have the = following=20 operations defined for each message type ( I broke the table into 3=20 parts):
 [looks=20 good!] 
OPERATION       = APPLICABLE=20 MESSAGE TYPES

          =   =20    Assoc-Setup  Assoc-Setup-Resp Assoc-Teardown=20 Heartbeat

no=20 operations
defined


          =   =20    Query  Query-Resp  Config =20 Config-Resp
SET, DEL, = UPDATE=20 =             &= nbsp;   =20    x          = x
GET           = ;   =20 x         = x
EV_S, EV_U=20 =             &= nbsp;       =20      = x         =20 x

(for event=20 subscribe/unsubscribe)


       =    =20      Packet-Redir

PAYLOAD          &= nbsp;=20 x


  =    =20           Event-Notif =20 Event-Notif-Resp
EVENT =  =20           =20 = x            =    =20 x

Note that for Query(-Resp), = Packet-Redir,=20 and Event-Notif(-Resp), we have each time only one operation. Looks = a bit=20 redundant. Ideas ?  = [These are=20 all very different, lets leave them as is, its not necessary to have = multiple operations in all=20 messages] 

Regards,
-Robert



-- 
Robert =
Haas
IBM Zurich Research =
Laboratory
S=E4umerstrasse =
4
CH-8803 =
R=FCschlikon/Switzerland
phone =
+41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha<=
/A>

--=20
Robert Haas
IBM Zurich Research Laboratory
S=E4umerstrasse 4
CH-8803 R=FCschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
------_=_NextPart_001_01C4B853.15F32613-- --===============1251629541== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1251629541==-- From forces-protocol-bounces@ietf.org Fri Oct 22 12:36:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18801 for ; Fri, 22 Oct 2004 12:35:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2bO-0001nc-Pg for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 12:49:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2MN-0005BF-Mg; Fri, 22 Oct 2004 12:33:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2Jd-0003wC-WA for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 12:30:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18454 for ; Fri, 22 Oct 2004 12:30:53 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2WR-0001g1-BG for forces-protocol@ietf.org; Fri, 22 Oct 2004 12:44:12 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9MGTwSA000614; Fri, 22 Oct 2004 16:29:58 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9MGXnmd024600; Fri, 22 Oct 2004 16:33:57 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102209300904655 ; Fri, 22 Oct 2004 09:30:10 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 09:30:07 -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 Subject: RE: [Forces-protocol] FE Protocol LFBs Date: Fri, 22 Oct 2004 09:30:06 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02FD8F49@orsmsx408> Thread-Topic: [Forces-protocol] FE Protocol LFBs Thread-Index: AcS4S/m2WaJB/ua7SxSyBzh9QQP2XQACDceA From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 22 Oct 2004 16:30:07.0998 (UTC) FILETIME=[64BB59E0:01C4B854] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: avri@psg.com, ram.gopal@nokia.com, Robert Haas , Ligang Dong , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Weiming, All=20 We should definitely define these LFBs related with FE, Protocol, etc as part of the protocol draft. There is no need to have them in a separate draft Regards Hormuzd -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn]=20 > > Also dont forget to look at the overview section in the latest draft > posted by Avri. Theres a little refinement of the split of the two LFBs > (each in its own section). > As to what to do about the FE Object and FE Protocol object, My opinion > is we should define everything taht we think we will need. > I would think the model team will take those needs and make sure its > part of the XML spec. Weiming, are you suggesting to do the xml from us? [Weiming] Yes, but I'm not sure if it should be defined inside this protocol text or just by another draft. I remember you also mentioned such thought before. We actually have the same question on Redirect LFBs, anyway any LFB like things that between FE model and protocol. Now it seems very popular to summarize everything as LFB, I even think of TML layer as LFBs from PL layer, but not sure. cheers, weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 12:39:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19040 for ; Fri, 22 Oct 2004 12:38:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2eI-0001rT-DB for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 12:52:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2MQ-0005CQ-8q; Fri, 22 Oct 2004 12:33:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2Lu-0004pI-Iu for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 12:33:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18670 for ; Fri, 22 Oct 2004 12:33:14 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2Yf-0001ir-59 for forces-protocol@ietf.org; Fri, 22 Oct 2004 12:46:33 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9MGVeBF451318; Fri, 22 Oct 2004 12:31:40 -0400 Received: from sihl.zurich.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9MGWpWr124508; Fri, 22 Oct 2004 12:32:52 -0400 Received: from [9.145.131.51] (sig-9-145-131-51.de.ibm.com [9.145.131.51]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id SAA74948; Fri, 22 Oct 2004 18:31:34 +0200 Message-ID: <417935D9.1080609@zurich.ibm.com> Date: Fri, 22 Oct 2004 18:31:21 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E02FD8F10@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02FD8F10@orsmsx408> X-Spam-Score: 0.9 (/) X-Scan-Signature: ce2737a971e141e0457c8c1bf182367f Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Ligang Dong Subject: [Forces-protocol] Re: Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1713044299==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: f45599941caef2d9ac4ed98df73589d5 This is a multi-part message in MIME format. --===============1713044299== Content-Type: multipart/alternative; boundary="------------010806080100010403050903" This is a multi-part message in MIME format. --------------010806080100010403050903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e2.ny.us.ibm.com id i9MGVeBF451318 Content-Transfer-Encoding: quoted-printable Hormuzd, Do you have the xml for the update you posted ? Thanks, -Robert Khosravi, Hormuzd M wrote: > Yes, having a new section for FE LFB, etc is a good idea. > Also, we can have a new section for the protocol State Machine (after=20 > Protocol Messages) > =20 > regards > Hormuzd > > -----------------------------------------------------------------------= - > From: Robert Haas [mailto:rha@zurich.ibm.com] > Sent: Friday, October 22, 2004 2:33 AM > To: Wang,Weiming > Cc: Khosravi, Hormuzd M; Ligang Dong; hadi@znyx.com; avri@psg.com;=20 > ram.gopal@nokia.com; forces-protocol@ietf.org > Subject: Re: Section 6 update > > Weiming. > I suggest we make a new section "FE LFB and FE Protocol LFB" just=20 > before Section 5 "Common Header", instead of leaving this to section=20 > 3.3.2. This will reflect the importance of those two LFBs in the=20 > operation of the protocol. > > I'll post my text when ready, please do the same, and we'll merge. > > -Robert > > Wang,Weiming wrote: > >> Robert, >> =20 >> Don't worry too much about the FE LFB and Protocol LFB, I think it=20 >> can be fit it well in the sections. >> =20 >> Actually I can do something for Protocol LFB and FE LFB if you think=20 >> possible. >> =20 >> Regards, >> Weiming >> =20 >> ----- Original Message ----- >> >> From: Khosravi, Hormuzd M >> To: Robert Haas >> Cc: Ligang Dong ; hadi@znyx.com >> ; avri@psg.com ; >> ram.gopal@nokia.com ; Weiming Wang >> ; forces-protocol@ietf.org >> >> Sent: Friday, October 22, 2004 4:35 PM >> Subject: Section 6 update >> >> Hi Robert, All >> >> =20 >> >> Here you go...I have updated sections 6.1, 6.3, 6.6 (remove), 6.7 >> (same). I have directly used the text that Jamal sent out >> wherever applicable. >> >> You can update sections 6.2, 6.4, 6.5 -> however, I would check >> with Weiming first as courtesy since he is working on these sectio= ns. >> >> =20 >> >> BTW, there were lots of things in the todo list I sent out... >> >> =20 >> >> Header Section - Jamal/Robert/Weiming? >> >> Protocol LFB - Robert/Others? >> >> FE LFB - Robert/Others? >> >> CE LFB - ? >> >> State Machine for Protocol - Ligang (taken) >> >> =20 >> >> Will you be working on any of these ?? >> >> =20 >> >> Pls do let us know...I will start working on whatever hasn't been >> claimed by tomorrow morning my time. >> >> =20 >> >> Thanks >> >> Hormuzd >> >> =20 >> >> ------------------------------------------------------------------= ------ >> >> From: Robert Haas [mailto:rha@zurich.ibm.com] >> Sent: Friday, October 22, 2004 12:39 AM >> To: Khosravi, Hormuzd M >> Cc: Ligang Dong; hadi@znyx.com; avri@psg.com; >> ram.gopal@nokia.com; Weiming Wang; forces-protocol@ietf.org >> Subject: Re: Applying changes to Section 6 (Protocol Messages) >> >> =20 >> >> Hormuzd, >> Could you please pass the token on section 6 together with your >> latest version so I can start editing it ? >> Thanks, >> -Robert >> >> Khosravi, Hormuzd M wrote: >> >> Robert, >> >> =20 >> >> As I said, your note mostly looks...I have put some more comments >> below... >> >> (It would help a lot if you start defining the FE, Protocol LFBs..= .) >> >> ------------------------------------------------------------------= ------ >> >> From: Robert Haas [mailto:rha@zurich.ibm.com] >> >> >> All: below is a rough list of changes and pending issues >> regarding section 6. Please review. >> >> 6.1.1 Association: The CE could obtain the HBI with a >> Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc >> msg strcutrue, we have to remove HBI from the Assoc Setup msg.=20 >> [Agreed, this would be part of ProtocolLFB even if it is in this >> message]=20 >> >> 6.1.2 How has the srcID=3D0 case been handled in the interop test= s >> ? Is this really feasible ? [Yes it worked fine during Interop]=20 >> >> 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes >> into the FEProtocolLFB. [Agreed it would be in some LFB, but not >> sure which LFB this would be part of...?]=20 >> >> 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. >> Note that for the sake of symmetry, we should introduce a >> CEProtocolLFB. [Sure, why dont you start defining some of these >> objects...then we can discuss more in detail]=20 >> >> 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become >> settable attributes in the FEProtocolLFB. [Yes, these messages >> will be part of Events or Config...we need to specify this]=20 >> >> 6.7 HB remains as is. [Agreed]=20 >> >> In summary, we have the following operations defined for each >> message type ( I broke the table into 3 parts): >> [looks good!]=20 >> OPERATION APPLICABLE MESSAGE TYPES >> >> Assoc-Setup Assoc-Setup-Resp Assoc-Teardown >> Heartbeat >> >> no operations >> defined >> >> >> Query Query-Resp Config Config-Resp >> SET, DEL, UPDATE x x >> GET x x >> EV_S, EV_U x x >> >> (for event subscribe/unsubscribe) >> >> >> Packet-Redir >> >> PAYLOAD x >> >> >> Event-Notif Event-Notif-Resp >> EVENT x x >> >> Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), >> we have each time only one operation. Looks a bit redundant. >> Ideas ? [These are all very different, lets leave them as is, >> its not necessary to have multiple operations in all messages]=20 >> >> Regards, >> -Robert >> >> >> >>--=20 >> >>Robert Haas >> >>IBM Zurich Research Laboratory >> >>S=E4umerstrasse 4 >> >>CH-8803 R=FCschlikon/Switzerland >> >>phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rh= a >> > >--=20 >Robert Haas >IBM Zurich Research Laboratory >S=E4umerstrasse 4 >CH-8803 R=FCschlikon/Switzerland >phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------010806080100010403050903 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hormuzd,
Do you have the xml for the update you posted ?
Thanks,
-Robert

Khosravi, Hormuzd M wrote:
Yes, having a new section for FE LFB, etc is a good idea.
Also, we can have a new section for the protocol State Machine (after Protocol Messages)
 
regards
Hormuzd

From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Friday, October 22, 2004 2:33 AM
To: Wang,Weiming
Cc: Khosravi, Hormuzd M; Ligang Dong; hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com; forces-protocol@ietf.org
Subject: Re: Section 6 update

Weiming.
I suggest we make a  new section "FE LFB and FE Protocol LFB" just before Section 5 "Common Header", instead of leaving this to section 3.3.2. This will reflect the importance of those two LFBs in the operation of the protocol.

I'll post my text when ready, please do the same, and we'll merge.

-Robert

Wang,Weiming wrote:
Robert,
 
Don't worry too much about the FE LFB and Protocol LFB, I think it can be fit it well in the sections.
 
Actually I can do something for Protocol LFB and FE LFB if you think possible.
 
Regards,
Weiming
 
----- Original Message -----
Sent: Friday, October 22, 2004 4:35 PM
Subject: Section 6 update

Hi Robert, All

 

Here you go…I have updated sections 6.1, 6.3, 6.6 (remove), 6.7 (same). I have directly used the text that Jamal sent out wherever applicable.

You can update sections 6.2, 6.4, 6.5 -> however, I would check with Weiming first as courtesy since he is working on these sections.

 

BTW, there were lots of things in the todo list I sent out…

 

Header Section - Jamal/Robert/Weiming?

Protocol LFB - Robert/Others?

FE LFB - Robert/Others?

CE LFB - ?

State Machine for Protocol – Ligang (taken)

 

Will you be working on any of these ??

 

Pls do let us know…I will start working on whatever hasn’t been claimed by tomorrow morning my time.

 

Thanks

Hormuzd

 

From: Robert Haas [mailto:rha@zurich.ibm.com]
Sent: Friday, October 22, 2004 12:39 AM
To: Khosravi, Hormuzd M
Cc: Ligang Dong; hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com; Weiming Wang; forces-protocol@ietf.org
Subject: Re: Applying changes to Section 6 (Protocol Messages)

 

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

Khosravi, Hormuzd M wrote:

Robert,

 

As I said, your note mostly looks...I have put some more comments below...

(It would help a lot if you start defining the FE, Protocol LFBs...)

From: Robert Haas [mailto:rha@zurich.ibm.com]


All: below is a rough list of changes and pending issues regarding section 6. Please review.

 6.1.1 Association: The CE could obtain the HBI with a Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg strcutrue, we have to remove HBI from the Assoc Setup msg.  [Agreed, this would be part of ProtocolLFB even if it is in this message] 

 6.1.2 How has the srcID=0 case been handled in the interop tests ? Is this really feasible ?  [Yes it worked fine during Interop] 

 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into the FEProtocolLFB.  [Agreed it would be in some LFB, but not sure which LFB this would be part of...?] 

 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note that for the sake of symmetry, we should introduce a CEProtocolLFB.  [Sure, why dont you start defining some of these objects...then we can discuss more in detail] 

 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become settable attributes in the FEProtocolLFB.  [Yes, these messages will be part of Events or Config...we need to specify this] 

 6.7 HB remains as is.  [Agreed] 

In summary, we have the following operations defined for each message type ( I broke the table into 3 parts):
 [looks good!] 
OPERATION       APPLICABLE MESSAGE TYPES

                Assoc-Setup  Assoc-Setup-Resp Assoc-Teardown Heartbeat

no operations
defined


                Query  Query-Resp  Config  Config-Resp
SET, DEL, UPDATE                     x          x
GET               x         x
EV_S, EV_U                           x          x

(for event subscribe/unsubscribe)


                Packet-Redir

PAYLOAD            x


                Event-Notif  Event-Notif-Resp
EVENT              x                x

Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we have each time only one operation. Looks a bit redundant. Ideas ?  [These are all very different, lets leave them as is, its not necessary to have multiple operations in all messages] 

Regards,
-Robert



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

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

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------010806080100010403050903-- --===============1713044299== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1713044299==-- From forces-protocol-bounces@ietf.org Fri Oct 22 12:44:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19373 for ; Fri, 22 Oct 2004 12:44:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2jG-0001xe-HQ for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 12:57:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2T1-0007Sp-EO; Fri, 22 Oct 2004 12:40:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2NN-0005S5-Fu for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 12:34:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18755 for ; Fri, 22 Oct 2004 12:34:45 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2aC-0001lo-4r for forces-protocol@ietf.org; Fri, 22 Oct 2004 12:48:04 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9MGXiSA002568; Fri, 22 Oct 2004 16:33:44 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9MGbcmf027553; Fri, 22 Oct 2004 16:37:41 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102209340205429 ; Fri, 22 Oct 2004 09:34:02 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 09:34:02 -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 Subject: [Forces-protocol] draft update ? Date: Fri, 22 Oct 2004 09:34:01 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02FD8F67@orsmsx408> Thread-Topic: [Forces-protocol] draft update ? Thread-Index: AcS4StUUdc4/6EamQr+NxuQkE9tM5gACZR+Q From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" X-OriginalArrivalTime: 22 Oct 2004 16:34:02.0292 (UTC) FILETIME=[F061C740:01C4B854] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Robert Haas , Ligang Dong , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Hi Avri, If you could incorporate the sections that Weiming and myself sent out into the draft and send us an update that would be great! It would be much easier to review the text after this. Thanks a lot, Hormuzd -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn]=20 Hi Avri, I'v updated the RedirectMsg, QueryMsg, and EventMsg as XML file in the attachments. It's a pity that I just find I can not pass to parse the file by xml2rfc because it included some of the format defined by you, therefore it seems I can not verify the correctness of the file for the xml format. I really want to save some of your work but it seems I'm not able to. If you like, next time I would just use txt like Hormuzd did. There is no change to the definition part. Hormuzd, I have mostly tried best to follow your format, but still there are some places that I prefer my style. Anyway, it matters less. thank you. Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 12:50:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19880 for ; Fri, 22 Oct 2004 12:50:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2p3-00024o-Ps for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 13:03:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2Vj-0008Cx-VQ; Fri, 22 Oct 2004 12:43:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2Qj-00066T-Hx for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 12:38:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18993 for ; Fri, 22 Oct 2004 12:38:13 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2dX-0001pP-Ex for forces-protocol@ietf.org; Fri, 22 Oct 2004 12:51:32 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9MGfSMH008631; Fri, 22 Oct 2004 16:41:28 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9MGfDmd030050; Fri, 22 Oct 2004 16:41:13 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102209373406009 ; Fri, 22 Oct 2004 09:37: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.0); Fri, 22 Oct 2004 09:37:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Oct 2004 09:37:32 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02FD8F7D@orsmsx408> Thread-Topic: Section 6 update Thread-Index: AcS4VKdBFHoPf2AyTkm5N40Sf9GzsQAAFJGQ From: "Khosravi, Hormuzd M" To: "Robert Haas" X-OriginalArrivalTime: 22 Oct 2004 16:37:34.0492 (UTC) FILETIME=[6EDCEDC0:01C4B855] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.9 (/) X-Scan-Signature: f1d8e5e632fcbbb13bf46ebb1d552b4e Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Ligang Dong Subject: [Forces-protocol] RE: Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1615662158==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 6e5958278d089090169a903f246b3f39 This is a multi-part message in MIME format. --===============1615662158== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B855.6E31CF77" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B855.6E31CF77 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No, I sent out the text directly. BTW, once Avri sends out an update I = can take care of making any more changes on section 6, if that is fine = with you. =20 Any update on the protocol LFBs ? Let me know if I should start of any = of the other sections, Header, State Machine ?? =20 Thanks All ! Hormuzd ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Friday, October 22, 2004 9:31 AM To: Khosravi, Hormuzd M Cc: Wang,Weiming; Ligang Dong; hadi@znyx.com; avri@psg.com; = ram.gopal@nokia.com; forces-protocol@ietf.org Subject: Re: Section 6 update Hormuzd, Do you have the xml for the update you posted ? Thanks, -Robert Khosravi, Hormuzd M wrote: Yes, having a new section for FE LFB, etc is a good idea. Also, we can have a new section for the protocol State Machine (after = Protocol Messages) =20 regards Hormuzd ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Friday, October 22, 2004 2:33 AM To: Wang,Weiming Cc: Khosravi, Hormuzd M; Ligang Dong; hadi@znyx.com; avri@psg.com; = ram.gopal@nokia.com; forces-protocol@ietf.org Subject: Re: Section 6 update =09 =09 Weiming. I suggest we make a new section "FE LFB and FE Protocol LFB" just = before Section 5 "Common Header", instead of leaving this to section = 3.3.2. This will reflect the importance of those two LFBs in the = operation of the protocol. =09 I'll post my text when ready, please do the same, and we'll merge. =09 -Robert =09 Wang,Weiming wrote: =09 Robert,=20 =20 Don't worry too much about the FE LFB and Protocol LFB, I think it can = be fit it well in the sections. =20 Actually I can do something for Protocol LFB and FE LFB if you think = possible. =20 Regards, Weiming =20 ----- Original Message -----=20 From: Khosravi, Hormuzd M =20 To: Robert Haas =20 Cc: Ligang Dong ; hadi@znyx.com ; = avri@psg.com ; ram.gopal@nokia.com ; Weiming Wang = ; forces-protocol@ietf.org=20 Sent: Friday, October 22, 2004 4:35 PM Subject: Section 6 update Hi Robert, All =20 Here you go...I have updated sections 6.1, 6.3, 6.6 (remove), 6.7 = (same). I have directly used the text that Jamal sent out wherever = applicable. You can update sections 6.2, 6.4, 6.5 -> however, I would check with = Weiming first as courtesy since he is working on these sections. =20 BTW, there were lots of things in the todo list I sent out... =20 Header Section - Jamal/Robert/Weiming? Protocol LFB - Robert/Others? FE LFB - Robert/Others? CE LFB - ? State Machine for Protocol - Ligang (taken) =20 Will you be working on any of these ?? =20 Pls do let us know...I will start working on whatever hasn't been = claimed by tomorrow morning my time. =20 Thanks Hormuzd =20 =09 ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Friday, October 22, 2004 12:39 AM To: Khosravi, Hormuzd M Cc: Ligang Dong; hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com; = Weiming Wang; forces-protocol@ietf.org Subject: Re: Applying changes to Section 6 (Protocol Messages) =20 Hormuzd, Could you please pass the token on section 6 together with your = latest version so I can start editing it ? Thanks, -Robert =09 Khosravi, Hormuzd M wrote: =09 =09 Robert, =20 As I said, your note mostly looks...I have put some more comments = below... (It would help a lot if you start defining the FE, Protocol LFBs...) =09 ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 =09 All: below is a rough list of changes and pending issues regarding = section 6. Please review. =09 6.1.1 Association: The CE could obtain the HBI with a = Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg = strcutrue, we have to remove HBI from the Assoc Setup msg. [Agreed, = this would be part of ProtocolLFB even if it is in this message]=20 =09 6.1.2 How has the srcID=3D0 case been handled in the interop tests ? = Is this really feasible ? [Yes it worked fine during Interop]=20 =09 6.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into = the FEProtocolLFB. [Agreed it would be in some LFB, but not sure which = LFB this would be part of...?]=20 =09 6.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note = that for the sake of symmetry, we should introduce a CEProtocolLFB. = [Sure, why dont you start defining some of these objects...then we can = discuss more in detail]=20 =09 6.6 State Maintenance: FE Activate/Deactivate/Shutdown become = settable attributes in the FEProtocolLFB. [Yes, these messages will be = part of Events or Config...we need to specify this]=20 =09 6.7 HB remains as is. [Agreed]=20 =09 In summary, we have the following operations defined for each message = type ( I broke the table into 3 parts): [looks good!]=20 OPERATION APPLICABLE MESSAGE TYPES =09 Assoc-Setup Assoc-Setup-Resp Assoc-Teardown = Heartbeat =09 no operations defined =09 =09 Query Query-Resp Config Config-Resp SET, DEL, UPDATE x x GET x x EV_S, EV_U x x =09 (for event subscribe/unsubscribe) =09 =09 Packet-Redir =09 PAYLOAD x =09 =09 Event-Notif Event-Notif-Resp EVENT x x =09 Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we = have each time only one operation. Looks a bit redundant. Ideas ? = [These are all very different, lets leave them as is, its not necessary = to have multiple operations in all messages]=20 =09 Regards, -Robert =09 =09 =09 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 = http://www.zurich.ibm.com/~rha =20 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 = http://www.zurich.ibm.com/~rha =20 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha ------_=_NextPart_001_01C4B855.6E31CF77 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
No, I sent out the text directly. BTW, once = Avri sends out=20 an update I can take care of making any more changes on section 6, if = that is=20 fine with you.
 
Any update on the protocol LFBs ? Let me know = if I should=20 start of any of the other sections, Header, State Machine = ??
 
Thanks All !
Hormuzd

From: Robert Haas = [mailto:rha@zurich.ibm.com]=20
Sent: Friday, October 22, 2004 9:31 AM
To: = Khosravi,=20 Hormuzd M
Cc: Wang,Weiming; Ligang Dong; hadi@znyx.com; = avri@psg.com;=20 ram.gopal@nokia.com; forces-protocol@ietf.org
Subject: Re: = Section 6=20 update

Hormuzd,
Do you have the xml for the update you posted=20 ?
Thanks,
-Robert

Khosravi, Hormuzd M wrote:
Yes, having a new section for FE LFB, etc is = a good=20 idea.
Also, we can have a new section for the = protocol State=20 Machine (after Protocol Messages)
 
regards
Hormuzd

From: Robert Haas [mailto:rha@zurich.ibm.com]=20
Sent: Friday, October 22, 2004 2:33 AM
To:=20 Wang,Weiming
Cc: Khosravi, Hormuzd M; Ligang Dong; hadi@znyx.com;=20 avri@psg.com;=20 ram.gopal@nokia.com; forces-protocol@ietf.org
= Subject:=20 Re: Section 6 update

Weiming.
I suggest we make = a =20 new section "FE LFB and FE Protocol LFB" just before Section 5 "Common = Header", instead of leaving this to section 3.3.2. This will reflect = the=20 importance of those two LFBs in the operation of the = protocol.

I'll=20 post my text when ready, please do the same, and we'll=20 merge.

-Robert

Wang,Weiming wrote:
Robert,
 
Don't worry too much about the FE = LFB and=20 Protocol LFB, I think it can be fit it well in the = sections.
 
Actually I can do something for = Protocol LFB=20 and FE LFB if you think possible.
 
Regards,
Weiming
 
----- Original Message -----
From:=20 Khosravi, Hormuzd = M To:=20 Robert=20 Haas Cc:=20 Ligang Dong ; hadi@znyx.com ; avri@psg.com = ; ram.gopal@nokia.com ; Weiming Wang ; forces-protocol@ietf.org = Sent:=20 Friday, October 22, 2004 4:35 PM Subject:=20 Section 6 update

Hi = Robert,=20 All

 

Here = you go=85I=20 have updated sections 6.1, 6.3, 6.6 (remove), 6.7 (same). I have = directly=20 used the text that Jamal sent out wherever = applicable.

You can = update=20 sections 6.2, 6.4, 6.5 -> however, I would check with Weiming = first as=20 courtesy since he is working on these sections.

 

BTW, = there were=20 lots of things in the todo list I sent out=85

 

Header = Section -=20 Jamal/Robert/Weiming?

Protocol LFB -=20 Robert/Others?

FE LFB = -=20 Robert/Others?

CE LFB = -=20 ?

State Machine for Protocol =96 Ligang=20 (taken)

 

Will = you be=20 working on any of these ??

 

Pls do = let us=20 know=85I will start working on whatever hasn=92t been claimed by = tomorrow=20 morning my time.

 

Thanks

Hormuzd

 

From: = Robert=20 Haas [mailto:rha@zurich.ibm.com]=20
Sent: Friday, = October=20 22, 2004 12:39 AM
To:=20 Khosravi, Hormuzd M
Cc:=20 Ligang Dong; hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com; = Weiming Wang;=20 forces-protocol@ietf.org
= Subject: Re: Applying = changes to=20 Section 6 (Protocol Messages)

 

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

Khosravi, Hormuzd M=20 wrote:

Robert,

 

As I = said, your=20 note mostly looks...I have put some more comments=20 below...

(It would help a lot if you sta= rt defining the FE, Protocol LFBs...)

From:=20 Robert Haas [mailto:rha@zurich.ibm.com]=20


All: below is a rough list of = changes and=20 pending issues regarding section 6. Please = review.

 6.1.1=20 Association: The CE could obtain the HBI with a=20 Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg = strcutrue, we have to remove HBI from the Assoc Setup=20 msg.  = [Agreed,=20 this would be part of ProtocolLFB even if it is in this=20 message] 

 6.1.2 How has the = srcID=3D0 case=20 been handled in the interop tests ? Is this really feasible ?  = [Yes it=20 worked fine during Interop] 

 6.2 = Query:=20 coarse FE info (inter/intra-FE topology, etc) goes into the=20 FEProtocolLFB.  = [Agreed it=20 would be in some LFB, but not sure which LFB this would be part=20 of...?] 

 6.4: Events: coarse CE = and FE=20 events go into CE/FEProtocolLFB. Note that for the sake of = symmetry, we=20 should introduce a CEProtocolLFB.  = [Sure, why=20 dont you start defining some of these objects...then we can = discuss more=20 in detail] 

 6.6 State Maintenance: = FE=20 Activate/Deactivate/Shutdown become settable attributes in the=20 FEProtocolLFB.  [Yes,=20 these messages will be part of Events or Config...we need to = specify=20 this] 

 6.7 HB remains as is. =20 [Agreed] 

In summary, we have the = following=20 operations defined for each message type ( I broke the table into = 3=20 parts):
 [looks=20 good!] 
OPERATION       = APPLICABLE MESSAGE TYPES

         =20       Assoc-Setup  Assoc-Setup-Resp=20 Assoc-Teardown Heartbeat

no operations
defined


         =20       Query  Query-Resp  = Config =20 Config-Resp
SET, = DEL, UPDATE=20 =             &= nbsp;   =20    = x         =20 x
GET           = ;   =20 x        =20 x
EV_S, EV_U=20 =             &= nbsp;       =20     =20 x         =20 x

(for event=20 subscribe/unsubscribe)


       =    =20      Packet-Redir

PAYLOAD          &= nbsp;=20 x


  =    =20           Event-Notif =20 Event-Notif-Resp
EVENT  =20           =20 = x            =    =20 x

Note that for Query(-Resp),=20 Packet-Redir, and Event-Notif(-Resp), we have each time only one=20 operation. Looks a bit redundant. Ideas ?  = [These are=20 all very different, lets leave them as is, its not necessary to = have=20 multiple operations in all=20 messages] 

Regards,
-Robert



-- 
Robert =
Haas
IBM Zurich Research =
Laboratory
S=E4umerstrasse =
4
CH-8803 =
R=FCschlikon/Switzerland
phone =
+41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha<=
/A>

--=20
Robert Haas
IBM Zurich Research Laboratory
S=E4umerstrasse 4
CH-8803 R=FCschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha<=
/A>

--=20
Robert Haas
IBM Zurich Research Laboratory
S=E4umerstrasse 4
CH-8803 R=FCschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
------_=_NextPart_001_01C4B855.6E31CF77-- --===============1615662158== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1615662158==-- From forces-protocol-bounces@ietf.org Fri Oct 22 13:08:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21095 for ; Fri, 22 Oct 2004 13:08:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL37I-0002NS-0O for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 13:22:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2p1-0006Pi-0Q; Fri, 22 Oct 2004 13:03:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL2hM-0003wZ-TC for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 12:55:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20214 for ; Fri, 22 Oct 2004 12:55:24 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL2uB-00029v-Df for forces-protocol@ietf.org; Fri, 22 Oct 2004 13:08:44 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102209575556:37793 ; Fri, 22 Oct 2004 09:57:55 -0700 From: Jamal Hadi Salim To: Robert Haas In-Reply-To: <4178D2A9.3040207@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E0257920D@orsmsx408> <4178D2A9.3040207@zurich.ibm.com> Organization: Znyx Networks Message-Id: <1098464119.1028.116.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Oct 2004 12:55:20 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/22/2004 09:57:56 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/22/2004 09:57:57 AM, Serialize complete at 10/22/2004 09:57:57 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Weiming Wang Subject: [Forces-protocol] Re: Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: 7bit On Fri, 2004-10-22 at 05:28, Robert Haas wrote: > > PL level PDU : = MAINHDR+ > > LFBselect := LFBCLASSID LFBInstance + > > OPER:= ]*>+ > > > > > I think we should now make our terminology consistent and use "FE LFB" > and "FE Protocol LFB" instead of Object or Managed Object. I know it > will make Weiming unhappy, but I find it less confusing. The reason is > that we treat regular LFBs and the FE Object and FE Protocol Object in > the same manner in the protocol ("Everything is an LFB"). I think we should use consitently the term FE object and FE Protocol object going forward. I think "Managed object" is generic enough and useful as well. It actually implies an attribute in my opinion. i.e something within an LFB that can be targeted by a path. > > main hdr (eg type = Association setup) > > | > > | > > +--- T = LFBselect > > | | > > | +-- LFBCLASSID = FE object > > | | > > | | > > | +-- LFBInstance = 0x1 > > | > > +--- T = FENAME > > | > > +-- "myname" > > > > > > > To me, FE Name is an attribute of the FE Protocol Object/LFB (not the > FE Object/LFB) that can be advertised by the FE. Agreed. Its an attribute within the FE object LFB. And for that reason the LFB selector should have a ADD operation with this attribute having a path. > Let's define a new "SHOW" operation for that purpose. > The message would therefore look like: > > > main hdr (eg type = Association setup) > | > | > +--- T = LFBselect > | > +-- LFBCLASSID = FE object > | > | > +-- LFBInstance = 0x1 > | > | > +-- T = operation SHOW > | > +-- FE NAME (path target) > > > What do you think ? A better name than "SHOW" ? > ADD? ;-> > > 6.3.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, LFB events. > > > > 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 > > 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 one or more TLVs, the format > > of the TLVs/message is as follows: > > > > > > main hdr (eg type = config) > > | > > | > > +--- T = LFBselect > > | | > > | +-- LFBCLASSID = target LFB class > > | | > > | | > > | +-- LFBInstance = target LFB instance > > | | > > | | > > | +-- T = operation { ADD, DEL, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > | +-- T = operation { ADD, DEL, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > | +-- T = operation { ADD, DEL, etc} > > | | | > > | | +-- // one or more path targets > > | | // under discussion > > | | > > > > > > 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 = LFB select | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | LFB Class ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | LFB Instance ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = Operations (ADD) | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Event Type | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Config data | > > . . > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = Operations (DEL) | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Event Type | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Config data | > > . . > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 16 > > > > Type (16 bits): > > LFB Select. > > Length (16 bits): > > Length of the TLV including the T and L fields, in bytes. > > LFB Class ID (16 bits): > > This field uniquely recognizes the LFB class/type. > > LFB Instance ID (16 bits): > > This field uniquely identifies the LFB instance. > > > > Type (16 bits): > > The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, SUBSCRIBE, > > UNSUBSCRIBE, CANCEL. The following Types are defined for this > > TLV: > > * Add, Del, Update, Del All, Cancel, Subscribe, Unsubscribe > > events > > Length (16 bits): > > Length of the TLV including the T and L fields, in bytes. > > Event Type (16 bits): > > For SUBSCRIBE, UNSUBSCRIBE Events Type TLVs, an Event Type field > > will define the Events of interest. Examples of Event Type > > include, All Events, FE Events, LFB Events, Packets, Packet > > Mirroring. > > > I am not comfortable with these Event Type flags that appear for every > operation (ADD, GET, DEL, etc) but are only used for EV_S and EV_U. > > I propose to do this differently: > > > main hdr (eg type = config) > | > | > +--- T = LFBselect > | | > | +-- LFBCLASSID = target LFB class > | | > | | > | +-- LFBInstance = target LFB instance > | | > | | > | +-- T = operation = EV_S > | | | > | | +-- // one or more path targets (i.e., events to subscribe) > | | // under discussion > And define the following attributes in their respective LFB/Objects: > - in each specific LFB (including the FE Object), an attribute for > each event it can fire, and possibly an attribute for "AllLFBEvents" > that can be subscribed to and corresponds to subscribing to all events > of that LFB (model team should look at this). > I don't know what a "Packets", or "Packet Mirroring" event corresponds > to. If this is a redirected packet, then we have already a special > message type for it. > I agree with you. Can we have a quick call to discuss just section 6? I hadnt paid attention to it before, but its one of the most important we have. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 13:45:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23958 for ; Fri, 22 Oct 2004 13:45:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3h5-00032o-OJ for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 13:59:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3QV-0001m8-LI; Fri, 22 Oct 2004 13:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3Lr-0008H4-9t for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 13:37:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23454 for ; Fri, 22 Oct 2004 13:37:16 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3Yf-0002uR-5Y for forces-protocol@ietf.org; Fri, 22 Oct 2004 13:50:34 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9MHCrep027294; Fri, 22 Oct 2004 19:12:54 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02FD8F7D@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02FD8F7D@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Oct 2004 13:37:08 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, hadi@znyx.com, Ligang Dong , Robert Haas Subject: [Forces-protocol] Re: Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Content-Transfer-Encoding: quoted-printable Am I supposed to integrate Hormuzd's Section 6 update and then Robert=20= will work on it? Or is Robert going take it and and then I will=20 integrate the reviewed/integrated Section 6? I was planning to do the later, but if necessary will do the=20 intermediate integration - i.e. will put the changes into XML. though=20= I may not get to it for a few hours yet. a. On 22 okt 2004, at 12.37, Khosravi, Hormuzd M wrote: > No, I sent out the text directly. BTW, once Avri sends out an update I=20= > can take care of making any more changes on section 6, if that is fine=20= > with you. > =A0 > Any update on the protocol LFBs ? Let me know if I should start of any=20= > of the other sections, Header, State Machine ?? > =A0 > Thanks All ! > Hormuzd > > > From: Robert Haas [mailto:rha@zurich.ibm.com] > Sent: Friday, October 22, 2004 9:31 AM > To: Khosravi, Hormuzd M > Cc: Wang,Weiming; Ligang Dong; hadi@znyx.com; avri@psg.com;=20 > ram.gopal@nokia.com; forces-protocol@ietf.org > Subject: Re: Section 6 update > > Hormuzd, > Do you have the xml for the update you posted ? > Thanks, > -Robert > > Khosravi, Hormuzd M wrote: > > Yes, having a new section for FE LFB, etc is a good idea. > Also, we can have a new section for the protocol State Machine (after=20= > Protocol Messages) > =A0 > regards > Hormuzd > > > From: Robert Haas [mailto:rha@zurich.ibm.com] > Sent: Friday, October 22, 2004 2:33 AM > To: Wang,Weiming > Cc: Khosravi, Hormuzd M; Ligang Dong; hadi@znyx.com; avri@psg.com;=20 > ram.gopal@nokia.com; forces-protocol@ietf.org > Subject: Re: Section 6 update > > Weiming. > I suggest we make a=A0 new section "FE LFB and FE Protocol LFB" just=20= > before Section 5 "Common Header", instead of leaving this to section=20= > 3.3.2. This will reflect the importance of those two LFBs in the=20 > operation of the protocol. > > I'll post my text when ready, please do the same, and we'll merge. > > -Robert > > Wang,Weiming wrote: > > Robert, > =A0 > Don't worry too much about the FE LFB and Protocol LFB, I think it can=20= > be fit it well in the sections. > =A0 > Actually I can do something for Protocol LFB and FE LFB if you think=20= > possible. > =A0 > Regards, > Weiming > =A0 > ----- Original Message ----- > From: Khosravi, Hormuzd M > To: Robert Haas > Cc: Ligang Dong ; hadi@znyx.com ; avri@psg.com ; ram.gopal@nokia.com ;=20= > Weiming Wang ; forces-protocol@ietf.org > Sent: Friday, October 22, 2004 4:35 PM > Subject: Section 6 update > > > Hi Robert, All > > =A0 > > Here you go=85I have updated sections 6.1, 6.3, 6.6 (remove), 6.7=20 > (same). I have directly used the text that Jamal sent out wherever=20 > applicable. > > You can update sections 6.2, 6.4, 6.5 -> however, I would check with=20= > Weiming first as courtesy since he is working on these sections. > > =A0 > > BTW, there were lots of things in the todo list I sent out=85 > > =A0 > > Header Section - Jamal/Robert/Weiming? > > Protocol LFB - Robert/Others? > > FE LFB - Robert/Others? > > CE LFB - ? > > State=A0Machine=A0for=A0Protocol=A0=96=A0Ligang (taken) > > =A0 > > Will you be working on any of these ?? > > =A0 > > Pls do let us know=85I will start working on whatever hasn=92t been=20 > claimed by tomorrow morning my time. > > =A0 > > Thanks > > Hormuzd > > =A0 > > > From: Robert Haas [mailto:rha@zurich.ibm.com] > Sent: Friday, October 22, 2004 12:39 AM > To: Khosravi, Hormuzd M > Cc: Ligang Dong; hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com;=20 > Weiming Wang; forces-protocol@ietf.org > Subject: Re: Applying changes to Section 6 (Protocol Messages) > > =A0 > > Hormuzd, > Could you please pass the token on section 6 together with your latest=20= > version so I can start editing it ? > Thanks, > -Robert > > Khosravi, Hormuzd M wrote: > > > Robert, > > =A0 > > As I said, your note mostly looks...I have put some more comments=20 > below... > > (It=A0would=A0help=A0a=A0lot=A0if=A0you=A0start=A0defining=A0the=A0FE,=A0= Protocol=A0LFBs...) > > > From: Robert Haas [mailto:rha@zurich.ibm.com] > > > All: below is a rough list of changes and pending issues regarding=20 > section 6. Please review. > > =A06.1.1 Association: The CE could obtain the HBI with a=20 > Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg=20 > strcutrue, we have to remove HBI from the Assoc Setup msg.=A0 [Agreed,=20= > this would be part of ProtocolLFB even if it is in this message]=A0 > > =A06.1.2 How has the srcID=3D0 case been handled in the interop tests = ? Is=20 > this really feasible ?=A0 [Yes it worked fine during Interop]=A0 > > =A06.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into=20= > the FEProtocolLFB.=A0 [Agreed it would be in some LFB, but not sure=20 > which LFB this would be part of...?]=A0 > > =A06.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note=20= > that for the sake of symmetry, we should introduce a CEProtocolLFB.=A0=20= > [Sure, why dont you start defining some of these objects...then we can=20= > discuss more in detail]=A0 > > =A06.6 State Maintenance: FE Activate/Deactivate/Shutdown become=20 > settable attributes in the FEProtocolLFB.=A0=A0[Yes, these messages = will=20 > be part of Events or Config...we need to specify this]=A0 > > =A06.7 HB remains as is.=A0 [Agreed]=A0 > > In summary, we have the following operations defined for each message=20= > type ( I broke the table into 3 parts): > =A0[looks good!]=A0 > OPERATION=A0=A0=A0=A0=A0=A0 APPLICABLE MESSAGE TYPES > > =A0=A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 Assoc-Setup=A0 Assoc-Setup-Resp = Assoc-Teardown Heartbeat > > no operations > defined > > > =A0=A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 Query=A0 Query-Resp=A0 Config=A0 = Config-Resp > SET, DEL, UPDATE =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0= x=A0=A0=A0=A0=A0=A0=A0=A0=A0 x > GET=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x=A0=A0=A0=A0=A0=A0=A0=A0 = x > EV_S, EV_U =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0 =A0=A0 x=A0=A0=A0=A0=A0=A0=A0=A0=A0 x > > (for event subscribe/unsubscribe) > > > =A0=A0=A0 =A0=A0 =A0=A0=A0 =A0=A0 =A0 Packet-Redir > > PAYLOAD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0 Event-Notif=A0 Event-Notif-Resp > EVENT =A0 =A0=A0 =A0=A0=A0=A0=A0=A0=A0 x=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 x > > Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we=20= > have each time only one operation. Looks a bit redundant. Ideas ?=A0=20= > [These are all very different, lets leave them as is, its not=20 > necessary to have multiple operations in all messages]=A0 > > Regards, > -Robert > > > > --=20 > Robert Haas > IBM Zurich Research Laboratory > S=E4umerstrasse 4 > CH-8803 R=FCschlikon/Switzerland > phone +41-1-724-8698=A0 fax +41-1-724-8578=A0=20 > http://www.zurich.ibm.com/~rha > > --=20 > Robert Haas > IBM Zurich Research Laboratory > S=E4umerstrasse 4 > CH-8803 R=FCschlikon/Switzerland > phone +41-1-724-8698 fax +41-1-724-8578 =20 > http://www.zurich.ibm.com/~rha > > --=20 > Robert Haas > IBM Zurich Research Laboratory > S=E4umerstrasse 4 > CH-8803 R=FCschlikon/Switzerland > phone +41-1-724-8698 fax +41-1-724-8578 =20 > http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 13:46:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24036 for ; Fri, 22 Oct 2004 13:46:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3hb-00033Y-Cj for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 13:59:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3Qt-0001tB-PD; Fri, 22 Oct 2004 13:42:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3N6-0008Kt-BC for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 13:38:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23524 for ; Fri, 22 Oct 2004 13:38:33 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3Zu-0002v3-VL for forces-protocol@ietf.org; Fri, 22 Oct 2004 13:51:51 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9MHcZ06006768; Fri, 22 Oct 2004 17:38:35 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9MHfOmh012259; Fri, 22 Oct 2004 17:41:34 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102210375417737 ; Fri, 22 Oct 2004 10:37:54 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 10:37:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 22 Oct 2004 10:37:52 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02FD9153@orsmsx408> Thread-Topic: Section 6 update Thread-Index: AcS4GYOzVwGfXU4lSPq2AyjIZy+LwQAQovpw From: "Khosravi, Hormuzd M" To: "Robert Haas" X-OriginalArrivalTime: 22 Oct 2004 17:37:53.0808 (UTC) FILETIME=[DC24B900:01C4B85D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 1.5 (+) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Weiming Wang Subject: [Forces-protocol] RE: Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0695607498==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 1.5 (+) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd This is a multi-part message in MIME format. --===============0695607498== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B85D.DB8570F1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B85D.DB8570F1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Robert, =20 Thanks for your comments below. I am mostly fine with them, will incorporate the changes in the text. BTW, any status update from you ? Should I assume you are not working on Section 6 at the moment ? =20 Pls see a few of my comments/clarifications below... =20 regards Hormuzd ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 =20 I think we should now make our terminology consistent and use "FE LFB" and "FE Protocol LFB" instead of Object or Managed Object. I know it will make Weiming unhappy, but I find it less confusing. The reason is that we treat regular LFBs and the FE Object and FE Protocol Object in the same manner in the protocol ("Everything is an LFB"). [HK] I am fine with whatever terminology you guys decide, as long as it is consistent in the draft. LFB is definitely cleaner, so I agree.=20 6.1.1 Association Setup Message To me, FE Name is an attribute of the FE Protocol Object/LFB (not the FE Object/LFB) that can be advertised by the FE. Let's define a new "SHOW" operation for that purpose. [Do we need to have an Operation ? If yes then SHOW is fine by me]=20 The message would therefore look like: main hdr (eg type =3D Association setup) | | +--- T =3D LFBselect | +-- LFBCLASSID =3D FE object | | +-- LFBInstance =3D 0x1 | | +-- T =3D operation SHOW | +-- FE NAME (path target) What do you think ? A better name than "SHOW" ? [Fine by me if we need an Operation]=20 6.3 Configuration Messages =20 6.3.1 Config Message Event Type (16 bits): For SUBSCRIBE, UNSUBSCRIBE Events Type TLVs, an Event Type field will define the Events of interest. Examples of Event Type include, All Events, FE Events, LFB Events, Packets, Packet Mirroring. I am not comfortable with these Event Type flags that appear for every operation (ADD, GET, DEL, etc) but are only used for EV_S and EV_U. I propose to do this differently: [Ok, I'll make this change]=20 main hdr (eg type =3D config) | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D target LFB class | | | | | +-- LFBInstance =3D target LFB instance=20 | | | | | +-- T =3D operation =3D EV_S | | | | | +-- // one or more path targets (i.e., events to subscribe)=20 | | // under discussion And define the following attributes in their respective LFB/Objects: - in each specific LFB (including the FE Object), an attribute for each event it can fire, and possibly an attribute for "AllLFBEvents" that can be subscribed to and corresponds to subscribing to all events of that LFB (model team should look at this). I don't know what a "Packets", or "Packet Mirroring" event corresponds to. If this is a redirected packet, then we have already a special message type for it. [HK] We need some way to Subscribe, Unsubscribe for Packets...so I decided to put it here...however based on your comment I think it would be cleaner to define 2 more operations PACKET SUBSCRIBE, PACKET UNSUBSCRIBE...let me know what you think ? 6.3.2 Config Response Message=20 But you have multiple overall results in the same config message. This should be fixed. [The overall results are per operation, I think I will change the terminology]=20 ------_=_NextPart_001_01C4B85D.DB8570F1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Robert,
 
Thanks for your comments below. I am mostly = fine with them,=20 will incorporate the changes in the text. BTW, any status update from = you=20 ?
Should=20 I assume you are not working on Section 6 at the moment = ?
 
Pls=20 see a few of my comments/clarifications below...
 
regards
Hormuzd
From: Robert Haas = [mailto:rha@zurich.ibm.com]=20
 
 I think we should now = make our=20 terminology consistent and use "FE LFB" and "FE Protocol LFB" instead of = Object=20 or Managed Object. I know it will make Weiming unhappy, but I find it = less=20 confusing. The reason is that we treat regular LFBs and the FE Object = and FE=20 Protocol Object in the same manner in the protocol ("Everything is an=20 LFB").
 [HK] I am fine with whatever terminology you guys decide, = as long=20 as it is consistent in the draft. LFB is definitely cleaner, so I=20 agree. 

6.1.1  Association Setup=20 Message

To me, FE Name is an attribute of the FE Protocol = Object/LFB (not=20 the FE Object/LFB) that can be advertised by the FE. Let's define a new = "SHOW"=20 operation for that purpose.  [Do we need to have an Operation ? If = yes then SHOW=20 is fine by me] 

The message would therefore = look=20 like:

main hdr (eg type =3D  Association=20 setup)
     |
    =20 |
     +--- T =3D=20 LFBselect
          =    =20 |
           &n= bsp; =20 +-- LFBCLASSID =3D FE=20 object
          &nb= sp;  =20 |
           &n= bsp; =20 |
           &n= bsp; =20 +-- LFBInstance =3D=20 0x1
           =   =20 |
           &n= bsp; =20 |
           &n= bsp; =20 +-- T =3D operation=20 SHOW
           = ;      =20 |
           &n= bsp;     =20 +-- FE NAME (path target)

What do you think ? A better name than = "SHOW"=20 ?       [Fine by me if we need an=20 Operation] 

6.3  Configuration=20 Messages
  
6.3.1  Config=20 Message

      Event Type (16=20 bits):
       For SUBSCRIBE, = UNSUBSCRIBE Events=20 Type TLVs, an Event Type field
       = will=20 define the Events of interest.  Examples of Event=20 Type
       include, All Events, FE = Events, LFB=20 Events, Packets, Packet
      =20 Mirroring.
  I am not comfortable with these Event Type flags = that=20 appear for every operation (ADD, GET, DEL, etc) but are only used for = EV_S and=20 EV_U.

I propose to do this differently:  [Ok, I'll=20 make this change] 

main hdr (eg type =3D=20 config)
     |
    =20 |
     +--- T =3D = LFBselect
    =20 |        = |
    =20 |        +-- LFBCLASSID =3D target = LFB=20 class
     = |       =20 |
     = |       =20 |
     = |        +--=20 LFBInstance =3D target LFB instance
    =20 |        = |
    =20 |        = |
    =20 |        +-- T =3D operation =3D=20 EV_S
     = |       =20 |   |
    =20 |        |   +--  // = one or=20 more path targets (i.e., events to subscribe) =
    =20 |       =20 |        // under = discussion

And=20 define the following attributes in their respective = LFB/Objects:
 - in=20 each specific LFB (including the FE Object), an attribute for each event = it can=20 fire, and possibly an attribute for "AllLFBEvents" that can be = subscribed to and=20 corresponds to subscribing to all events of that LFB (model team should = look at=20 this).
I don't know what a "Packets", or "Packet Mirroring" event = corresponds=20 to. If this is a redirected packet, then we have already a special = message type=20 for it.
 [HK] We need some way to Subscribe, Unsubscribe for = Packets...so I=20 decided to put it here...however based on your comment I think it = would be=20 cleaner to define 2 more operations PACKET SUBSCRIBE, PACKET = UNSUBSCRIBE...let=20 me know what you think ?
 6.3.2  Config Response Message 
But you have multiple =
overall results in the same config message. This should be =
fixed.
 [The overall results are per operation, I =
think I will change the =
terminology] 
------_=_NextPart_001_01C4B85D.DB8570F1-- --===============0695607498== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0695607498==-- From forces-protocol-bounces@ietf.org Fri Oct 22 14:03:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25220 for ; Fri, 22 Oct 2004 14:03:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3yK-0003O0-Gp for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 14:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3gY-0006Hn-By; Fri, 22 Oct 2004 13:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3ZA-0004cX-6Z for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 13:51:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24427 for ; Fri, 22 Oct 2004 13:51:01 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL3ly-00039J-Uw for forces-protocol@ietf.org; Fri, 22 Oct 2004 14:04:19 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9MHsMMH019975; Fri, 22 Oct 2004 17:54:22 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9MHqJnp022975; Fri, 22 Oct 2004 17:54:07 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102210502719889 ; Fri, 22 Oct 2004 10:50:27 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 10:50:27 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Oct 2004 10:50:26 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02FD91BE@orsmsx408> Thread-Topic: Section 6 update Thread-Index: AcS4XedxzyC0RNATQbmZZ3ci7I/CqAAAXCOg From: "Khosravi, Hormuzd M" To: , "Robert Haas" X-OriginalArrivalTime: 22 Oct 2004 17:50:27.0418 (UTC) FILETIME=[9D547BA0:01C4B85F] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, hadi@znyx.com, Ligang Dong , "Wang, Weiming" , forces-protocol@ietf.org Subject: [Forces-protocol] RE: Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Content-Transfer-Encoding: quoted-printable I think it would help in terms of readability to put in changes from = both Weiming and myself. I have sent an email to Robert to clarify his status as well...in any = case I will be making a few updates to section 6 to incorporate Robert's = comments. Thanks Avri, Hormuzd=20 -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 Sent: Friday, October 22, 2004 10:37 AM To: Khosravi, Hormuzd M Cc: hadi@znyx.com; Wang,Weiming; Ligang Dong; Robert Haas; = forces-protocol@ietf.org; ram.gopal@nokia.com Subject: Re: Section 6 update Am I supposed to integrate Hormuzd's Section 6 update and then Robert=20 will work on it? Or is Robert going take it and and then I will=20 integrate the reviewed/integrated Section 6? I was planning to do the later, but if necessary will do the=20 intermediate integration - i.e. will put the changes into XML. though=20 I may not get to it for a few hours yet. a. On 22 okt 2004, at 12.37, Khosravi, Hormuzd M wrote: > No, I sent out the text directly. BTW, once Avri sends out an update I = > can take care of making any more changes on section 6, if that is fine = > with you. > =A0 > Any update on the protocol LFBs ? Let me know if I should start of any = > of the other sections, Header, State Machine ?? > =A0 > Thanks All ! > Hormuzd > > > From: Robert Haas [mailto:rha@zurich.ibm.com] > Sent: Friday, October 22, 2004 9:31 AM > To: Khosravi, Hormuzd M > Cc: Wang,Weiming; Ligang Dong; hadi@znyx.com; avri@psg.com;=20 > ram.gopal@nokia.com; forces-protocol@ietf.org > Subject: Re: Section 6 update > > Hormuzd, > Do you have the xml for the update you posted ? > Thanks, > -Robert > > Khosravi, Hormuzd M wrote: > > Yes, having a new section for FE LFB, etc is a good idea. > Also, we can have a new section for the protocol State Machine (after=20 > Protocol Messages) > =A0 > regards > Hormuzd > > > From: Robert Haas [mailto:rha@zurich.ibm.com] > Sent: Friday, October 22, 2004 2:33 AM > To: Wang,Weiming > Cc: Khosravi, Hormuzd M; Ligang Dong; hadi@znyx.com; avri@psg.com;=20 > ram.gopal@nokia.com; forces-protocol@ietf.org > Subject: Re: Section 6 update > > Weiming. > I suggest we make a=A0 new section "FE LFB and FE Protocol LFB" just=20 > before Section 5 "Common Header", instead of leaving this to section=20 > 3.3.2. This will reflect the importance of those two LFBs in the=20 > operation of the protocol. > > I'll post my text when ready, please do the same, and we'll merge. > > -Robert > > Wang,Weiming wrote: > > Robert, > =A0 > Don't worry too much about the FE LFB and Protocol LFB, I think it can = > be fit it well in the sections. > =A0 > Actually I can do something for Protocol LFB and FE LFB if you think=20 > possible. > =A0 > Regards, > Weiming > =A0 > ----- Original Message ----- > From: Khosravi, Hormuzd M > To: Robert Haas > Cc: Ligang Dong ; hadi@znyx.com ; avri@psg.com ; ram.gopal@nokia.com ; = > Weiming Wang ; forces-protocol@ietf.org > Sent: Friday, October 22, 2004 4:35 PM > Subject: Section 6 update > > > Hi Robert, All > > =A0 > > Here you go...I have updated sections 6.1, 6.3, 6.6 (remove), 6.7=20 > (same). I have directly used the text that Jamal sent out wherever=20 > applicable. > > You can update sections 6.2, 6.4, 6.5 -> however, I would check with=20 > Weiming first as courtesy since he is working on these sections. > > =A0 > > BTW, there were lots of things in the todo list I sent out... > > =A0 > > Header Section - Jamal/Robert/Weiming? > > Protocol LFB - Robert/Others? > > FE LFB - Robert/Others? > > CE LFB - ? > > State=A0Machine=A0for=A0Protocol=A0-=A0Ligang (taken) > > =A0 > > Will you be working on any of these ?? > > =A0 > > Pls do let us know...I will start working on whatever hasn't been=20 > claimed by tomorrow morning my time. > > =A0 > > Thanks > > Hormuzd > > =A0 > > > From: Robert Haas [mailto:rha@zurich.ibm.com] > Sent: Friday, October 22, 2004 12:39 AM > To: Khosravi, Hormuzd M > Cc: Ligang Dong; hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com;=20 > Weiming Wang; forces-protocol@ietf.org > Subject: Re: Applying changes to Section 6 (Protocol Messages) > > =A0 > > Hormuzd, > Could you please pass the token on section 6 together with your latest = > version so I can start editing it ? > Thanks, > -Robert > > Khosravi, Hormuzd M wrote: > > > Robert, > > =A0 > > As I said, your note mostly looks...I have put some more comments=20 > below... > > = (It=A0would=A0help=A0a=A0lot=A0if=A0you=A0start=A0defining=A0the=A0FE,=A0= Protocol=A0LFBs...) > > > From: Robert Haas [mailto:rha@zurich.ibm.com] > > > All: below is a rough list of changes and pending issues regarding=20 > section 6. Please review. > > =A06.1.1 Association: The CE could obtain the HBI with a=20 > Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg=20 > strcutrue, we have to remove HBI from the Assoc Setup msg.=A0 [Agreed, = > this would be part of ProtocolLFB even if it is in this message]=A0 > > =A06.1.2 How has the srcID=3D0 case been handled in the interop tests = ? Is=20 > this really feasible ?=A0 [Yes it worked fine during Interop]=A0 > > =A06.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into=20 > the FEProtocolLFB.=A0 [Agreed it would be in some LFB, but not sure=20 > which LFB this would be part of...?]=A0 > > =A06.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. Note = > that for the sake of symmetry, we should introduce a CEProtocolLFB.=A0 = > [Sure, why dont you start defining some of these objects...then we can = > discuss more in detail]=A0 > > =A06.6 State Maintenance: FE Activate/Deactivate/Shutdown become=20 > settable attributes in the FEProtocolLFB.=A0=A0[Yes, these messages = will=20 > be part of Events or Config...we need to specify this]=A0 > > =A06.7 HB remains as is.=A0 [Agreed]=A0 > > In summary, we have the following operations defined for each message=20 > type ( I broke the table into 3 parts): > =A0[looks good!]=A0 > OPERATION=A0=A0=A0=A0=A0=A0 APPLICABLE MESSAGE TYPES > > =A0=A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 Assoc-Setup=A0 Assoc-Setup-Resp = Assoc-Teardown Heartbeat > > no operations > defined > > > =A0=A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 Query=A0 Query-Resp=A0 Config=A0 = Config-Resp > SET, DEL, UPDATE =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0=A0 x=A0=A0=A0=A0=A0=A0=A0=A0=A0 x > GET=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = x=A0=A0=A0=A0=A0=A0=A0=A0 x > EV_S, EV_U = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 =A0=A0 = x=A0=A0=A0=A0=A0=A0=A0=A0=A0 x > > (for event subscribe/unsubscribe) > > > =A0=A0=A0 =A0=A0 =A0=A0=A0 =A0=A0 =A0 Packet-Redir > > PAYLOAD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0 Event-Notif=A0 Event-Notif-Resp > EVENT =A0 =A0=A0 =A0=A0=A0=A0=A0=A0=A0 = x=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x > > Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we=20 > have each time only one operation. Looks a bit redundant. Ideas ?=A0=20 > [These are all very different, lets leave them as is, its not=20 > necessary to have multiple operations in all messages]=A0 > > Regards, > -Robert > > > > --=20 > Robert Haas > IBM Zurich Research Laboratory > S=E4umerstrasse 4 > CH-8803 R=FCschlikon/Switzerland > phone +41-1-724-8698=A0 fax +41-1-724-8578=A0=20 > http://www.zurich.ibm.com/~rha > > --=20 > Robert Haas > IBM Zurich Research Laboratory > S=E4umerstrasse 4 > CH-8803 R=FCschlikon/Switzerland > phone +41-1-724-8698 fax +41-1-724-8578 =20 > http://www.zurich.ibm.com/~rha > > --=20 > Robert Haas > IBM Zurich Research Laboratory > S=E4umerstrasse 4 > CH-8803 R=FCschlikon/Switzerland > phone +41-1-724-8698 fax +41-1-724-8578 =20 > http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 14:27:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26897 for ; Fri, 22 Oct 2004 14:27:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4LQ-0003no-LZ for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 14:40:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL45i-0005kj-SX; Fri, 22 Oct 2004 14:24:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL43O-0004uS-UT for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 14:22:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26632 for ; Fri, 22 Oct 2004 14:22:15 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4GD-0003iq-VR for forces-protocol@ietf.org; Fri, 22 Oct 2004 14:35:34 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9MHvtep027401; Fri, 22 Oct 2004 19:57:56 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02FD91BE@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02FD91BE@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <49B7F78C-2457-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Oct 2004 14:22:10 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, hadi@znyx.com, Ligang Dong , Robert Haas Subject: [Forces-protocol] Re: Section 6 update X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Content-Transfer-Encoding: quoted-printable ok, so once i get a section 6 from you that says - insert this - i will=20= do the xml edit and will make that available to Robert - should he want=20= it. it would help, however, if you can send a diff between the 01-1 i sent=20= out and what you do. but if you are unable to do that, i will do it=20 myself. a. On 22 okt 2004, at 13.50, Khosravi, Hormuzd M wrote: > I think it would help in terms of readability to put in changes from=20= > both Weiming and myself. > I have sent an email to Robert to clarify his status as well...in any=20= > case I will be making a few updates to section 6 to incorporate=20 > Robert's comments. > > Thanks Avri, > Hormuzd > > -----Original Message----- > From: avri@psg.com [mailto:avri@psg.com] > Sent: Friday, October 22, 2004 10:37 AM > To: Khosravi, Hormuzd M > Cc: hadi@znyx.com; Wang,Weiming; Ligang Dong; Robert Haas;=20 > forces-protocol@ietf.org; ram.gopal@nokia.com > Subject: Re: Section 6 update > > Am I supposed to integrate Hormuzd's Section 6 update and then Robert > will work on it? Or is Robert going take it and and then I will > integrate the reviewed/integrated Section 6? > > I was planning to do the later, but if necessary will do the > intermediate integration - i.e. will put the changes into XML. though > I may not get to it for a few hours yet. > > a. > > On 22 okt 2004, at 12.37, Khosravi, Hormuzd M wrote: > >> No, I sent out the text directly. BTW, once Avri sends out an update = I >> can take care of making any more changes on section 6, if that is = fine >> with you. >> =A0 >> Any update on the protocol LFBs ? Let me know if I should start of = any >> of the other sections, Header, State Machine ?? >> =A0 >> Thanks All ! >> Hormuzd >> >> >> From: Robert Haas [mailto:rha@zurich.ibm.com] >> Sent: Friday, October 22, 2004 9:31 AM >> To: Khosravi, Hormuzd M >> Cc: Wang,Weiming; Ligang Dong; hadi@znyx.com; avri@psg.com; >> ram.gopal@nokia.com; forces-protocol@ietf.org >> Subject: Re: Section 6 update >> >> Hormuzd, >> Do you have the xml for the update you posted ? >> Thanks, >> -Robert >> >> Khosravi, Hormuzd M wrote: >> >> Yes, having a new section for FE LFB, etc is a good idea. >> Also, we can have a new section for the protocol State Machine (after >> Protocol Messages) >> =A0 >> regards >> Hormuzd >> >> >> From: Robert Haas [mailto:rha@zurich.ibm.com] >> Sent: Friday, October 22, 2004 2:33 AM >> To: Wang,Weiming >> Cc: Khosravi, Hormuzd M; Ligang Dong; hadi@znyx.com; avri@psg.com; >> ram.gopal@nokia.com; forces-protocol@ietf.org >> Subject: Re: Section 6 update >> >> Weiming. >> I suggest we make a=A0 new section "FE LFB and FE Protocol LFB" just >> before Section 5 "Common Header", instead of leaving this to section >> 3.3.2. This will reflect the importance of those two LFBs in the >> operation of the protocol. >> >> I'll post my text when ready, please do the same, and we'll merge. >> >> -Robert >> >> Wang,Weiming wrote: >> >> Robert, >> =A0 >> Don't worry too much about the FE LFB and Protocol LFB, I think it = can >> be fit it well in the sections. >> =A0 >> Actually I can do something for Protocol LFB and FE LFB if you think >> possible. >> =A0 >> Regards, >> Weiming >> =A0 >> ----- Original Message ----- >> From: Khosravi, Hormuzd M >> To: Robert Haas >> Cc: Ligang Dong ; hadi@znyx.com ; avri@psg.com ; ram.gopal@nokia.com = ; >> Weiming Wang ; forces-protocol@ietf.org >> Sent: Friday, October 22, 2004 4:35 PM >> Subject: Section 6 update >> >> >> Hi Robert, All >> >> =A0 >> >> Here you go...I have updated sections 6.1, 6.3, 6.6 (remove), 6.7 >> (same). I have directly used the text that Jamal sent out wherever >> applicable. >> >> You can update sections 6.2, 6.4, 6.5 -> however, I would check with >> Weiming first as courtesy since he is working on these sections. >> >> =A0 >> >> BTW, there were lots of things in the todo list I sent out... >> >> =A0 >> >> Header Section - Jamal/Robert/Weiming? >> >> Protocol LFB - Robert/Others? >> >> FE LFB - Robert/Others? >> >> CE LFB - ? >> >> State=A0Machine=A0for=A0Protocol=A0-=A0Ligang (taken) >> >> =A0 >> >> Will you be working on any of these ?? >> >> =A0 >> >> Pls do let us know...I will start working on whatever hasn't been >> claimed by tomorrow morning my time. >> >> =A0 >> >> Thanks >> >> Hormuzd >> >> =A0 >> >> >> From: Robert Haas [mailto:rha@zurich.ibm.com] >> Sent: Friday, October 22, 2004 12:39 AM >> To: Khosravi, Hormuzd M >> Cc: Ligang Dong; hadi@znyx.com; avri@psg.com; ram.gopal@nokia.com; >> Weiming Wang; forces-protocol@ietf.org >> Subject: Re: Applying changes to Section 6 (Protocol Messages) >> >> =A0 >> >> Hormuzd, >> Could you please pass the token on section 6 together with your = latest >> version so I can start editing it ? >> Thanks, >> -Robert >> >> Khosravi, Hormuzd M wrote: >> >> >> Robert, >> >> =A0 >> >> As I said, your note mostly looks...I have put some more comments >> below... >> >> (It=A0would=A0help=A0a=A0lot=A0if=A0you=A0start=A0defining=A0the=A0FE,=A0= Protocol=A0LFBs...) >> >> >> From: Robert Haas [mailto:rha@zurich.ibm.com] >> >> >> All: below is a rough list of changes and pending issues regarding >> section 6. Please review. >> >> =A06.1.1 Association: The CE could obtain the HBI with a >> Query-SGT-FEProtocolLFP-HeartbeatInterval. Given the new Assoc msg >> strcutrue, we have to remove HBI from the Assoc Setup msg.=A0 = [Agreed, >> this would be part of ProtocolLFB even if it is in this message]=A0 >> >> =A06.1.2 How has the srcID=3D0 case been handled in the interop tests = ? Is >> this really feasible ?=A0 [Yes it worked fine during Interop]=A0 >> >> =A06.2 Query: coarse FE info (inter/intra-FE topology, etc) goes into >> the FEProtocolLFB.=A0 [Agreed it would be in some LFB, but not sure >> which LFB this would be part of...?]=A0 >> >> =A06.4: Events: coarse CE and FE events go into CE/FEProtocolLFB. = Note >> that for the sake of symmetry, we should introduce a CEProtocolLFB.=A0 >> [Sure, why dont you start defining some of these objects...then we = can >> discuss more in detail]=A0 >> >> =A06.6 State Maintenance: FE Activate/Deactivate/Shutdown become >> settable attributes in the FEProtocolLFB.=A0=A0[Yes, these messages = will >> be part of Events or Config...we need to specify this]=A0 >> >> =A06.7 HB remains as is.=A0 [Agreed]=A0 >> >> In summary, we have the following operations defined for each message >> type ( I broke the table into 3 parts): >> =A0[looks good!]=A0 >> OPERATION=A0=A0=A0=A0=A0=A0 APPLICABLE MESSAGE TYPES >> >> =A0=A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 Assoc-Setup=A0 Assoc-Setup-Resp = Assoc-Teardown Heartbeat >> >> no operations >> defined >> >> >> =A0=A0=A0 =A0=A0 =A0=A0 =A0=A0 =A0=A0 Query=A0 Query-Resp=A0 Config=A0 = Config-Resp >> SET, DEL, UPDATE =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0= x=A0=A0=A0=A0=A0=A0=A0=A0=A0 x >> GET=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x=A0=A0=A0=A0=A0=A0=A0=A0= x >> EV_S, EV_U =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 =A0=A0 x=A0=A0=A0=A0=A0=A0=A0=A0=A0 x >> >> (for event subscribe/unsubscribe) >> >> >> =A0=A0=A0 =A0=A0 =A0=A0=A0 =A0=A0 =A0 Packet-Redir >> >> PAYLOAD=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 x >> >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0 Event-Notif=A0 Event-Notif-Resp >> EVENT =A0 =A0=A0 =A0=A0=A0=A0=A0=A0=A0 x=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 x >> >> Note that for Query(-Resp), Packet-Redir, and Event-Notif(-Resp), we >> have each time only one operation. Looks a bit redundant. Ideas ?=A0 >> [These are all very different, lets leave them as is, its not >> necessary to have multiple operations in all messages]=A0 >> >> Regards, >> -Robert >> >> >> >> --=20 >> Robert Haas >> IBM Zurich Research Laboratory >> S=E4umerstrasse 4 >> CH-8803 R=FCschlikon/Switzerland >> phone +41-1-724-8698=A0 fax +41-1-724-8578=A0 >> http://www.zurich.ibm.com/~rha >> >> --=20 >> Robert Haas >> IBM Zurich Research Laboratory >> S=E4umerstrasse 4 >> CH-8803 R=FCschlikon/Switzerland >> phone +41-1-724-8698 fax +41-1-724-8578 >> http://www.zurich.ibm.com/~rha >> >> --=20 >> Robert Haas >> IBM Zurich Research Laboratory >> S=E4umerstrasse 4 >> CH-8803 R=FCschlikon/Switzerland >> phone +41-1-724-8698 fax +41-1-724-8578 >> http://www.zurich.ibm.com/~rha > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 15:08:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00132 for ; Fri, 22 Oct 2004 15:08:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4zN-0004YN-DL for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 15:22:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4bh-0007YG-7a; Fri, 22 Oct 2004 14:57:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4ZV-0006dH-30 for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 14:55:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29233 for ; Fri, 22 Oct 2004 14:55:25 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4mH-0004Ko-Dc for forces-protocol@ietf.org; Fri, 22 Oct 2004 15:08:44 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9MIsmEx541266 for ; Fri, 22 Oct 2004 14:54:48 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9MIsmxd344276 for ; Fri, 22 Oct 2004 12:54:48 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9MIsmOK012441 for ; Fri, 22 Oct 2004 12:54:48 -0600 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9MIsgIk012198; Fri, 22 Oct 2004 12:54:43 -0600 Received: from [9.146.219.255] (sig-9-146-219-255.de.ibm.com [9.146.219.255]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id UAA85988; Fri, 22 Oct 2004 20:53:35 +0200 Message-ID: <4179571E.2080400@zurich.ibm.com> Date: Fri, 22 Oct 2004 20:53:18 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wang,Weiming" Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt References: <468F3FDA28AA87429AD807992E22D07E02579209@orsmsx408> <420441FF-23F7-11D9-9DB1-000393CC2112@acm.org> <108701c4b84a$8028ba60$845c21d2@Necom.hzic.edu.cn> In-Reply-To: <108701c4b84a$8028ba60$845c21d2@Necom.hzic.edu.cn> X-Spam-Score: 0.5 (/) X-Scan-Signature: 2bd911cf113edd7639f45f953ff6603f Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, avri@acm.org, forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0316602311==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 1444cbbac440967c96d8c0108a543a24 This is a multi-part message in MIME format. --===============0316602311== Content-Type: multipart/alternative; boundary="------------040902070701020604030008" This is a multi-part message in MIME format. --------------040902070701020604030008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id i9MIsmEx541266 Content-Transfer-Encoding: quoted-printable Weiming, I have a few suggestions for your sections. See inline. Please review=20 them and indicate to Avri if she should incorporate these into the final=20 draft. It would be good if Avri could do the english-check on these=20 sections to as I am not a native english speaker neither Regards, -Robert Wang,Weiming wrote: >Hi Avri, > >I'v updated the RedirectMsg, QueryMsg, and EventMsg as XML file in the >attachments. It's a pity that I just find I can not pass to parse the fi= le by >xml2rfc because it included some of the format defined by you, therefore= it >seems I can not verify the correctness of the file for the xml format. = I really >want to save some of your work but it seems I'm not able to. If you like= , next >time I would just use txt like Hormuzd did. > >There is no change to the definition part. > >Hormuzd, I have mostly tried best to follow your format, but still there= are >some places that I prefer my style. Anyway, it matters less. > >thank you. >Weiming >----- Original Message ----- >From: > =20 > >>On 22 okt 2004, at 02.19, Khosravi, Hormuzd M wrote: >> >> =20 >> >>>I sent you the entire section so you can just put it in. You don't hav= e >>>to find any diffs. I have attached it again for your convenience. >>> =20 >>> >>doesn't quite work like that. >>but i have put in the changes as far as i can tell. check to make sure >>i got it right. >> >>http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-1.txt >> >> =20 >> >>>BTW, where are you at this moment? in the US or Europe? Just curious i= n >>>case we need to setup some conference calls. >>> =20 >>> >>this week in the us - east coast. >> >>a. >> >> =20 >> > > > =20 > > > > >
> >Packet redirect message is used to transfer data packets=20 > between CE and FE. Usually these data packets are IP packets,=20 > though they may sometimes associated with some metadata=20 > generated by other LFBs in the model, or they may=20 > occasionally be other protocol packets, which usually happen=20 > when CE and FE are jointly implementing some high-touch=20 > operations. Packets redirected from FE to CE are the data=20 > packets that come from forwarding plane, and usually are the=20 > data packets that need high-touch operations in CE. > ... or packets for which the IP destination address is the NE. [Note=20 that I distinguish high-touch operations from endpoint protocol processin= g] > Packets=20 > redirected from CE to FE are the data packets that are=20 > generated by CE and are decided by CE to put into forwarding=20 > plane in FE. > > =20 > don't write "generated by the CE". Such packets could very well be=20 packets that initially were redirected from an FE. Instead, just say=20 "come from the CE". >By properly configuring related LFBs in FE, a packet can also=20 > be mirrored to CE instead of purely redirected to CE, i.e.,=20 > the packet is duplicated and one is redirected to CE and the=20 > other continues its way in the LFB topology. > > =20 > Side note: we will have to define how the packet header only can be=20 passed to the CE, and leave the payload in the FE, until the CE decides=20 what to do with the packet. Second side note: we need to specify why we consider that=20 packet_redirect deserves its own message type, and not simply be treated=20 as an event fired by the Redirect LFB that contains, as part of the=20 event data, the packet itself. My thinking is that using a specific=20 message type is important to let the CE distinguish promptly if the=20 message is an FE-internal event or an external packet that was just=20 forwarded. Something like this should be written in the intro of this=20 section. Weiming ? > > >=20 >There are also discussions on how LFBs in FE model that are=20 > related to packet redirect operations should be defined. Although=20 > it is out of the scope of forces protocol, how to define the LFBs=20 > affect the Packet Redirect Message described here. Because currently > it is still in progress in FE model on how to define such LFBs,=20 > we try to post some thoughts on this here for discussion. They=20 > will be removed later along with the progress of the FE model work. > > > >To define LFBs called 'RedirectSink' and 'RedirectTap' for >packet redirect. >An LFB in FE called 'RedirectSink' is responsible to collect=20 > data packets that need to be redirected to CE. From the=20 > perspective of the FE LFB topology, the 'RedirectSink' LFB=20 > is an LFB with only one input port and without any output=20 > port, and the input port can then be connected to any other=20 > LFB in FE model by means of a datapath in the forwarding=20 > plane. From the perspective of the ForCES protocol layer,=20 > the 'RedirectSink' LFB will generate the Packet Redirect=20 > Messages when it receives data packets from forwarding plane. > > >An LFB in FE called 'RedirectTap' is responsible to receive=20 > data packets that are redirected from CE. From the perspective=20 > of the FE LFB topology, the 'RedirectTap' LFB is an LFB with=20 > only one output port and without any input port, and the=20 > output port can then be connected to any other LFB in FE=20 > model by means of a datapath in the forwarding plane. From=20 > the perspective of ForCES protocol layer, the 'RedirectTap'=20 > LFB can receive the Packet Redirect Messages from CE, and=20 > un-encapsulate the data packets from the message and put=20 > them to datapaths in the forwarding plane. Actually the=20 > 'RecirectTap' LFB acts more like a transcoder that transfers=20 > the ForCES protocol messages to normal data packets in IP=20 > forwarding plane. As a result, if we need to have redirected=20 > packets connected to some LFB (say a Scheduler) in FE model,=20 > we only need to connect the 'RedirectTap LFB to the Scheduler=20 > LFB directly via a datapath as follows: > >
> +-----------------+ +-----------+ > | RedirectTap LFB |------>| | > +-----------------+ | | > | Scheduler | > From other LFB ---->| LFB | > | | > +-----------+ >
> > >By use of several 'RedirectSink' LFBs and several 'RedirectTap'=20 > LFBs that connect to several different datapaths in FE=20 > forwarding plane, multiple packet redirect paths between=20 > CE and FE can be constructed. > > > There might be another way a packet could be redirected: > directly by a forwarding path, e.g., by FPGA/ASIC/NP microcode. In=20 > such a case we do not need to put in a lot of smartness. Probably=20 > a link layer or even network level header is enough. The receiver=20 > demuxes it only based on some protocol type in the link layer or=20 > network transport layer. The pros for this appraoch is it may=20 > provide a fast and cost-effective path for packet redirect. The=20 > cons for this is it may more or less confuses the Fp reference=20 > point definition in ForCES framework.=20 > > > >We describe the Packet Redirect Message data format in details=20 > as follows: > > >CE to FE or FE to CE > > > > >The Message Type in the header is set to=20 > MessageType=3D 'PacketRedirect'. The ACK flags in the header=20 > SHOULD be set 'NoACK', meaning no response is expected by this=20 > message. If the ACK flag is set other values, the=20 > meanings will be ignored. > > > > >Consists of one or more TLVs, with every TLV having the=20 > following data format: > > > =20 > >
> > 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operatioin TLV | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operatioin TLV | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 >
> > >There are only two possible LFB classes here, the=20 > 'RedirectSink' LFB or the 'RedirectTap' LFB. If the message is=20 > from FE to CE, the LFB class should be 'RedirectSink'. If the=20 > message is from CE to FE, the LFB class should be 'RedirectTap'. > > > =20 > Why restrict this ? If any other LFB wants to generate a packet redirect=20 to the CE, let him do it ! > >Instance ID for the 'RedirectSink' LFB or 'RedirectTap' LFB. > > > > >This is a TLV describing one packet of data to be directed=20 > via the specified LFB above. The order of the data number is=20 > also the order the data packet arrives the redirector LFB, that=20 > is, the Redirected Data #1 should arrive earlier than the=20 > Redirected Data #2 in this redirector LFB. The TLV format is=20 > as follows: > > =20 > If what you mean is sequencing the redirected packet then I think it is=20 dangerous. Assume you use UDP to transport the redirected packets from=20 the CE to the FE. If one is lost, then what will the FE do with the next=20 ones ? > >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D Operations (PAYLOAD)| Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path(or Sequence Number?) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ Redirected Data ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >
> >[Under discussion and TBD] > > >[TBD] > > > >This field will make a detailed description of the data to=20 > be redirected as well as the data itself. The encoding of the=20 > description is based on the ForCES FE model if the redirector=20 > LFB is defined by FE model, or based on vendor specifications=20 > if the redirector LFB is defined by vendors. The description=20 > will usually include the name (or the name ID) of the redirected=20 > packet data (such as 'IPv4 Packet', 'IPv6 Packet'), and the=20 > packet data itself. It may also include some metadata (metadata=20 > name (or name ID) and its value)associated with the redirected=20 > data packet. > > >
> > > =20 > > > > >
> =20 > Be more specific: "Query and Query Response Messages" >The ForCES query and response messages are used for one ForCES=20 > element (CE or FE) to query other ForCES element(s) for various=20 > kinds of information. Current version of ForCES protocol limits=20 > the use of the messages only for CE to query information of FE.=20 > >
> >As usual, a query message is composed of a common header and=20 > a message body that consists of one or more TLV data format.=20 > Detailed description of the message is as below. > > > >Current version limits the query message transfer direction=20 > only from CE to FE. > > >The Message Type in the header is set to MessageType=3D 'Query'.=20 > The ACK flag in the header SHOULD be set 'ACKAll', meaning a=20 > full response for a query message is always expected. If the=20 > ACK flag is set other values, the meaning of the=20 > flag will then be ignored, and a full response will still be=20 > returned by message receiver. > > > >The query message body consists of (at least) one or more than=20 > one TLVs that describe entries to be queried. The TLV is called=20 > LFBselect TLV and the data format is as below: > >
> >=20 > 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 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operatioin TLV | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operatioin TLV | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > Typo in all figures: correct "Operatioin TLV" General comment: in many cases the same type in TLV is used in different=20 PL messages (Query vs Response, etc) and then the V is different. This=20 WILL be a big source of implementation bugs. I think we should defined=20 operation TLVs differently: GET and GET-RESP, SET and SET-RESP, REPORT=20 and REPORT-RESP. What do you think ? > =20 > >
> > > > > >Under discussion is whether there is a need for explicit multiple LFB= insatance > addressing here. One way to realize it is to define a specific Insta= nce select > TLV to substitute above 'LFB Instance ID' field. The TLV may have fo= llowing format: >
> INSselectTLV :=3D Type Length Value > Type :=3D INSselect > Value :=3D InstanceID (RangeMark | Instance ID)+ > >
>An applicable RangeMark is '0xffffffff', the value of which is the sa= me as=20 > Instance broadcast ID. Because there will be no broadcast address ap= plied > in this place, there will be no worry of ambiguity here. > =20 > > > >The Operation TLV for the 'Query' message is formatted as: > >
> =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D Operations (GET) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path(or Attribute ID?) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Query Data | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > =20 > Again, in all your sections, could you change "Type =3D Operations (GET)"= =20 to "Type =3D GET" and so on ? >
> >[Under discussion and TBD] > > > > >=20 >There is a debate on whether we should use a 'Path' or simply an 'Attrib= ute ID'=20 > or a 'Table ID' here at the protocol layer. A Path is used for data=20 > indexing for a table, while an 'Attribute ID' or a 'Table ID' only s= pecify=20 > which attribute or table to use, leaving table index to be included = in followed=20 > data. > > > > > [Under discussion and TBD] > > >To better understand the above PDU format, we can show a tree structu= re for the=20 > format as below: >
>main hdr (type =3D Query) > | > | > +--- T =3D LFBselect > | | > | +-- LFBCLASSID =3D target LFB class > | | > | | > | +-- LFBInstance =3D target LFB instance=20 > | | > | | > | +-- T =3D operation { GET } > | | | > | | +-- // one or more path targets=20 > | | // under discussion > | +-- T =3D operation { GET } > | | | > | | +-- // one or more path targets=20 > | |=20 > >
>
> >
>When receiving a query message, the receiver should process the=20 > message and come up with a query result. The receiver sends the=20 > query result back to the message sender by use of the Query=20 > Response Message. The query result can be the information=20 > being queried if the query operation is successful, or can also=20 > be error codes if the query operation fails, indicating the=20 > reasons for the failure. > >A query response message is also composed of a common header and=20 > a message body consists of one or more TLVs describing the query=20 > result. Detailed description of the message is as below. > > > >Current version limits the query response message transfer direction=20 > only from FE to CE. > > =20 > >The Message Type in the header is set to MessageType=3D 'QueryResponse'.= =20 > The ACK flag in the header SHOULD be set 'NoACK', meaning no further= =20 > response for a query response message is expected. If the ACK flag i= s=20 > set other values, the meaning of the flag will then be=20 > ignored. The Sequence Number in the header SHOULD keep the same as=20 > that of the query message to be responded, so that the query message= =20 > sender can keep track of the responses.=20 > > =20 > >The message body for a query response message consists of (at least)=20 > one or more than one TLVs that describe query results for individual= =20 > queried entries. The TLV is also called LFBselect TLV, and has exact= ly=20 > the same data format as query message, except the Operation TLV insi= de > the TLV comprises the 'Query Response Data', instead of the 'Query D= ata', > as below: > > >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D Operations (GET) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path(or Attribute ID?) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Query Response Data | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >
> =20 > You should specify here that the order of the TLV in the Query-Reponse=20 matches the TLVs in the Query. So there is always the same number of=20 TLVs in the response as in the query. Side note: we have not yet resolved the use of a transaction or sequence=20 number that will be used for each PL message. >=20 > >[Under discussion and TBD] > > > =20 >
>
> > > =20 > > > > >
> >The Event Notification Message is used for one ForCES element=20 > to asynchronously notify one or more other ForCES elements=20 > in the same ForCES NE on just happened events in it. The=20 > Event Notification Response Message is used for the receiver=20 > of the Event Notification Message to acknowledge the reception=20 > of the event notification. > >Events in current ForCES protocol can be categorized into following t= ypes: > >Events happened in CE >Events happened in FE > =20 > Why does this matter for the protocol ? > > >Events can also be categorized into two classes according to=20 > whether they need subscription or not. An event in one ForCES=20 > element that needs to be subscribed will send notifications to=20 > other ForCES elements only when the other elements have subscribed=20 > to the element for the event notification. How to=20 > subscribe/unsubscribe for an event is described in the Configure=20 > Message in Section 6.3. An event that needs not to be subscribed=20 > will always send notifications to other ForCES elements when the=20 > event happens. An event definition made by ForCES protocol, ForCES=20 > FE model, or by vendors will state if the event needs subscription o= r not. > > > >There is an argument that it is preferable to have=20 >all events subscribable. > > > > >
> >As usual, an Event Notification Message is composed of a common=20 > header and a message body that consists of one or more TLV data=20 > format. Detailed description of the message is as below. > > >FE to CE, or CE to FE > > > > >The Message Type in the message header is set to > MessageType =3D 'EventNotification'. The ACK flag in the header=20 > can be set as: ACK flag =3D'NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKA= ll'.=20 > Note that the 'Success' here only means the receiver of the message=20 > has successfully received the message. > > > > >The message body for an event notification message consists=20 > of (at least) one or more than one TLVs that describe the=20 > notified events. The TLV is defined 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 LFBselect | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Class ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | LFB Instance ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operatioin TLV | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ ... ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Operatioin TLV | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >
> > >This is a TLV that describes the event to be notified, as follows: > > >
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D Operations (REPORT) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path(or Event ID?) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Event Data | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >
> >[Under discussion and TBD] > > > > [Under discussion and TBD] > > >To better understand the above PDU format, we can show a tree structu= re for the=20 > format as below: >
>main hdr (type =3D Event Notification) > | > | > +--- T =3D LFBselect > | | > | +-- LFBCLASSID =3D target LFB class > | | > | | > | +-- LFBInstance =3D target LFB instance=20 > | | > | | > | +-- T =3D operation { REPORT } > | | | > | | +-- // one or more path targets=20 > | | // under discussion > | +-- T =3D operation { REPORT } > | | | > | | +-- // one or more path targets=20 > | |=20 > >
> >
> >
> >After sending out an Event Notification Message, the sender may=20 > be interested in ensuring that the message has been received=20 > by receivers, especially when the sender thinks the event=20 > notification is vital for system management. An Event=20 > Notification Response Message is used for this purpose. The=20 > ACK flag in the Event Notification Message header are used to=20 > signal if such acknowledge is requested or not by the sender.=20 > >Detailed description of the message is as below: > > >From FE to CE or from CE to FE, just inverse to the=20 > direction of the Event Notification Message that it responses. > > > > >The Message Type in the header is set=20 > MessageType=3D 'EventNotificationResponse'. The ACK flag in the=20 > header SHOULD be set 'NoACK', meaning no further response for=20 > the message is expected. If the ACK flag is set other values,=20 > the meaning of the flag will then be ignored.=20 > The Sequence Number in the header SHOULD keep the same as that=20 > of the message to be responded, so that the event notificatin=20 > message sender can keep track of the responses. > > > >The message body for an event notification message consists=20 > =20 > correct above: event notification "response" message > of (at least) one or more than one TLVs that describe the=20 > notified events. The TLV is also called LFBselect TLV, and has exact= ly=20 > the same data format as Event Notification Message, except the Opera= tion=20 > TLV inside the TLV comprises the event response data, instead of the= =20 > 'Event Data', as below: > =20 > Again, you should mention that the each "Operation TLV" in the response=20 corresponds one-to-one to a TLV in the notification. > > >
> >This contains a TLV that describe the response result=20 > as below: > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type =3D Operations (REPORT) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path(or Event ID?) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Result | Reason | Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >
> >[Under discussion and TBD] > > >This describes the reception result of the event notification=20 > message as below: > >
> Result Value Meaning > 'Success' The event has been successfully received. > 'Unsuccess' The event has not been successfully received. >
> > >This describes the reason and possible error code when=20 > the message is not successfully received. Note that only the=20 > failure at the protocol layer rather than the transport layer=20 > can be allocated here, > typo: not "allocated" but "handled". > that is, if even the header part of the=20 > message to be responded can not be correctly received, the=20 > response to the message will not be able to be generated by=20 > the receiver. > > > >=20 >There is a debate on whether the Event Notification=20 > Response Message is necessary or not. The pro for it is some event=20 > notification senders may be interested in knowing if receivers=20 > have had success/unsuccess receptions of the events or not. An=20 > alternative to generate such response is for the protocol to=20 > define a universal ACK message so that it can act as responses=20 > for any types of messages as well as the event notification=20 > messages, when the message senders are interested in knowing=20 > whether the messages have been successfully received or not=20 > (different from the responses for the message processing results). >=20 > > >
>
> > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------040902070701020604030008 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Weiming,
I have a few suggestions for your sections. See inline. Please review them and indicate to Avri if she should incorporate these into the final draft. It would be good if Avri could do the english-check on these sections to as I am not a native english speaker neither
Regards,
-Robert

Wang,Weiming wrote:
Hi Avri,

I'v updated the RedirectMsg, QueryMsg, and EventMsg as XML file in the
attachments. It's a pity that I just find I can not pass to parse the file by
xml2rfc because it included some of the format defined by you, therefore it
seems I can not verify the correctness of the  file for the xml format. I really
want to save some of your work but it seems I'm not able to. If you like, next
time I would just use txt like Hormuzd did.

There is no change to the definition part.

Hormuzd, I have mostly tried best to follow your format, but still there are
some places that I prefer my style. Anyway, it matters less.

thank you.
Weiming
----- Original Message -----
From: <avri@acm.org>
  
On 22 okt 2004, at 02.19, Khosravi, Hormuzd M wrote:

    
I sent you the entire section so you can just put it in. You don't have
to find any diffs. I have attached it again for your convenience.
      
doesn't quite work like that.
but i have put in the changes as far as i can tell. check to make sure
i got it right.

http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-1.txt

    
BTW, where are you at this moment? in the US or Europe? Just curious in
case we need to setup some conference calls.
      
this week in the us - east coast.

a.

    


  
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with <OXygen/>XML editor 4.1, by Weiming Wang & Ligang Dong 
     *** RedirectMsg V1.0, 2004-06-13, changes since last version:
     - None, as the original version.
     *** RedirectMsgV1.1, 2004-06-18.
-->

<section anchor="RedirectMsg" title="Packet Redirect Message">

<t>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. [Note that I distinguish high-touch operations from endpoint protocol processing]
 Packets 
    redirected from CE to FE are the data packets that are 
    generated by CE and are decided by CE to put into forwarding 
    plane in FE.</t>
don't write "generated by the CE". Such packets could very well be packets that initially were redirected from an FE. Instead, just say "come from the CE".
<t>By properly configuring related LFBs in FE, a packet can also 
    be 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. </t>
Side note: we will have to define how the packet header only can be passed to the CE, and leave the payload in the FE, until the CE decides what to do with the packet.

Second side note: we need to specify why we consider that packet_redirect deserves its own message type, and not simply be treated as an event fired by the Redirect LFB that contains, as part of the event data, the packet itself. My thinking is that using a specific message type is important to let the CE distinguish promptly if the message is an FE-internal event or an external packet that was just forwarded. Something like this should be written in the intro of this section. Weiming ?
<vspace blankLines="1" />
<list style="hanging" hangIndent="17">
<t hangText = "Editorial Note: "> 
There are also discussions on how LFBs in FE model that are 
    related to packet redirect operations should be defined. Although 
    it is out of the scope of forces protocol, how to define the LFBs 
    affect the Packet Redirect Message described here. Because currently
    it is still in progress in FE model on how to define such LFBs, 
    we try to post some thoughts on this here for discussion. They 
    will be removed later along with the progress of the FE model work.
</t>
<vspace blankLines="1" />
<t hangText ="     Thought 1: ">
To define LFBs called 'RedirectSink' and 'RedirectTap' for
packet redirect.</t>
<t>An LFB in FE called 'RedirectSink' is responsible to collect 
    data packets that need to be redirected to CE. From the 
    perspective of the FE LFB topology, the 'RedirectSink' LFB 
    is an LFB with only one input port and without any output 
    port, and the input port can then be connected to any other 
    LFB in FE model by means of a datapath in the forwarding 
    plane. From the perspective of the ForCES protocol layer, 
    the 'RedirectSink' LFB will generate the Packet Redirect 
    Messages when it receives data packets from forwarding plane.
</t>
<vspace blankLines="1" />
<t>An LFB in FE called 'RedirectTap' is responsible to receive 
    data packets that are redirected from CE. From the perspective 
    of the FE LFB topology, the 'RedirectTap' LFB is an LFB with 
    only one output port and without any input port, and the 
    output port can then be connected to any other LFB in FE 
    model by means of a datapath in the forwarding plane. From 
    the perspective of ForCES protocol layer, the 'RedirectTap' 
    LFB can receive the Packet Redirect Messages from CE, and 
    un-encapsulate the data packets from the message and put 
    them to datapaths in the forwarding plane. Actually the 
    'RecirectTap' LFB acts more like a transcoder that transfers 
    the ForCES protocol messages to normal data packets in IP 
    forwarding plane. As a result, if we need to have redirected 
    packets connected to some LFB (say a Scheduler) in FE model, 
    we only need to connect the 'RedirectTap LFB to the Scheduler 
    LFB directly via a datapath as follows:
<vspace blankLines="1" />
<figure anchor="LFB_Redirect"><artwork>
                          +-----------------+       +-----------+
                          | RedirectTap LFB |------>|           |
                          +-----------------+       |           |
                                                    | Scheduler |
                              From other LFB   ---->|    LFB    |
                                                    |           |
                                                    +-----------+
</artwork></figure>
</t>
<vspace blankLines="1" />
<t>By use of several 'RedirectSink' LFBs and several 'RedirectTap' 
    LFBs that connect to several different datapaths in FE 
    forwarding plane, multiple packet redirect paths between 
    CE and FE can be constructed. </t>
<vspace blankLines="1" />
<t hangText ="     Thought 2: ">
    There might be another way a packet could be redirected:
    directly by a forwarding path, e.g., by FPGA/ASIC/NP microcode. In 
    such a case we do not need to put in a lot of smartness. Probably 
    a link layer or even network level header is enough. The receiver 
    demuxes it only based on some protocol type in the link layer or 
    network transport layer. The pros for this appraoch is it may 
    provide a fast and cost-effective path for packet redirect. The 
    cons for this is it may more or less confuses the Fp reference 
    point definition in ForCES framework. 
</t>
</list>
<vspace blankLines="1" />
<t>We describe the Packet Redirect Message data format in details 
    as follows:</t>
<list style="hanging" hangIndent="1">
<t hangText= "Message Direction:  "><vspace />
CE to FE or FE to CE
</t>


<t hangText= "Message Header:  "><vspace />
The Message Type in the header is set to 
    MessageType= '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.
</t>


<t hangText= "Message Body: "><vspace />
Consists of one or more TLVs, with every TLV having the 
    following data format:
</t>

  
<figure anchor="tlv_Redirect_Data">
<artwork>
     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 = LFBselect       |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          LFB Class ID                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        LFB Instance ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Operatioin TLV                         |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                           ...                                 ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Operatioin TLV                         |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  
</artwork></figure>

<t hangText= "LFB class ID: "><vspace />
There are only two possible LFB classes here, the 
    'RedirectSink' LFB or the 'RedirectTap' LFB. 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 'RedirectTap'.
</t>
Why restrict this ? If any other LFB wants to generate a packet redirect to the CE, let him do it !
<t hangText= "Instance ID: "><vspace />
Instance ID for the 'RedirectSink' LFB or 'RedirectTap' LFB.
</t>


<t hangText= "Operation TLV: "><vspace />
This is a TLV describing one packet of data to be directed 
    via the specified LFB above. The order of the data number is 
    also the order the data packet arrives the redirector LFB, that 
    is, the Redirected Data #1 should arrive earlier than the 
    Redirected Data #2 in this redirector LFB. The TLV format is 
    as follows:
</t>
If what you mean is sequencing the redirected packet then I think it is dangerous. Assume you use UDP to transport the redirected packets from the CE to the FE. If one is lost, then what will the FE do with the next ones ?

<figure anchor="tlv_Redirected_Data"><artwork>
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type = Operations (PAYLOAD)|               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Path(or Sequence Number?)              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                        Redirected Data                        ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<t hangText= "Path(or Sequence Number?): "><vspace />
[Under discussion and TBD]
</t>
<t hangText= "Type: "><vspace />
[TBD]
</t>

<t hangText= "Redirected Data: "><vspace />
This field will make a detailed description of the data to 
    be redirected as well as the data itself. The encoding of the 
    description is based on the ForCES FE model if the redirector 
    LFB is defined by FE model, or based on vendor specifications 
    if the redirector LFB is defined by vendors. The description 
    will usually include the name (or the name ID) of the redirected 
    packet data (such as 'IPv4 Packet', 'IPv6 Packet'), and the 
    packet data itself. It may also include some metadata (metadata 
    name (or name ID) and its value)associated with the redirected 
    data packet.
</t>
</list>
</section>

<!-- $Log: RedirectMsg.xml,v $
<!-- Rewritten by Weiming Wang 2004/10/22
<!-- Incorparate LFBselect and Operation TLV 
<!--
<!-- Revision 1.7  2004/07/19 09:37:05  avri
<!-- Version 2 checkin
<!--
<!-- Revision 1.6  2004/06/23 05:05:34  avri
<!-- final edit for 00
<!--
<!-- Revision 1.5  2004/06/22 07:02:37  avri
<!-- remove
<!--
<!-- Revision 1.4  2004/06/22 07:01:00  avri
<!-- Team Edit from 00-7
<!--
<!-- Revision 1.2  2004-06-21 21:40:41+08  administrator
<!-- Incorparate some comments from Jamal (June 21, 2004 10:50 AM). -Weiming
<!--
<!-- Revision 1.1  2004-06-21 21:09:41+08  administrator
<!-- Revision handed from Avri. - Weiming
<!--
<!-- Revision 1.3  2004/06/19 13:11:12  avri
<!-- Linefeeds
<!--
<!-- Revision 1.2  2004/06/19 13:05:00  avri
<!-- anchors
<!--
<!-- Revision 1.1  2004/06/17 03:45:55  avri
<!-- Initial revision
<!-- 
     edited with <OXygen/>XML editor 4.1, by Weiming Wang & Ligang Dong 
     *** RedirectMsg V1.0, 2004-06-13, changes since last version:
     - None, as the original version.
-->
  
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with <OXygen/>XML editor 4.1, by Weiming Wang & Ligang Dong 
     *** QueryMsg V1.0, 2004-06-13, changes since last version:
     - None, as the original version.
     *** QueryMsgV1.1, 2004-06-18
     - change EncodingType to Type
     *** QueryMsgV1.2, 2004-10-20
     - for ietf-protocol-01
-->

<section anchor="QueryMsg" title="Query and Response Messages">
Be more specific: "Query and Query Response Messages"
<t>The ForCES query and response messages are used for one ForCES 
    element (CE or FE) to query other ForCES element(s) for various 
    kinds of information. Current version of ForCES protocol limits 
    the use of the messages only for CE to query information of FE. 
</t>
<section anchor="Query" title="Query Message">

<t>As usual, a query 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.</t>
<list style="hanging" hangIndent="4"> <vspace />
<vspace blankLines="1" />
<t hangText= "Message transfer direction:"> <vspace />
Current version limits the query message transfer direction 
    only from CE to FE.</t>

<t hangText= "Message Header:"> <vspace />
The Message Type in the header is set to MessageType= '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.</t>


<t hangText = "Message body: "><vspace />
The query message body consists of (at least) one or more than 
    one TLVs that describe entries to be queried. The TLV is called 
    LFBselect TLV and the data format is as below:
</t>
<figure anchor="msg_Query">
<artwork>
 
      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 = LFBselect       |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          LFB Class ID                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        LFB Instance ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Operatioin TLV                         |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                           ...                                 ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Operatioin TLV                         |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Typo in all figures: correct "Operatioin TLV"

General comment: in many cases the same type in TLV is used in different PL messages (Query vs Response, etc) and then the V is different. This WILL be a big source of implementation bugs. I think we should defined operation TLVs differently: GET and GET-RESP, SET and SET-RESP, REPORT and REPORT-RESP.
What do you think ?
     
</artwork>
</figure>
<vspace blankLines="1" />
<list style= "hanging" hangIndent="17" >
<t hangText = "Editorial Note: ">
</t>
<list style="numbers" hangIndent="3">
<t>Under discussion is whether there is a need for explicit multiple LFB insatance
    addressing here. One way to realize it is to define a specific Instance select
    TLV to substitute above 'LFB Instance ID' field. The TLV may have following format:</t>
<figure><artwork>
        INSselectTLV := Type Length Value
        Type := INSselect
        Value := InstanceID (RangeMark | Instance ID)+

</artwork></figure>
<t>An applicable RangeMark is '0xffffffff', the value of which is the same as 
    Instance broadcast ID. Because there will be no broadcast address applied
    in this place, there will be no worry of ambiguity here.</t>
</list>   
</list>
<vspace blankLines="1" />
<t hangText= "Operation TLV"><vspace />
The Operation TLV for the 'Query' message is formatted as:
</t>
<figure anchor="tlv_Query">
<artwork>    
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type = Operations (GET)    |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Path(or Attribute ID?)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Query Data                         |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Again, in all your sections, could you change "Type = Operations (GET)" to "Type = GET" and so on ?
</artwork></figure>
<t hangText= "Path(or Attribute ID?): "><vspace />
[Under discussion and TBD]
</t>

<vspace blankLines = "1" />
<list style="hanging" hangIndent="17">
<t hangText = "Editorial Note:"> 
There is a debate on whether we should use a 'Path' or simply an 'Attribute ID' 
    or a 'Table ID' here at the protocol layer. A Path is used for data 
    indexing for a table, while an 'Attribute ID' or a 'Table ID' only specify 
    which attribute or table to use, leaving table index to be included in followed 
    data.
</t>
</list>
<vspace blankLines="1" />
<t hangText= "Query Data: "><vspace />
    [Under discussion and TBD]
</t>
</list>
<t>To better understand the above PDU format, we can show a tree structure for the 
    format as below:
<figure>
main hdr (type = Query)
     |
     |
     +--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = target LFB class
     |        |
     |        |
     |        +-- LFBInstance = target LFB instance 
     |        |
     |        |
     |        +-- T = operation { GET }
     |        |   |
     |        |   +--  // one or more path targets 
     |        |        // under discussion
     |        +-- T = operation { GET }
     |        |   |
     |        |   +--  // one or more path targets 
     |        | 

</figure>
</section>

<section anchor="QueryResponse" title="Query Response Message">
<t>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.</t>

<t>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.</t>
<vspace blankLines="1" />
<list style= "hanging" hangIndent="4">
<t hangText= "Message transfer direction: "><vspace />
Current version limits the query response message transfer direction 
    only from FE to CE.
</t>
    
<t hangText= "Message Header:  "><vspace />
The Message Type in the header is set to MessageType= '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 Sequence Number in the header SHOULD keep the same as 
    that of the query message to be responded, so that the query message 
    sender can keep track of the responses. 
</t>
    
<t hangText= "Message body: "><vspace />
The message body for a query response message consists of (at least) 
    one or more than one TLVs that describe query results for individual 
    queried entries. The TLV is also called LFBselect TLV, and has exactly 
    the same data format as query message, except the Operation TLV inside
    the TLV comprises the 'Query Response Data', instead of the 'Query Data',
    as below:
</t>

<figure anchor="msg_Query_Response">
<artwork>
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type = Operations (GET)    |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Path(or Attribute ID?)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Query Response Data                    |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
You should specify here that the order of the TLV in the Query-Reponse matches the TLVs in the Query. So there is always the same number of TLVs in the response as in the query.

Side note: we have not yet resolved the use of a transaction or sequence number that will be used for each PL message.

 
<t hangText= "Query Response Data: "><vspace />
[Under discussion and TBD]
</t>
</list>
    
</section>
</section>

<!-- $Log: QueryMsg.xml,v $
<!-- Rewritten by Weiming Wang 2004/10/22
<!-- Incorparate LFBselect and Operation TLV 
<!--
<!-- Revision 1.10  2004/10/20 14:49:36  avri
<!-- Changes for draft-ietf-forces-protocol-00
<!--
<!-- Revision 1.9  2004/07/19 09:37:22  avri
<!-- Version 2 checkin
<!--
<!-- Revision 1.8  2004/06/23 05:05:47  avri
<!-- final edits for 00
<!--
<!-- Revision 1.7  2004/06/22 06:54:17  avri
<!-- Remove
<!--
<!-- Revision 1.6  2004/06/22 06:52:33  avri
<!-- Incorporate WW changes
<!-- Include team edits on 00-7
<!--
<!-- Revision 1.2  2004-06-21 21:40:25+08  administrator
<!-- Incorparate some comments from Jamal (June 21, 2004 10:50 AM). -Weiming
<!--
<!-- Revision 1.1  2004-06-21 20:36:40+08  administrator
<!-- revision handed from Avri
<!--
<!-- Revision 1.5  2004/06/19 13:12:33  avri
<!-- formatting
<!--
<!-- Revision 1.4  2004/06/19 13:03:03  avri
<!-- fix cross reference
<!--
<!-- Revision 1.3  2004/06/19 12:21:11  avri
<!-- - change EncodingType to Type (from WW)
<!-- - fix formating
<!--
<!-- Revision 1.2  2004/06/17 03:43:47  avri
<!-- Replace with new WW files
<!--
    edited with <OXygen/>XML editor 4.1, by Weiming Wang &Ligang Dong 
     *** QueryMsg V1.0, 2004-06-13, changes since last version:
     - None, as the original version.
-->
  
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with <OXygen/>XML editor 4.1, by Weiming Wang &Ligang Dong 
     *** EventMsg V1.0, 2004-06-13, changes since last version:
     - None, as the original version.
     *** EventMsgV1.1, 2004-06-18:
     - change EncodingType to Type.
-->

<section anchor="EventMsg" title="Event Notification and Response Messages">

<t>The Event Notification Message is used for one ForCES element 
    to asynchronously notify one or more other ForCES elements 
    in the same ForCES NE on just happened events in it. The 
    Event Notification Response Message is used for the receiver 
    of the Event Notification Message to acknowledge the reception 
    of the event notification.</t>

<t>Events in current ForCES protocol can be categorized into following types:</t>
<t><list style="symbols">
<t>Events happened in CE</t>
<t>Events happened in FE</t>
Why does this matter for the protocol ?
</list></t>

<t>Events can also be categorized into two classes according to 
    whether they need subscription or not. An event in one ForCES 
    element that needs to be subscribed will send notifications to 
    other ForCES elements only when the other elements have subscribed 
    to the element for the event notification. How to 
    subscribe/unsubscribe for an event is described in the Configure 
    Message in Section 6.3. An event that needs not to be subscribed 
    will always send notifications to other ForCES elements when the 
    event happens. An event definition made by ForCES protocol, ForCES 
    FE model, or by vendors will state if the event needs subscription or not.</t>
<vspace blankLines="1" />
<list style="hanging" hangIndent="17" >
<t hangText="Editorial Note: " >
There is an argument that it is preferable to have 
all events subscribable.
</t>
</list>


<section title="Event Notification Message">

<t>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.</t>
<list style="hanging" hangIndent="1">
<t hangText= "Message Transfer Direction:  "><vspace />
FE to CE, or CE to FE
</t>


<t hangText= "Message Header:  "><vspace />
The Message Type in the message header is set to <vspace />
    MessageType = 'EventNotification'. The ACK flag in the header 
    can be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'. 
    Note that the 'Success' here only means the receiver of the message 
    has successfully received the message.
</t>


<t hangText= "Message Body: "><vspace />
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 defined as follows:
<vspace blankLines="1" />
</t>

<figure anchor="tlv_Event_Notification">
<artwork>
      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 = LFBselect       |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          LFB Class ID                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        LFB Instance ID                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Operatioin TLV                         |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                           ...                                 ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Operatioin TLV                         |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
</artwork></figure>

<t hangText= "Operation TLV: "><vspace />
This is a TLV that describes the event to be notified, as follows:
</t>

<figure anchor="tlv_Event"><artwork>
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type = Operations (REPORT) |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Path(or Event ID?)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Event Data                         |
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork></figure>
<t hangText= "Path(or Event ID): "><vspace />
[Under discussion and TBD]
</t>

<t hangText= "Event Data: "><vspace />
    [Under discussion and TBD]
</t>
</list>
<t>To better understand the above PDU format, we can show a tree structure for the 
    format as below:
<figure>
main hdr (type = Event Notification)
     |
     |
     +--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = target LFB class
     |        |
     |        |
     |        +-- LFBInstance = target LFB instance 
     |        |
     |        |
     |        +-- T = operation { REPORT }
     |        |   |
     |        |   +--  // one or more path targets 
     |        |        // under discussion
     |        +-- T = operation { REPORT }
     |        |   |
     |        |   +--  // one or more path targets 
     |        | 

</figure>
</list>
</section>

<section title="Event Notification Response Message">

<t>After sending out an Event Notification Message, the sender may 
    be interested in ensuring that the message has been received 
    by receivers, especially when the sender thinks the event 
    notification is vital for system management. An Event 
    Notification Response Message is used for this purpose. The 
    ACK flag in the Event Notification Message header are used to 
    signal if such acknowledge is requested or not by the sender.</t> 

<t>Detailed description of the message is as below:</t>
<list style="hanging" hangIndent="1">
<t hangText= "Message Transfer Direction:  "><vspace />
>From FE to CE or from CE to FE, just inverse to the 
    direction of the Event Notification Message that it responses.
</t>


<t hangText= "Message Header:  "><vspace />
The Message Type in the header is set 
    MessageType= 'EventNotificationResponse'. The ACK flag in the 
    header SHOULD be set 'NoACK', meaning no further response for 
    the message is expected. If the ACK flag is set other values, 
    the meaning of the flag will then be ignored. 
    The Sequence Number in the header SHOULD keep the same as that 
    of the message to be responded, so that the event notificatin 
    message sender can keep track of the responses.
</t>

<t hangText= "Message Body: "><vspace />
The message body for an event notification message consists
correct above: event notification "response" message
    of (at least) one or more than one TLVs that describe the 
    notified events. The TLV is also called LFBselect TLV, and has exactly 
    the same data format as Event Notification Message, except the Operation 
    TLV inside the TLV comprises the event response data, instead of the 
    'Event Data', as below:
Again, you should mention that the each "Operation TLV" in the response corresponds one-to-one to a TLV in the notification.
<vspace blankLines="1" />

<figure anchor="tlv_Repsonse_Result">
<preamble>
This contains a TLV that describe the response result 
    as below:
</preamble>
<artwork>
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type = Operations (REPORT) |               Length          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Path(or Event ID?)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Result     |   Reason      |         Code                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

</artwork></figure>
<t hangText= "Path(or Event ID?): "><vspace />
[Under discussion and TBD]
</t>
<t hangText= "Result: "><vspace />
This describes the reception result of the event notification 
    message as below:
</t>
<figure><artwork>
	Result Value             Meaning
	'Success'       The event has been successfully received.
	'Unsuccess'     The event has not been successfully received.
</artwork></figure>

<t hangText= "Reason, Code: "><vspace />
This describes the reason and possible error code when 
    the message is not successfully received. Note that only the 
    failure at the protocol layer rather than the transport layer 
    can be allocated here,
typo: not "allocated" but "handled".
 that is, if even the header part of the 
    message to be responded can not be correctly received, the 
    response to the message will not be able to be generated by 
    the receiver.
</t>
<vspace blankLines="1" />
<list style="hanging" hangIndent="17">
<t hangText="Editorial Note: "> 
There is a debate on whether the Event Notification 
    Response Message is necessary or not. The pro for it is some event 
    notification senders may be interested in knowing if receivers 
    have had success/unsuccess receptions of the events or not. An 
    alternative to generate such response is for the protocol to 
    define a universal ACK message so that it can act as responses 
    for any types of messages as well as the event notification 
    messages, when the message senders are interested in knowing 
    whether the messages have been successfully received or not 
    (different from the responses for the message processing results).
</t> 
</list>
</list>
</section>
</section>

<!-- $Log: EventMsg.xml,v $
<!-- Rewritten by Weiming Wang 2004/10/22
<!-- Incorparate LFBselect and Operation TLV 
<!--
<!-- Revision 1.7  2004/07/19 09:38:16  avri
<!-- Version 2 checkin
<!--
<!-- Revision 1.6  2004/06/23 05:05:20  avri
<!-- final edit for 00
<!--
<!-- Revision 1.5  2004/06/22 06:59:23  avri
<!-- remove
<!--
<!-- Revision 1.4  2004/06/22 06:58:25  avri
<!-- Team edits from 00-7
<!--
<!-- Revision 1.2  2004-06-21 21:40:58+08  administrator
<!-- Incorparate some comments from Jamal (June 21, 2004 10:50 AM). -Weiming
<!--
<!-- Revision 1.1  2004-06-21 21:07:54+08  administrator
<!-- Revision handed from Avri  - Weiming
<!--
<!-- Revision 1.3  2004/06/19 13:13:30  avri
<!-- Formatting
<!--
<!-- Revision 1.2  2004/06/19 12:29:52  avri
<!-- - change EncodingType to Type. (from WW)
<!-- Fice formatting
<!--
<!-- Revision 1.1  2004/06/17 03:45:02  avri
<!-- Initial revision
<!--
     edited with <OXygen/>XML editor 4.1, by Weiming Wang &Ligang Dong
     *** EventMsg V1.0, 2004-06-13, changes since last version:
     - None, as the original version.
-->
  

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------040902070701020604030008-- --===============0316602311== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0316602311==-- From forces-protocol-bounces@ietf.org Fri Oct 22 15:32:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02721 for ; Fri, 22 Oct 2004 15:32:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5MN-0004wt-8v for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 15:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4zu-0001qk-Dw; Fri, 22 Oct 2004 15:22:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4xX-0007xQ-4L for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 15:20:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01597 for ; Fri, 22 Oct 2004 15:20:15 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5AM-0004kZ-0B for forces-protocol@ietf.org; Fri, 22 Oct 2004 15:33:35 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102212223790:37977 ; Fri, 22 Oct 2004 12:22:37 -0700 Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt From: Jamal Hadi Salim To: Robert Haas In-Reply-To: <4179571E.2080400@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E02579209@orsmsx408> <420441FF-23F7-11D9-9DB1-000393CC2112@acm.org> <108701c4b84a$8028ba60$845c21d2@Necom.hzic.edu.cn> <4179571E.2080400@zurich.ibm.com> Organization: Znyx Networks Message-Id: <1098472803.1399.13.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Oct 2004 15:20:04 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/22/2004 12:22:38 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/22/2004 12:22:46 PM, Serialize complete at 10/22/2004 12:22:46 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Wang, Weiming" , avri@acm.org, forces-protocol@ietf.org, Ligang Dong X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On Fri, 2004-10-22 at 14:53, Robert Haas wrote: > Weiming, > I have a few suggestions for your sections. See inline. Please review > them and indicate to Avri if she should incorporate these into the > final draft. It would be good if Avri could do the english-check on > these sections to as I am not a native english speaker neither > Regards, Hormuzd, Can we have a quick concal over the weekend at some point? I think we need to go over section six and the rest really quickly. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 15:32:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02747 for ; Fri, 22 Oct 2004 15:32:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5MV-0004xA-8k for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 15:46:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4zu-0001rX-JA; Fri, 22 Oct 2004 15:22:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL4y8-00006c-KU for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 15:20:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01679 for ; Fri, 22 Oct 2004 15:20:53 -0400 (EDT) From: avri@acm.org Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL5Ax-0004lQ-Ai for forces-protocol@ietf.org; Fri, 22 Oct 2004 15:34:12 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9MIuXep027522; Fri, 22 Oct 2004 20:56:33 +0200 In-Reply-To: <108701c4b84a$8028ba60$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E02579209@orsmsx408> <420441FF-23F7-11D9-9DB1-000393CC2112@acm.org> <108701c4b84a$8028ba60$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7AA0AA41-245F-11D9-9DB1-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Date: Fri, 22 Oct 2004 15:20:48 -0400 To: "Wang,Weiming" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit XML is easier then text. and text diffs are easier then complete text. i can always massage the xml it to make it compile. i am not sure what you mean, though, as the syntax i sent certainly works with xml2rfc. or is it your oxygen xml editor that is having the problem. i use emacs, in sgml mode, to edit the xml files so have few restrictions. but now i am waiting for you to bless Robert's edits before i include it. a. On 22 okt 2004, at 11.19, Wang,Weiming wrote: > Hi Avri, > > I'v updated the RedirectMsg, QueryMsg, and EventMsg as XML file in the > attachments. It's a pity that I just find I can not pass to parse the > file by > xml2rfc because it included some of the format defined by you, > therefore it > seems I can not verify the correctness of the file for the xml > format. I really > want to save some of your work but it seems I'm not able to. If you > like, next > time I would just use txt like Hormuzd did. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 19:26:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13079 for ; Fri, 22 Oct 2004 19:26:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL90Z-0000W4-3I for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 19:39:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8XV-0006KI-DZ; Fri, 22 Oct 2004 19:09:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8JP-0003rV-6o for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 18:55:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08027 for ; Fri, 22 Oct 2004 18:55:05 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8WJ-0007PD-Lp for forces-protocol@ietf.org; Fri, 22 Oct 2004 19:08:28 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9MMt606028181; Fri, 22 Oct 2004 22:55:06 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9MMkFJu032343; Fri, 22 Oct 2004 22:48:04 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102215542602154 ; Fri, 22 Oct 2004 15:54:26 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 15:54:26 -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 Subject: RE: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Date: Fri, 22 Oct 2004 15:54:25 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02FD98CE@orsmsx408> Thread-Topic: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Thread-Index: AcS4bCqtIHlY+NeaQ3y56+LxfQOGBgAHYvAA From: "Khosravi, Hormuzd M" To: , "Robert Haas" X-OriginalArrivalTime: 22 Oct 2004 22:54:26.0888 (UTC) FILETIME=[14E6BC80:01C4B88A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, avri@acm.org, Ligang Dong , "Wang, Weiming" , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Jamal, I don't think this will be possible especially over the weekend. Section 6 is looking pretty good actually, we have used the text you provided in most places. Did you get a chance to review the Header, etc ? Thanks Hormuzd=20 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Friday, October 22, 2004 12:20 PM To: Robert Haas Cc: Wang,Weiming; avri@acm.org; Khosravi, Hormuzd M; forces-protocol@ietf.org; Ligang Dong; ram.gopal@nokia.com Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt On Fri, 2004-10-22 at 14:53, Robert Haas wrote: > Weiming, > I have a few suggestions for your sections. See inline. Please review > them and indicate to Avri if she should incorporate these into the > final draft. It would be good if Avri could do the english-check on > these sections to as I am not a native english speaker neither > Regards, Hormuzd,=20 Can we have a quick concal over the weekend at some point? I think we need to go over section six and the rest really quickly. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 19:28:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13328 for ; Fri, 22 Oct 2004 19:28:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL92F-0000a1-9x for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 19:41:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8ny-00019C-NX; Fri, 22 Oct 2004 19:26:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8Yf-0007Yk-SL for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 19:10:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11820 for ; Fri, 22 Oct 2004 19:10:51 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8lZ-00007F-LG for forces-protocol@ietf.org; Fri, 22 Oct 2004 19:24:14 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9MNAw06003255; Fri, 22 Oct 2004 23:10:58 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9MN3eJ8013534; Fri, 22 Oct 2004 23:03:52 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102216101213828 ; Fri, 22 Oct 2004 16:10:14 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 16:10:12 -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 Subject: RE: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Date: Fri, 22 Oct 2004 16:10:10 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02FD992D@orsmsx408> Thread-Topic: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Thread-Index: AcS4bEFw/7TIWgyTR7+cMzVdkfqf/QAH3H0g From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" X-OriginalArrivalTime: 22 Oct 2004 23:10:12.0031 (UTC) FILETIME=[48401CF0:01C4B88C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Robert Haas , Ligang Dong , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Avri, All of us are not very familiar with XML, so you will have to bare with the text for sometime...I could easily maintain this entire draft in Word but most folks wont like that. Is it possible for you to convert Weiming's section (that he sent today morning) to text and send them to me? (even if you don't add it to the draft right now) I requested you in the morning, but seems like you missed that part...? Thanks Hormuzd=20 -----Original Message----- From: avri@acm.org [mailto:avri@acm.org]=20 Sent: Friday, October 22, 2004 12:21 PM To: Wang,Weiming Cc: Ligang Dong; forces-protocol@ietf.org; Robert Haas; ram.gopal@nokia.com; Khosravi, Hormuzd M; Jamal Hadi Salim Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt XML is easier then text. and text diffs are easier then complete text. i can always massage the xml it to make it compile. i am not sure what you mean, though, as the syntax i sent certainly=20 works with xml2rfc. or is it your oxygen xml editor that is having the=20 problem. i use emacs, in sgml mode, to edit the xml files so have few=20 restrictions. but now i am waiting for you to bless Robert's edits before i include=20 it. a. On 22 okt 2004, at 11.19, Wang,Weiming wrote: > Hi Avri, > > I'v updated the RedirectMsg, QueryMsg, and EventMsg as XML file in the > attachments. It's a pity that I just find I can not pass to parse the=20 > file by > xml2rfc because it included some of the format defined by you,=20 > therefore it > seems I can not verify the correctness of the file for the xml=20 > format. I really > want to save some of your work but it seems I'm not able to. If you=20 > like, next > time I would just use txt like Hormuzd did. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 19:28:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13384 for ; Fri, 22 Oct 2004 19:28:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL92e-0000ai-RR for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 19:41:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8o1-0001FD-5Y; Fri, 22 Oct 2004 19:26:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL8Zn-0000CJ-Tr for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 19:12:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11941 for ; Fri, 22 Oct 2004 19:12:02 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8mh-00009w-FW for forces-protocol@ietf.org; Fri, 22 Oct 2004 19:25:25 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9MNFOMH007527; Fri, 22 Oct 2004 23:15:24 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9MN3kJw013699; Fri, 22 Oct 2004 23:05:07 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102216113004771 ; Fri, 22 Oct 2004 16:11:30 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 16:11:30 -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 Subject: RE: [Forces-protocol] Header Section Date: Fri, 22 Oct 2004 16:11:27 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02FD9935@orsmsx408> Thread-Topic: [Forces-protocol] Header Section Thread-Index: AcS3qtii9vXRNEFHTMaB+7E4kn9n6wA4X0Bw From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 22 Oct 2004 23:11:30.0159 (UTC) FILETIME=[76D17FF0:01C4B88C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Jamal, Pls take care of the Header section, no one seems to be looking at it. Thanks Hormuzd=20 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Robert,Weiming, Ligang: Are you taking care of the common header section or should i jump into that next? Not that i think there are any useful changes tomake for this version of draft. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 21:15:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20088 for ; Fri, 22 Oct 2004 21:15:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLAiV-0002Qy-T1 for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 21:29:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLAUg-0005Pd-KE; Fri, 22 Oct 2004 21:14:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLASU-0003wu-SQ for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 21:12:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19865 for ; Fri, 22 Oct 2004 21:12:38 -0400 (EDT) From: avri@acm.org Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLAfQ-0002OT-JX for forces-protocol@ietf.org; Fri, 22 Oct 2004 21:26:01 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9N0mEep028152; Sat, 23 Oct 2004 02:48:16 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02FD992D@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02FD992D@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9C886B40-2490-11D9-9DB1-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Date: Fri, 22 Oct 2004 21:12:30 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit On 22 okt 2004, at 19.10, Khosravi, Hormuzd M wrote: > Avri, > > All of us are not very familiar with XML, so you will have to bare with > the text for sometime...I could easily maintain this entire draft in > Word but most folks wont like that. fine. as i said dealing with text is ok, though text diff is easier. > > Is it possible for you to convert Weiming's section (that he sent today > morning) to text and send them to me? (even if you don't add it to the > draft right now) I requested you in the morning, but seems like you > missed that part...? > i did not miss it, i was waiting for Weiming's response to Robert's changes. but i will fold it in this evening in any case. I was assuming i would do one version a day. yesterday i did two since i had missed your HA material. the material is coming in a sort of a chaotic manner and while my preference would be to let things settle down before cutting in the text, i realize that because we waited until the last minute to do updates (in true ietf style, i might add) we don't have that luxury. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 21:42:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21602 for ; Fri, 22 Oct 2004 21:42:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLB8i-0002pt-Ri for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 21:56:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLAuH-0008Tv-2C; Fri, 22 Oct 2004 21:41:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLAsC-0007bj-Rc for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 21:39:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21472 for ; Fri, 22 Oct 2004 21:39:11 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLB57-0002mq-Se for forces-protocol@ietf.org; Fri, 22 Oct 2004 21:52:34 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9N1cDSA016895; Sat, 23 Oct 2004 01:38:13 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9N1VtJE003931; Sat, 23 Oct 2004 01:32:12 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102218383421552 ; Fri, 22 Oct 2004 18:38:34 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 18:38:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4B8A1.027CA750" Date: Fri, 22 Oct 2004 18:38:29 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0257920E@orsmsx408> X-MS-Has-Attach: yes Thread-Topic: draft update.... Thread-Index: AcS4nWa4ugNgyQO8Sc+X22mTenacMQAAt5Eg From: "Khosravi, Hormuzd M" To: , "Robert Haas" X-OriginalArrivalTime: 23 Oct 2004 01:38:35.0164 (UTC) FILETIME=[02EE65C0:01C4B8A1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Ligang Dong , "Wang, Weiming" , forces-protocol@ietf.org Subject: [Forces-protocol] draft update.... X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2fe944273194be3112d13b31c91e6941 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B8A1.027CA750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Avri, Here is the new text for section 6 (6.1, 6.3, 6.7), I have incorporated Robert's comments. Pls go ahead and Insert this into the draft. Updating the draft once a day is fine, I just have a tough time reading xml files on my laptop that runs Windows...I probably shouldn't mention this ;) Thanks Hormuzd -----Original Message----- From: avri@acm.org [mailto:avri@acm.org]=20 Sent: Friday, October 22, 2004 6:13 PM To: Khosravi, Hormuzd M Cc: Wang,Weiming; forces-protocol@ietf.org; Jamal Hadi Salim; Ligang Dong; ram.gopal@nokia.com; Robert Haas Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt On 22 okt 2004, at 19.10, Khosravi, Hormuzd M wrote: > Avri, > > All of us are not very familiar with XML, so you will have to bare with > the text for sometime...I could easily maintain this entire draft in > Word but most folks wont like that. fine. as i said dealing with text is ok, though text diff is easier. > > Is it possible for you to convert Weiming's section (that he sent today > morning) to text and send them to me? (even if you don't add it to the > draft right now) I requested you in the morning, but seems like you > missed that part...? > i did not miss it, i was waiting for Weiming's response to Robert's=20 changes. but i will fold it in this evening in any case. I was=20 assuming i would do one version a day. yesterday i did two since i had=20 missed your HA material. the material is coming in a sort of a chaotic manner and while my=20 preference would be to let things settle down before cutting in the=20 text, i realize that because we waited until the last minute to do=20 updates (in true ietf style, i might add) we don't have that luxury. a. ------_=_NextPart_001_01C4B8A1.027CA750 Content-Type: text/plain; name="section-6-update.txt" Content-Description: section-6-update.txt Content-Disposition: attachment; filename="section-6-update.txt" Content-Transfer-Encoding: base64 Ni4gIFByb3RvY29sIE1lc3NhZ2VzDQoNClRoZSBnZW5lcmFsIHN0cnVjdHVyZSBvZiBtb3N0IG1l c3NhZ2VzIGlzIGFzIGZvbGxvd3MgaW4gQk5GIGZvcm1hdDoNCg0KUEwgbGV2ZWwgUERVIDogPSBN QUlOSERSPExGQnNlbGVjdD4rIA0KTEZCc2VsZWN0IDo9IExGQkNMQVNTSUQgTEZCSW5zdGFuY2Ug PE9QRVI+Kw0KT1BFUjo9IDxPUEVSQVRJT04gWzxwYXRoLWRhdGE+XSo+Kw0KDQotIE1BSU5IRFIg ZGVmaW5lcyBtc2cgdHlwZSwgVGFyZ2V0IEZFL0NFIElEIGV0Yy4NCnRoZSBNQUlOSERSIGFsc28g ZGVmaW5lcyB0aGUgY29udGVudC4gQXMgYW4gZXhhbXBsZSB0aGUgY29udGVudCBvZg0KYSAiY29u ZmlnIiBtZXNzYWdlIHdvdWxkIGJlIGRpZmZlcmVudCBmcm9tIGFuICJhc3NvY2lhdGlvbiIgbWVz c2FnZS4NCi0gTEZCQ0xBU1NJRCBpcyBhIDMyIGJpdCB1bmlxdWUgaWRlbnRpZmllciBwZXIgTEZC IGNsYXNzIGRlZmluZWQNCmF0IGNsYXNzIGNyZWF0aW9uIHRpbWUuDQotIExGQkluc3RhbmNlIGlz IGEgMzIgYml0IHVuaXF1ZSBpbnN0YW5jZSBpZGVudGlmaWVyIG9mIGFuIExGQiBjbGFzcw0KLSBP UEVSQVRJT04gaXMgb25lIG9mIHtBREQsREVMLGV0Yy59IGRlcGVuZGluZyBvbiB0aGUgbWVzc2Fn ZSB0eXBlDQoNClRoZSBwYXRoLWRhdGEgaWRlbnRpZmllcyB0aGUgZXhhY3QgZWxlbWVudCB0YXJn ZXRlZC4NCkl0IG1heSBoYXZlIHplcm8gb3IgbW9yZSBkYXRhIHZhbHVlcyBhc3NvY2lhdGVkLg0K DQpJbiBzdW1tYXJ5IHRoaXMgYXBwcm9hY2ggaGFzIHRoZSBmb2xsb3dpbmcgY2hhcmFjdGVyaXN0 aWM6DQotIHRoZXJlIGNhbiBiZSBvbmUgb3IgbW9yZSBMRkIgQ2xhc3MgKyBJbnN0YW5jZUlkIGNv bWJvDQp0YXJnZXRlZCBpbiBhIG1lc3NhZ2UgKGJhdGNoKQ0KLSBUaGVyZSBjYW4gb25lIG9yIG1v cmUgb3BlcmF0aW9uIG9uIGFuIGFkZHJlc3NlZCBMRkIgDQpjbGFzc2lkK2luc3RhbmNlaWQgY29t Ym8oYmF0Y2gpIA0KLSBUaGVyZSBjYW4gYmUgb25lIG9yIG1vcmUgcGF0aCB0YXJnZXRzIHBlciBv cGVyYXRpb24gKGJhdGNoKQ0KLSBwYXRocyBtYXkgaGF2ZSB6ZXJvIG9yIG1vcmUgZGF0YSB2YWx1 ZXMgYXNzb2NpYXRlZCAoZmxleGliaWxpdHkNCmFuZCBvcGVyYXRpb24gc3BlY2lmaWMpDQoNCkl0 IHNob3VsZCBiZSBub3RlZCB0aGF0IHRoZSBhYm92ZSBpcyBvcHRpbWl6ZWQgZm9yIHRoZSBjYXNl IG9mIGENCmEgc2luZ2xlIGNsYXNzaWQraW5zdGFuY2UgdGFyZ2V0aW5nLiBUbyB0YXJnZXQgbXVs dGlwbGUgaW5zdGFuY2VzDQp3aXRoaW4gdGhlIHNhbWUgY2xhc3MsIG11bHRpcGxlIExGQnNlbGVj dCBhcmUgbmVlZGVkLiANCg0KDQo2LjEgIEFzc29jaWF0aW9uIE1lc3NhZ2VzDQoNCiAgIFRoZSBG b3JDRVMgQXNzb2NpYXRpb24gbWVzc2FnZXMgYXJlIHVzZWQgdG8gZXN0YWJsaXNoIGFuZCB0ZWFy ZG93bg0KICAgYXNzb2NpYXRpb25zIGJldHdlZW4gRkVzIGFuZCBDRXMuDQoNCjYuMS4xICBBc3Nv Y2lhdGlvbiBTZXR1cCBNZXNzYWdlDQoNCiAgIFRoaXMgbWVzc2FnZSBpcyBzZW50IGJ5IHRoZSBG RSB0byB0aGUgQ0UgdG8gc2V0dXAgYSBGb3JDRVMNCiAgIGFzc29jaWF0aW9uIGJldHdlZW4gdGhl bS4gIFRoaXMgbWVzc2FnZSBjb3VsZCBhbHNvIGJlIHVzZWQgYnkgQ0VzIHRvDQogICBqb2luIGEg Rm9yQ0VTIE5FLCBob3dldmVyIENFLXRvLUNFIGNvbW11bmljYXRpb24gaXMgbm90IGNvdmVyZWQg YnkNCiAgIHRoaXMgcHJvdG9jb2wuDQoNCiAgIE1lc3NhZ2UgdHJhbnNmZXIgZGlyZWN0aW9uOg0K ICAgICAgRkUgdG8gQ0UNCiAgIE1lc3NhZ2UgSGVhZGVyOg0KICAgICAgVGhlIE1lc3NhZ2UgVHlw ZSBpbiB0aGUgaGVhZGVyIGlzIHNldCBNZXNzYWdlVHlwZT0gJ0Fzc29jaWF0aW9uDQogICAgICBT ZXR1cCcuICBUaGUgQUNLIGZsYWcgaW4gdGhlIGhlYWRlciBpcyBpZ25vcmVkLCBiZWNhdXNlIHRo ZSBzZXR1cA0KICAgICAgbWVzc2FnZSB3aWxsIGFsd2F5cyBleHBlY3QgdG8gZ2V0IGEgcmVzcG9u c2UgZnJvbSB0aGUgbWVzc2FnZQ0KICAgICAgcmVjZWl2ZXIgKENFKSB3aGV0aGVyIHRoZSBzZXR1 cCBpcyBzdWNjZXNzZnVsIG9yIG5vdC4gIFRoZSBTcmMgSUQNCiAgICAgIChGRSBJRCkgbWF5IGJl IHNldCB0byBPIGluIHRoZSBoZWFkZXIgd2hpY2ggbWVhbnMgdGhhdCB0aGUgRkUNCiAgICAgIHdv dWxkIGxpa2UgdGhlIENFIHRvIGFzc2lnbiBhIEZFIElEIGZvciB0aGUgRkUgaW4gdGhlIHNldHVw DQogICAgICByZXNwb25zZSBtZXNzYWdlLg0KICAgTWVzc2FnZSBib2R5Og0KICAgICAgVGhlIHNl dHVwIG1lc3NhZ2UgYm9keSBjb25zaXN0cyBvZiBMRkJTZWxlY3QgJiBGRSBOYW1lIFRMViwgdGhl IGZvcm1hdCBvZg0KICAgICAgd2hpY2ggaXMgYXMgZm9sbG93czoNCg0KbWFpbiBoZHIgKGVnIHR5 cGUgPSAgQXNzb2NpYXRpb24gc2V0dXApDQogICAgIHwNCiAgICAgfA0KICAgICArLS0tIFQgPSBM RkJzZWxlY3QNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gTEZCQ0xBU1NJRCA9 IEZFIG9iamVjdA0KICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAg ICAgKy0tIExGQkluc3RhbmNlID0gMHgxDQogICAgIHwgICAgICAgIA0KICAgICArLS0tIFQgPSBP cGVyYXRpb24gPSBTSE9XDQogICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgKy0tIEZFIE5B TUUNCg0KDQoNCiAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICB8ICAgICAg ICBUeXBlID0gTEZCIHNlbGVjdCAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAg fA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICAgICAgfCAgICAgICAgICAgICAgICAgTEZCIENsYXNzIElE ID0gRkUgT2JqZWN0ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBMRkIgSW5zdGFuY2UgSUQgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICB8ICAgICAgICBUeXBlID0gb3Bl cmF0aW9uIFNob3cgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgRkUgTmFtZSBzdHJpbmcgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgIC4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAu DQogICAgICAgfCAgICAgICAgICAgICAgICAgICBGRSBPYmplY3QgTEZCIChpbmNsdWRpbmcgSEJJ LCBldGMpICAgICAgICAgIHwNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRmlndXJlIDgNCg0KICAgVHlwZSAoMTYgYml0cyk6DQogICAgICBMRkIg U2VsZWN0Lg0KICAgTGVuZ3RoICgxNiBiaXRzKToNCiAgICAgIExlbmd0aCBvZiB0aGUgVExWIGlu Y2x1ZGluZyB0aGUgVCBhbmQgTCBmaWVsZHMsIGluIGJ5dGVzLg0KICAgRkUgT2JqZWN0IExGQjoN CiAgICAgIFRoaXMgY29udGFpbnMgdGhlIEZFIHBhcmFtZXRlcnMgZS5nLiBIQkkgd2lsbCBiZSBl eGNoYW5nZWQgd2l0aCB0aGUgDQogICAgICBDRSB1c2luZyB0aGlzIExGQi4NCiAgIEZFIE5hbWUg U3RyaW5nOg0KICAgICAgVGhpcyBpcyBhIHN0cmluZyB3aGljaCBjb250YWlucyB0aGUgRkUgbmFt ZSAocGFydCBvZiBGRSBPYmplY3QgTEZCKS4NCg0KICAgICAgRWRpdG9yaWFsIE5vdGU6ICBJbiBj ZXJ0YWluIHNpdHVhdGlvbnMgKHN1Y2ggYXMgdXNlIG9mIG11bHRpY2FzdA0KICAgICAgICAgICAg ICAgICAgICAgICBJRHMpLCBpdCBtaWdodCBub3QgYmUgcG9zc2libGUgdG8gbWFrZSB1c2Ugb2Yg dGhlDQogICAgICAgICAgICAgICAgICAgICAgIHByb2NlZHVyZSBkZXNjcmliZWQgYWJvdmUgZm9y IHRoZSBGRSB0bw0KICAgICAgICAgICAgICAgICAgICAgICBkeW5hbWljYWxseSBvYnRhaW4gYW4g SUQgZnJvbSB0aGUgQ0UuICBTdWNoDQogICAgICAgICAgICAgICAgICAgICAgIHNpdHVhdGlvbnMg bmVlZCB0byBiZSBpZGVudGlmaWVkLg0KDQo2LjEuMiAgQXNzb2NpYXRpb24gU2V0dXAgUmVzcG9u c2UgTWVzc2FnZQ0KDQogICBUaGlzIG1lc3NhZ2UgaXMgc2VudCBieSB0aGUgQ0UgdG8gdGhlIEZF IGluIHJlc3BvbnNlIHRvIHRoZSBTZXR1cA0KICAgbWVzc2FnZS4gIEl0IGluZGljYXRlcyB0byB0 aGUgRkUgd2hldGhlciB0aGUgc2V0dXAgaXMgc3VjY2Vzc2Z1bCBvcg0KICAgbm90LCBpLmUuICB3 aGV0aGVyIGFuIGFzc29jaWF0aW9uIGlzIGVzdGFibGlzaGVkLg0KDQogICBNZXNzYWdlIHRyYW5z ZmVyIGRpcmVjdGlvbjoNCiAgICAgICBDRSB0byBGRQ0KICAgTWVzc2FnZSBIZWFkZXI6DQogICAg ICAgVGhlIE1lc3NhZ2UgVHlwZSBpbiB0aGUgaGVhZGVyIGlzIHNldCBNZXNzYWdlVHlwZT0gJ1Nl dHVwDQogICAgICAgUmVzcG9uc2UnLiAgVGhlIEFDSyBmbGFnIGluIHRoZSBoZWFkZXIgaXMgYWx3 YXlzIGlnbm9yZWQsIGJlY2F1c2UNCiAgICAgICB0aGUgc2V0dXAgcmVzcG9uc2UgbWVzc2FnZSB3 aWxsIG5ldmVyIGV4cGVjdCB0byBnZXQgYW55IG1vcmUNCiAgICAgICByZXNwb25zZSBmcm9tIHRo ZSBtZXNzYWdlIHJlY2VpdmVyIChGRSkuICBUaGUgRHN0IElEIGluIHRoZQ0KICAgICAgIGhlYWRl ciB3aWxsIGJlIHNldCB0byBzb21lIEZFIElEIHZhbHVlIGFzc2lnbmVkIGJ5IHRoZSBDRSBpZiB0 aGUNCiAgICAgICBGRSBoYWQgcmVxdWVzdGVkIHRoYXQgaW4gdGhlIHNldHVwIG1lc3NhZ2UgKGJ5 IFNyY0lEID0gMCkuDQogICBNZXNzYWdlIGJvZHk6DQogICAgICAgVGhlIHNldHVwIHJlc3BvbnNl IG1lc3NhZ2UgYm9keSBjb25zaXN0cyBvZiBMRkJTZWxlY3QgJiBSZXN1bHQgVExWLCB0aGUgZm9y bWF0DQogICAgICAgb2Ygd2hpY2ggaXMgYXMgZm9sbG93czoNCg0KDQptYWluIGhkciAoZWcgdHlw ZSA9ICBBc3NvY2lhdGlvbiBzZXR1cCByZXNwb25zZSkNCiAgICAgfA0KICAgICB8DQogICAgICst LS0gVCA9IExGQnNlbGVjdA0KICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAgICstLSBMRkJD TEFTU0lEID0gRkUgb2JqZWN0DQogICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAgICAgfA0KICAg ICB8ICAgICAgICArLS0gTEZCSW5zdGFuY2UgPSAweDENCiAgICAgfCAgICAgICAgDQogICAgICst LS0gVCA9IEZFUmVzdWx0DQogICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgKy0tIHJlc3Vs dHZhbHVlDQoNCg0KICAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICB8ICAg ICAgICBUeXBlID0gTEZCIHNlbGVjdCAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAg ICAgfA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICAgfCAgICAgICAgICAgICAgICAgTEZCIENsYXNz IElEID0gRkUgT2JqZWN0ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBMRkIgSW5zdGFuY2UgSUQgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICB8ICAgICAgICBUeXBlID0g b3BlcmF0aW9uIFNob3cgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQogICAgICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgICB8ICAgICAgICAgICAgICAgICAgIEZF IE9iamVjdCBMRkIgKG9wdGlvbmFsKSAgICAgICAgICB8DQogICAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAg ICB8ICAgICAgIFR5cGUgPSBSZXN1bHQgICAgICAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGgg ICAgICAgICAgfA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICAgfCAgICAgICAgIFJlc3VsdCAgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICBSZXNlcnZlZCAgICAgICAgIHwNCiAgICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDkNCg0KICAg VHlwZSAoMTYgYml0cyk6DQogICAgICAgTEZCIFNlbGVjdC4NCiAgIExlbmd0aCAoMTYgYml0cyk6 DQogICAgICAgTGVuZ3RoIG9mIHRoZSBUTFYgaW5jbHVkaW5nIHRoZSBUIGFuZCBMIGZpZWxkcywg aW4gYnl0ZXMuDQogICBGRSBPYmplY3QgTEZCOg0KICAgICAgVGhlIEZFIHBhcmFtZXRlcnMgZS5n LiBIQkkgbWF5IGJlIGV4Y2hhbmdlZCB1c2luZyB0aGlzIExGQi4NCiAgIFJlc3VsdCAoMTYgYml0 cyk6DQogICAgICAgVGhpcyBpbmRpY2F0ZXMgd2hldGhlciB0aGUgc2V0dXAgbXNnIHdhcyBzdWNj ZXNzZnVsIG9yIHdoZXRoZXINCiAgICAgICB0aGUgRkUgcmVxdWVzdCB3YXMgcmVqZWN0ZWQgYnkg dGhlIENFLg0KDQo2LjEuMyAgQXNzb2NpYXRpb24gVGVhcmRvd24gTWVzc2FnZQ0KDQogICBUaGlz IG1lc3NhZ2UgY2FuIGJlIHNlbnQgYnkgdGhlIEZFIG9yIENFIHRvIGFueSBGb3JDRVMgZWxlbWVu dCB0byBlbmQNCiAgIGl0cyBGb3JDRVMgYXNzb2NpYXRpb24gd2l0aCB0aGF0IGVsZW1lbnQuDQoN CiAgIE1lc3NhZ2UgdHJhbnNmZXIgZGlyZWN0aW9uOg0KICAgICAgIENFIHRvIEZFLCBvciBGRSB0 byBDRSAob3IgQ0UgdG8gQ0UpDQogICBNZXNzYWdlIEhlYWRlcjoNCiAgICAgICBUaGUgTWVzc2Fn ZSBUeXBlIGluIHRoZSBoZWFkZXIgaXMgc2V0IE1lc3NhZ2VUeXBlPSAiQXNzby4NCiAgICAgICBU ZWFyZG93biIuICBUaGUgQUNLIGZsYWcgaW4gdGhlIGhlYWRlciBpcyBhbHdheXMgaWdub3JlZCwN CiAgICAgICBiZWNhdXNlIHRoZSB0ZWFyZG93biBtZXNzYWdlIHdpbGwgbmV2ZXIgZXhwZWN0IHRv IGdldCBhbnkNCiAgICAgICByZXNwb25zZSBmcm9tIHRoZSBtZXNzYWdlIHJlY2VpdmVyLg0KICAg TWVzc2FnZSBib2R5Og0KICAgICAgIFRoZSBhc3NvY2lhdGlvbiB0ZWFyZG93biBtZXNzYWdlIGJv ZHkgY29uc2lzdHMgb2YgTEZCU2VsZWN0ICYgRkVSZWFzb24gVExWLCB0aGUNCiAgICAgICBmb3Jt YXQgb2Ygd2hpY2ggaXMgYXMgZm9sbG93czoNCg0KbWFpbiBoZHIgKGVnIHR5cGUgPSAgQXNzb2Np YXRpb24gdGVhcikNCiAgICAgfA0KICAgICB8DQogICAgICstLS0gVCA9IExGQnNlbGVjdA0KICAg ICB8ICAgICAgICB8DQogICAgIHwgICAgICAgICstLSBMRkJDTEFTU0lEID0gRkUgb2JqZWN0DQog ICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gTEZCSW5z dGFuY2UgPSAweDENCiAgICAgfCAgICAgICAgDQogICAgICstLS0gVCA9IEZFUmVhc29uDQogICAg ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgKy0tICJteXJlYXNvbiINCg0KDQoNCiAgICAgICAg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxDQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICB8ICAgICAgICBUeXBlID0gTEZCIHNlbGVj dCAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICAgICAgfCAgICAgICAgICAgICAgICAgTEZCIENsYXNzIElEID0gRkUgT2JqZWN0ICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICBMRkIgSW5zdGFuY2UgSUQgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgICAgICB8ICAgICAgICAgVHlwZSA9IFQucmVhc29uICAgICAgIHwgICAg ICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICAgfCAg ICAgICAgICAgICAgICAgICBSZWFzb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBGaWd1cmUgMTANCg0KICAgVHlwZSAoMTYgYml0cyk6DQogICAgICAgTEZCIFNlbGVjdC4NCiAg IExlbmd0aCAoMTYgYml0cyk6DQogICAgICAgTGVuZ3RoIG9mIHRoZSBUTFYgaW5jbHVkaW5nIHRo ZSBUIGFuZCBMIGZpZWxkcywgaW4gYnl0ZXMuDQogICBULnJlYXNvbiAoMzIgYml0cyk6DQogICAg ICAgVGhpcyBpbmRpY2F0ZXMgdGhlIHJlYXNvbiB3aHkgdGhlIGFzc29jaWF0aW9uIGlzIGJlaW5n DQogICAgICAgdGVybWluYXRlZC4NCg0KDQo2LjMgIENvbmZpZ3VyYXRpb24gTWVzc2FnZXMNCg0K ICAgVGhlIEZvckNFUyBDb25maWd1cmF0aW9uIG1lc3NhZ2VzIGFyZSB1c2VkIGJ5IHRoZSBDRXMg dG8gY29uZmlndXJlDQogICB0aGUgRkVzIGluIGEgRm9yQ0VTIE5FIGFuZCByZXBvcnQgdGhlIHJl c3VsdHMgYmFjayB0byB0aGUgQ0UuDQoNCjYuMy4xICBDb25maWcgTWVzc2FnZQ0KDQogICBUaGlz IG1lc3NhZ2UgaXMgc2VudCBieSB0aGUgQ0UgdG8gdGhlIEZFIHRvIGNvbmZpZ3VyZSBGRSBvciBM RkINCiAgIGF0dHJpYnV0ZXMuICBUaGlzIG1lc3NhZ2UgaXMgYWxzbyB1c2VkIGJ5IHRoZSBDRSB0 byBzdWJzY3JpYmUvDQogICB1bnN1YnNjcmliZSB0byBGRSwgTEZCIGV2ZW50cy4NCg0KICAgTWVz c2FnZSB0cmFuc2ZlciBkaXJlY3Rpb246DQogICAgICAgQ0UgdG8gRkUNCiAgIE1lc3NhZ2UgSGVh ZGVyOg0KICAgICAgIFRoZSBNZXNzYWdlIFR5cGUgaW4gdGhlIGhlYWRlciBpcyBzZXQgTWVzc2Fn ZVR5cGU9ICdDb25maWcnLiAgVGhlDQogICAgICAgQUNLIGZsYWcgaW4gdGhlIGhlYWRlciBpcyBj YW4gYmUgdXNlZCBieSB0aGUgQ0UgdG8gdHVybiBvZmYgYW55DQogICAgICAgcmVzcG9uc2UgZnJv bSB0aGUgRkUuICBUaGUgZGVmYXVsdCBiZWhhdmlvciBpcyB0byB0dXJuIG9uIHRoZSBBQ0sNCiAg ICAgICB0byBnZXQgdGhlIGNvbmZpZyByZXNwb25zZSBmcm9tIHRoZSBGRS4NCiAgIE1lc3NhZ2Ug Ym9keToNCiAgICAgICBUaGUgQ29uZmlnIG1lc3NhZ2UgYm9keSBjb25zaXN0cyBvZiBvbmUgb3Ig bW9yZSBUTFZzLCB0aGUgZm9ybWF0DQogICAgICAgb2YgdGhlIFRMVnMvbWVzc2FnZSBpcyBhcyBm b2xsb3dzOg0KDQoNCm1haW4gaGRyIChlZyB0eXBlID0gY29uZmlnKQ0KICAgICB8DQogICAgIHwN CiAgICAgKy0tLSBUID0gTEZCc2VsZWN0DQogICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAgICAg Ky0tIExGQkNMQVNTSUQgPSB0YXJnZXQgTEZCIGNsYXNzDQogICAgIHwgICAgICAgIHwNCiAgICAg fCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gTEZCSW5zdGFuY2UgPSB0YXJnZXQgTEZCIGlu c3RhbmNlIA0KICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAgICAg Ky0tIFQgPSBvcGVyYXRpb24geyBBREQsIERFTCwgIGV0Y30NCiAgICAgfCAgICAgICAgfCAgIHwN CiAgICAgfCAgICAgICAgfCAgICstLSAgLy8gb25lIG9yIG1vcmUgcGF0aCB0YXJnZXRzIA0KICAg ICB8ICAgICAgICB8ICAgICAgICAvLyB1bmRlciBkaXNjdXNzaW9uDQogICAgIHwgICAgICAgIHwN CiAgICAgfCAgICAgICAgKy0tIFQgPSBvcGVyYXRpb24geyBBREQsIERFTCwgIGV0Y30NCiAgICAg fCAgICAgICAgfCAgIHwNCiAgICAgfCAgICAgICAgfCAgICstLSAgLy8gb25lIG9yIG1vcmUgcGF0 aCB0YXJnZXRzIA0KICAgICB8ICAgICAgICB8ICAgICAgICAvLyB1bmRlciBkaXNjdXNzaW9uDQog ICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAgICAgKy0tIFQgPSBvcGVyYXRpb24geyBBREQsIERF TCwgIGV0Y30NCiAgICAgfCAgICAgICAgfCAgIHwNCiAgICAgfCAgICAgICAgfCAgICstLSAgLy8g b25lIG9yIG1vcmUgcGF0aCB0YXJnZXRzIA0KICAgICB8ICAgICAgICB8ICAgICAgICAvLyB1bmRl ciBkaXNjdXNzaW9uDQogICAgIHwgICAgICAgIHwNCg0KDQogICAgICAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgICAgfCAgICAgICAgVHlwZSA9IExGQiBzZWxlY3QgICAgICB8ICAgICAgICAgICAg ICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgTEZCIENsYXNzIElEICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIExGQiBJbnN0YW5jZSBJRCAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICBUeXBlID0g T3BlcmF0aW9ucyAoQUREKSAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICBDb25maWcgZGF0YSAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiAgICAgfCAgICBUeXBlID0gT3BlcmF0aW9ucyAoREVMKSAgICB8ICAgICAgICAgICAgICAgTGVu Z3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICBDb25maWcgZGF0YSAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC4NCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3Vy ZSAxNg0KDQogICBUeXBlICgxNiBiaXRzKToNCiAgICAgICBMRkIgU2VsZWN0Lg0KICAgTGVuZ3Ro ICgxNiBiaXRzKToNCiAgICAgICBMZW5ndGggb2YgdGhlIFRMViBpbmNsdWRpbmcgdGhlIFQgYW5k IEwgZmllbGRzLCBpbiBieXRlcy4NCiAgIExGQiBDbGFzcyBJRCAoMTYgYml0cyk6DQogICAgICAg VGhpcyBmaWVsZCB1bmlxdWVseSByZWNvZ25pemVzIHRoZSBMRkIgY2xhc3MvdHlwZS4NCiAgIExG QiBJbnN0YW5jZSBJRCAoMTYgYml0cyk6DQogICAgICAgVGhpcyBmaWVsZCB1bmlxdWVseSBpZGVu dGlmaWVzIHRoZSBMRkIgaW5zdGFuY2UuDQogICBUeXBlICgxNiBiaXRzKToNCiAgICAgICBUaGUg b3BlcmF0aW9ucyBpbmNsdWRlLCBBREQsIERFTCwgVVBEQVRFL1JFUExBQ0UsIERFTCBBTEwsIEVW RU5UIFNVQlNDUklCRSwNCiAgICAgICBFVkVOVCBVTlNVQlNDUklCRSwgUEFDS0VUIFNVQlNDUklC RSwgUEFDS0VUIFVOU1VCU0NSSUJFLCBDQU5DRUwuDQoNCiAgIExlbmd0aCAoMTYgYml0cyk6DQog ICAgICAgTGVuZ3RoIG9mIHRoZSBUTFYgaW5jbHVkaW5nIHRoZSBUIGFuZCBMIGZpZWxkcywgaW4g Ynl0ZXMuDQoNCiAgIENvbmZpZyBEYXRhICh2YXJpYWJsZSBsZW5ndGgpOg0KICAgICAgIFRoaXMg d2lsbCBjYXJyeSBMRkIgc3BlY2lmaWMgZGF0YSAoPHBhdGg+LHNpbmdsZSBvciBBcnJheSBMRkIg c3BlY2lmaWMNCiAgICAgICBlbnRyaWVzKS4gIFRoZSBjb25maWcgZGF0YSBtaWdodCBpdHNlbGYg YmUgb2YgdGhlIGZvcm0gb2YgYSBUTFYuDQoNCipOb3RlOiBGRSBBY3RpdmF0ZS9EZWFjdGl2YXRl LCBTaHV0ZG93biBGRSBjb21tYW5kcyBmb3IgU3RhdGUgTWFpbnRlbmFuY2Ugd2lsbA0KICAgICAg YmUgc2VudCB1c2luZyBDb25maWcgbWVzc2FnZXMuDQoqTm90ZTogRm9yIEV2ZW50IHN1YnNjcmlw dGlvbiwgdGhlIGV2ZW50cyB3aWxsIGJlIGRlZmluZXMgYnkgdGhlIGluZGl2aWR1YWwgTEZCcy4N Cg0KDQo2LjMuMiAgQ29uZmlnIFJlc3BvbnNlIE1lc3NhZ2UNCg0KICAgVGhpcyBtZXNzYWdlIGlz IHNlbnQgYnkgdGhlIEZFIHRvIHRoZSBDRSBpbiByZXNwb25zZSB0byB0aGUgQ29uZmlnDQogICBt ZXNzYWdlLiAgSXQgaW5kaWNhdGVzIHdoZXRoZXIgdGhlIENvbmZpZyB3YXMgc3VjY2Vzc2Z1bCBv ciBub3Qgb24NCiAgIHRoZSBGRSBhbmQgYWxzbyBnaXZlcyBhIGRldGFpbGVkIHJlc3BvbnNlIHJl Z2FyZGluZyB0aGUgY29uZmlndXJhdGlvbg0KICAgcmVzdWx0IG9mIGVhY2ggYXR0cmlidXRlLg0K DQogICBNZXNzYWdlIHRyYW5zZmVyIGRpcmVjdGlvbjoNCiAgICAgICBGRSB0byBDRQ0KICAgTWVz c2FnZSBIZWFkZXI6DQogICAgICAgVGhlIE1lc3NhZ2UgVHlwZSBpbiB0aGUgaGVhZGVyIGlzIHNl dCBNZXNzYWdlVHlwZT0gJ0NvbmZpZw0KICAgICAgIFJlc3BvbnNlJy4gIFRoZSBBQ0sgZmxhZyBp biB0aGUgaGVhZGVyIGlzIGFsd2F5cyBpZ25vcmVkLCBiZWNhdXNlDQogICAgICAgdGhlIGNvbmZp ZyByZXNwb25zZSBtZXNzYWdlIHdpbGwgbmV2ZXIgZXhwZWN0IHRvIGdldCBhbnkgbW9yZQ0KICAg ICAgIHJlc3BvbnNlIGZyb20gdGhlIG1lc3NhZ2UgcmVjZWl2ZXIgKENFKS4NCiAgIE1lc3NhZ2Ug Ym9keToNCiAgICAgICBUaGUgQ29uZmlnIHJlc3BvbnNlIG1lc3NhZ2UgYm9keSBjb25zaXN0cyBv ZiBvbmUgb3IgbW9yZSBUTFZzLA0KICAgICAgIHRoZSBmb3JtYXQgb2YgdGhlIFRMVnMvbWVzc2Fn ZSBpcyBhcyBmb2xsb3dzOg0KDQoNCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAg fCAgICAgICAgVHlwZSA9IExGQiBzZWxlY3QgICAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAg ICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg TEZCIENsYXNzIElEICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgIExGQiBJbnN0YW5jZSBJRCAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICBUeXBlID0gT3BlcmF0aW9ucyAo QUREKSAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiAgICAgfCAgICAgT3BlcmF0aW9uIFJlc3VsdCAgICAgICAgICB8ICAgICAgICAgICByZXNlcnZl ZCAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICBDb25maWcgUmVzdWx0ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC4NCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICBUeXBlID0gT3BlcmF0aW9ucyAoREVMKSAgICB8 ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAg ICAgT3BlcmF0aW9uIFJlc3VsdCAgICAgICAgICB8ICAgICAgICAgICByZXNlcnZlZCAgICAgICAg ICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICBDb25m aWcgUmVzdWx0ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxNw0KDQog ICBUeXBlICgxNiBiaXRzKToNCiAgICAgICBMRkIgU2VsZWN0Lg0KICAgTGVuZ3RoICgxNiBiaXRz KToNCiAgICAgICBMZW5ndGggb2YgdGhlIFRMViBpbmNsdWRpbmcgdGhlIFQgYW5kIEwgZmllbGRz LCBpbiBieXRlcy4NCiAgIExGQiBDbGFzcyBJRCAoMTYgYml0cyk6DQogICAgICAgVGhpcyBmaWVs ZCB1bmlxdWVseSByZWNvZ25pemVzIHRoZSBMRkIgY2xhc3MvdHlwZS4NCiAgIExGQiBJbnN0YW5j ZSBJRCAoMTYgYml0cyk6DQogICAgICAgVGhpcyBmaWVsZCB1bmlxdWVseSBpZGVudGlmaWVzIHRo ZSBMRkIgaW5zdGFuY2UuDQoNCiAgIFR5cGUgKDE2IGJpdHMpOg0KICAgICAgIFRoZSBvcGVyYXRp b25zIGFyZSBzYW1lIGFzIHRob3NlIGRlZmluZWQgZm9yIENvbmZpZyBtZXNzYWdlcy4NCg0KICAg TGVuZ3RoICgxNiBiaXRzKToNCiAgICAgICBMZW5ndGggb2YgdGhlIFRMViBpbmNsdWRpbmcgdGhl IFQgYW5kIEwgZmllbGRzLCBpbiBieXRlcy4NCiAgIE9wZXJhdGlvbiBSZXN1bHQgKDE2IGJpdHMp Og0KICAgICAgIFRoaXMgaW5kaWNhdGVzIHRoZSBvdmVyYWxsIHJlc3VsdCBvZiB0aGUgY29uZmln IG9wZXJhdGlvbiwgd2hldGhlcg0KICAgICAgIGl0IHdhcyBzdWNjZXNzZnVsIG9yIGl0IGZhaWxl ZC4NCiAgIENvbmZpZyBSZXN1bHQgKHZhcmlhYmxlIGxlbmd0aCk6DQogICAgICAgVGhpcyB3aWxs IGNhcnJ5IExGQiBzcGVjaWZpYyByZXN1bHRzIChzaW5nbGUgb3IgQXJyYXkgTEZCDQogICAgICAg c3BlY2lmaWMgcmVzdWx0IGVudHJpZXMpLiAgVGhlIGNvbmZpZyByZXN1bHQgbWlnaHQgaXRzZWxm IGJlIG9mDQogICAgICAgdGhlIGZvcm0gb2YgYSBUTFYuDQoNCg0KNi42LiAtPiBSZW1vdmUgdGhp cyBzZWN0aW9uDQoNCjYuNyAgSGVhcnRiZWF0IE1lc3NhZ2UNCg0KICAgVGhlIEhlYXJ0YmVhdCAo SEIpIE1lc3NhZ2UgaXMgdXNlZCBmb3Igb25lIEZvckNFUyBlbGVtZW50IChGRSBvciBDRSkNCiAg IHRvIGFzeW5jaHJvbm91c2x5IG5vdGlmeSBvbmUgb3IgbW9yZSBvdGhlciBGb3JDRVMgZWxlbWVu dHMgaW4gdGhlDQogICBzYW1lIEZvckNFUyBORSBvbiBpdHMgbGl2ZW5lc3MuDQoNCiAgIEEgSGVh cnRiZWF0IE1lc3NhZ2UgaXMgc2VudCBieSBhIEZvckNFUyBlbGVtZW50IHBlcmlvZGljYWxseS4g IFRoZQ0KICAgdGltZSBpbnRlcnZhbCB0byBzZW5kIHRoZSBtZXNzYWdlIGlzIHNldCBieSB0aGUg QXNzb2NpYXRpb24gU2V0dXANCiAgIE1lc3NhZ2UgZGVzY3JpYmVkIGluIFNlY3Rpb24gNi4xLjEu ICBBIGxpdHRsZSBkaWZmZXJlbnQgZnJvbSBvdGhlcg0KICAgcHJvdG9jb2wgbWVzc2FnZXMsIGEg SGVhcnRiZWF0IG1lc3NnZSBpcyBvbmx5IGNvbXBvc2VkIG9mIGEgY29tbW9uDQogICBoZWFkZXIs IHdpdGggdGhlIG1lc3NhZ2UgYm9keSBsZWZ0IGVtcHR5LiAgRGV0YWlsZWQgZGVzY3JpcHRpb24g b2YNCiAgIHRoZSBtZXNzYWdlIGlzIGFzIGJlbG93Lg0KICAgTWVzc2FnZSBUcmFuc2ZlciBEaXJl Y3Rpb246DQogICAgICAgRkUgdG8gQ0UsIG9yIENFIHRvIEZFDQogICBNZXNzYWdlIEhlYWRlcjoN CiAgICAgICBUaGUgTWVzc2FnZSBUeXBlIGluIHRoZSBtZXNzYWdlIGhlYWRlciBpcyBzZXQgdG8g TWVzc2FnZVR5cGUgPQ0KICAgICAgICdIZWFydGJlYXQnLiAgVGhlIEFDSyBmbGFnIGluIHRoZSBo ZWFkZXIgU0hPVUxEIGJlIHNldCB0bw0KICAgICAgICdOb0FDSycsIG1lYW5pbmcgbm8gcmVzcG9u c2UgZnJvbSByZWNlaXZlcihzKSBpcyBleHBlY3RlZCBieSB0aGUNCiAgICAgICBtZXNzYWdlIHNl bmRlci4gIE90aGVyIHZhbHVlcyBvZiB0aGUgQUNLIGZsYWcgd2lsbCBhbHdheXMgYmUNCiAgICAg ICBpZ25vcmVkIGJ5IHRoZSBtZXNzYWdlIHJlY2VpdmVyLg0KICAgTWVzc2FnZSBCb2R5Og0KICAg ICAgIFRoZSBtZXNzYWdlIGJvZHkgaXMgZW1wdHkgZm9yIHRoZSBIZWFydGJlYXQgTWVzc2FnZSwg c28gYXMgdG8NCiAgICAgICBncmFzcCBtb3JlIGVmZmljaWVuY3kgZm9yIG1lc3NhZ2UgdHJhbnNw b3J0YXRpb24gYW5kIHByb2Nlc3NpbmcuDQoNCg0KDQoNCg== ------_=_NextPart_001_01C4B8A1.027CA750 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol ------_=_NextPart_001_01C4B8A1.027CA750-- From forces-protocol-bounces@ietf.org Fri Oct 22 22:07:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23948 for ; Fri, 22 Oct 2004 22:07:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLBWm-0003Aa-6R for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 22:21:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLBEe-00015q-Cp; Fri, 22 Oct 2004 22:02:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLBBM-0007xp-RD for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 21:59:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22080 for ; Fri, 22 Oct 2004 21:59:00 -0400 (EDT) From: avri@acm.org Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLBOI-00031o-2A for forces-protocol@ietf.org; Fri, 22 Oct 2004 22:12:23 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9N1Ybep028222; Sat, 23 Oct 2004 03:34:38 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0257920E@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0257920E@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1810BAF0-2497-11D9-9DB1-000393CC2112@acm.org> Content-Transfer-Encoding: 7bit Date: Fri, 22 Oct 2004 21:58:54 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , "Wang, Weiming" , Robert Haas Subject: [Forces-protocol] Re: draft update.... X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit ouch. ok, i just integrated Weiming's xml in. the problem was it had a bunch of syntactic problems. i think xml2rfc is a lot stricter then oxygen. http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-2.txt i will integrate your further changes in later - in a few hours. please - everyone - let me know which changes belong in. please flag the messages with changes that are supposed to go in. the constant messages with 2 copies each is blowing my mind - or at least my concentration. i need some definite clues. a. On 22 okt 2004, at 21.38, Khosravi, Hormuzd M wrote: > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 22:49:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06383 for ; Fri, 22 Oct 2004 22:49:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLCAi-0003pC-BZ for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 23:02:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLBws-00048L-PZ; Fri, 22 Oct 2004 22:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLBvl-0003gy-2T for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 22:46:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06306 for ; Fri, 22 Oct 2004 22:46:56 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLC8h-0003mg-Lu for forces-protocol@ietf.org; Fri, 22 Oct 2004 23:00:20 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102219492484:38705 ; Fri, 22 Oct 2004 19:49:24 -0700 Subject: RE: [Forces-protocol] FE Protocol LFBs From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02FD8F49@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02FD8F49@orsmsx408> Organization: ZNYX Networks Message-Id: <1098499610.1097.21.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Oct 2004 22:46:51 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/22/2004 07:49:25 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/22/2004 07:49:28 PM, Serialize complete at 10/22/2004 07:49:28 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, avri@psg.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Hormuzd, Hold that thought; I think given the way things are going, the FE object and Protocol LFBs may become beasts that deserve their own drafts. Same with the redirector that Weiming is talking about. For now lets hold them in the draft as is, but there should certainly be opportunity for them to go out and coauthored by people other than the model team. cheers, jamal On Fri, 2004-10-22 at 12:30, Khosravi, Hormuzd M wrote: > Weiming, All > > We should definitely define these LFBs related with FE, Protocol, etc as > part of the protocol draft. There is no need to have them in a separate > draft > > Regards > Hormuzd > > -----Original Message----- > From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn] > > > > > Also dont forget to look at the overview section in the latest draft > > posted by Avri. Theres a little refinement of the split of the two > LFBs > > (each in its own section). > > As to what to do about the FE Object and FE Protocol object, My > opinion > > is we should define everything taht we think we will need. > > I would think the model team will take those needs and make sure its > > part of the XML spec. Weiming, are you suggesting to do the xml from > us? > [Weiming] Yes, but I'm not sure if it should be defined inside this > protocol > text or just by another draft. I remember you also mentioned such > thought > before. We actually have the same question on Redirect LFBs, anyway any > LFB like > things that between FE model and protocol. Now it seems very popular to > summarize everything as LFB, I even think of TML layer as LFBs from PL > layer, > but not sure. > > cheers, > weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 22 23:05:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06934 for ; Fri, 22 Oct 2004 23:05:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLCQe-00041J-8r for forces-protocol-web-archive@ietf.org; Fri, 22 Oct 2004 23:18:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLCBP-00024A-7W; Fri, 22 Oct 2004 23:03:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLC6r-0008Ec-Pr for forces-protocol@megatron.ietf.org; Fri, 22 Oct 2004 22:58:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06678 for ; Fri, 22 Oct 2004 22:58:24 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLCJn-0003vx-Mm for forces-protocol@ietf.org; Fri, 22 Oct 2004 23:11:49 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102220005399:38718 ; Fri, 22 Oct 2004 20:00:53 -0700 Subject: RE: [Forces-protocol] Header Section From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02FD9935@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02FD9935@orsmsx408> Organization: ZNYX Networks Message-Id: <1098500299.1255.33.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Oct 2004 22:58:19 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/22/2004 08:00:54 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/22/2004 08:00:56 PM, Serialize complete at 10/22/2004 08:00:56 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit On Fri, 2004-10-22 at 19:11, Khosravi, Hormuzd M wrote: > Jamal, > > Pls take care of the Header section, no one seems to be looking at it. > Hormuzd, Main comment on header was todo with version to remove the major minor and just have one flat space. The other thing i dont remember is whether we should get rid of the resvd field or not. Some of the falgs need revisiting; however i think the revisit will make more sense once the operations and data-path dust settles. So my suggestion is lets have Avri make the changes to the major:minor and probably get rid of the resvd field and leave the rest for the next round. Thoughts? cheers, jamal > Thanks > Hormuzd > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > Robert,Weiming, Ligang: Are you taking care of the common header section > or should i jump into that next? Not that i think there are any useful > changes tomake for this version of draft. > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 00:19:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10481 for ; Sat, 23 Oct 2004 00:19:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLDZx-0005C9-A7 for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 00:32:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLDJo-0006GZ-B4; Sat, 23 Oct 2004 00:15:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLDE2-0003u0-Ck for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 00:09:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10124 for ; Sat, 23 Oct 2004 00:09:51 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLDOx-00051S-VK for forces-protocol@ietf.org; Sat, 23 Oct 2004 00:23:16 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Sat, 23 Oct 2004 12:26:04 +0800 (CST) Received: from wwm1 (unverified [219.82.191.210]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Sat, 23 Oct 2004 12:02:13 +0800 Message-ID: <009801c4b8b6$36ce1290$020aa8c0@wwm1> From: "Weiming Wang" To: "Robert Haas" , References: <468F3FDA28AA87429AD807992E22D07E02579209@orsmsx408> <420441FF-23F7-11D9-9DB1-000393CC2112@acm.org> <108701c4b84a$8028ba60$845c21d2@Necom.hzic.edu.cn> <4179571E.2080400@zurich.ibm.com> Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Date: Sat, 23 Oct 2004 12:10:15 +0800 MIME-Version: 1.0 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 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 933574082e9c73b77c13a13d45bce65c Cc: "Khosravi, Hormuzd M" , Jamal Hadi Salim , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0145242418==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 3.8 (+++) X-Scan-Signature: b7c2fe1bf2b2832414a99e02b4d267aa This is a multi-part message in MIME format. --===============0145242418== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01C4B8F9.4151BDA0" This is a multi-part message in MIME format. ------=_NextPart_000_0090_01C4B8F9.4151BDA0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpJIGZpbmQgbW9zdCBvZiB5b3VyIGNvbW1lbnRzIGFyZSB2YWx1YWJsZS4g SSdtIHRyeWluZyB0byBpbmNvcnBhcmF0ZSBpdC4NCg0KQXZyaSwgDQoNCkRvIHlvdSB3YW50IG1l IHRvIG1ha2UgdGhlIGNoYW5nZXMgb3IgeW91IG1ha2UgaXQ/IElmIGZvcm1lciwgcGxzIHNlbmQg bWUgYmFjayB0aGUgbW9kaWZpZWQgWE1MIGZpbGVzIEkganVzdCB1cGRhdGVkLg0KSWYgbGF0dGVy LCBJIHdpbGwgbWFyayB0aGUgY2hhbmdlcy4NCg0KUGxzIHJlcGx5IG1lIGFzYXAgd2hlbiB5b3Ug c2VlIHRoaXMuIFRoYW5rcy4NCg0KV2VpbWluZw0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tIA0KICBGcm9tOiBSb2JlcnQgSGFhcyANCiAgVG86IFdhbmcsV2VpbWluZyANCiAgQ2M6IGF2 cmlAYWNtLm9yZyA7IEtob3NyYXZpLCBIb3JtdXpkIE0gOyBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5v cmcgOyBMaWdhbmcgRG9uZyA7IHJhbS5nb3BhbEBub2tpYS5jb20gOyBKYW1hbCBIYWRpIFNhbGlt IA0KICBTZW50OiBTYXR1cmRheSwgT2N0b2JlciAyMywgMjAwNCAyOjUzIEFNDQogIFN1YmplY3Q6 IFJlOiBbRm9yY2VzLXByb3RvY29sXSBSRTogZHJhZnQtaWV0Zi1mb3JjZXMtcHJvdG9jb2wtMDEt MC50eHQNCg0KDQogIFdlaW1pbmcsDQogIEkgaGF2ZSBhIGZldyBzdWdnZXN0aW9ucyBmb3IgeW91 ciBzZWN0aW9ucy4gU2VlIGlubGluZS4gUGxlYXNlIHJldmlldyB0aGVtIGFuZCBpbmRpY2F0ZSB0 byBBdnJpIGlmIHNoZSBzaG91bGQgaW5jb3Jwb3JhdGUgdGhlc2UgaW50byB0aGUgZmluYWwgZHJh ZnQuIEl0IHdvdWxkIGJlIGdvb2QgaWYgQXZyaSBjb3VsZCBkbyB0aGUgZW5nbGlzaC1jaGVjayBv biB0aGVzZSBzZWN0aW9ucyB0byBhcyBJIGFtIG5vdCBhIG5hdGl2ZSBlbmdsaXNoIHNwZWFrZXIg bmVpdGhlcg0KICBSZWdhcmRzLA0KICAtUm9iZXJ0DQoNCiAgV2FuZyxXZWltaW5nIHdyb3RlOg0K DQpIaSBBdnJpLA0KDQpJJ3YgdXBkYXRlZCB0aGUgUmVkaXJlY3RNc2csIFF1ZXJ5TXNnLCBhbmQg RXZlbnRNc2cgYXMgWE1MIGZpbGUgaW4gdGhlDQphdHRhY2htZW50cy4gSXQncyBhIHBpdHkgdGhh dCBJIGp1c3QgZmluZCBJIGNhbiBub3QgcGFzcyB0byBwYXJzZSB0aGUgZmlsZSBieQ0KeG1sMnJm YyBiZWNhdXNlIGl0IGluY2x1ZGVkIHNvbWUgb2YgdGhlIGZvcm1hdCBkZWZpbmVkIGJ5IHlvdSwg dGhlcmVmb3JlIGl0DQpzZWVtcyBJIGNhbiBub3QgdmVyaWZ5IHRoZSBjb3JyZWN0bmVzcyBvZiB0 aGUgIGZpbGUgZm9yIHRoZSB4bWwgZm9ybWF0LiBJIHJlYWxseQ0Kd2FudCB0byBzYXZlIHNvbWUg b2YgeW91ciB3b3JrIGJ1dCBpdCBzZWVtcyBJJ20gbm90IGFibGUgdG8uIElmIHlvdSBsaWtlLCBu ZXh0DQp0aW1lIEkgd291bGQganVzdCB1c2UgdHh0IGxpa2UgSG9ybXV6ZCBkaWQuDQoNClRoZXJl IGlzIG5vIGNoYW5nZSB0byB0aGUgZGVmaW5pdGlvbiBwYXJ0Lg0KDQpIb3JtdXpkLCBJIGhhdmUg bW9zdGx5IHRyaWVkIGJlc3QgdG8gZm9sbG93IHlvdXIgZm9ybWF0LCBidXQgc3RpbGwgdGhlcmUg YXJlDQpzb21lIHBsYWNlcyB0aGF0IEkgcHJlZmVyIG15IHN0eWxlLiBBbnl3YXksIGl0IG1hdHRl cnMgbGVzcy4NCg0KdGhhbmsgeW91Lg0KV2VpbWluZw0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLQ0KRnJvbTogPGF2cmlAYWNtLm9yZz4NCiAgT24gMjIgb2t0IDIwMDQsIGF0IDAyLjE5LCBL aG9zcmF2aSwgSG9ybXV6ZCBNIHdyb3RlOg0KDQogICAgSSBzZW50IHlvdSB0aGUgZW50aXJlIHNl Y3Rpb24gc28geW91IGNhbiBqdXN0IHB1dCBpdCBpbi4gWW91IGRvbid0IGhhdmUNCnRvIGZpbmQg YW55IGRpZmZzLiBJIGhhdmUgYXR0YWNoZWQgaXQgYWdhaW4gZm9yIHlvdXIgY29udmVuaWVuY2Uu DQogICAgICBkb2Vzbid0IHF1aXRlIHdvcmsgbGlrZSB0aGF0Lg0KYnV0IGkgaGF2ZSBwdXQgaW4g dGhlIGNoYW5nZXMgYXMgZmFyIGFzIGkgY2FuIHRlbGwuIGNoZWNrIHRvIG1ha2Ugc3VyZQ0KaSBn b3QgaXQgcmlnaHQuDQoNCmh0dHA6Ly9wc2cuY29tL35hdnJpL2ZvcmNlcy9kcmFmdC9kcmFmdC1p ZXRmLWZvcmNlcy1wcm90b2NvbC0wMS0xLnR4dA0KDQogICAgQlRXLCB3aGVyZSBhcmUgeW91IGF0 IHRoaXMgbW9tZW50PyBpbiB0aGUgVVMgb3IgRXVyb3BlPyBKdXN0IGN1cmlvdXMgaW4NCmNhc2Ug d2UgbmVlZCB0byBzZXR1cCBzb21lIGNvbmZlcmVuY2UgY2FsbHMuDQogICAgICB0aGlzIHdlZWsg aW4gdGhlIHVzIC0gZWFzdCBjb2FzdC4NCg0KYS4NCg0KICAgIA0KDQogIDw/eG1sIHZlcnNpb249 IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DQo8IS0tIGVkaXRlZCB3aXRoIDxPWHlnZW4vPlhNTCBl ZGl0b3IgNC4xLCBieSBXZWltaW5nIFdhbmcgJiBMaWdhbmcgRG9uZyANCiAgICAgKioqIFJlZGly ZWN0TXNnIFYxLjAsIDIwMDQtMDYtMTMsIGNoYW5nZXMgc2luY2UgbGFzdCB2ZXJzaW9uOg0KICAg ICAtIE5vbmUsIGFzIHRoZSBvcmlnaW5hbCB2ZXJzaW9uLg0KICAgICAqKiogUmVkaXJlY3RNc2dW MS4xLCAyMDA0LTA2LTE4Lg0KLS0+DQoNCjxzZWN0aW9uIGFuY2hvcj0iUmVkaXJlY3RNc2ciIHRp dGxlPSJQYWNrZXQgUmVkaXJlY3QgTWVzc2FnZSI+DQoNCjx0PlBhY2tldCByZWRpcmVjdCBtZXNz YWdlIGlzIHVzZWQgdG8gdHJhbnNmZXIgZGF0YSBwYWNrZXRzIA0KICAgIGJldHdlZW4gQ0UgYW5k IEZFLiBVc3VhbGx5IHRoZXNlIGRhdGEgcGFja2V0cyBhcmUgSVAgcGFja2V0cywgDQogICAgdGhv dWdoIHRoZXkgbWF5IHNvbWV0aW1lcyBhc3NvY2lhdGVkIHdpdGggc29tZSBtZXRhZGF0YSANCiAg ICBnZW5lcmF0ZWQgYnkgb3RoZXIgTEZCcyBpbiB0aGUgbW9kZWwsIG9yIHRoZXkgbWF5IA0KICAg IG9jY2FzaW9uYWxseSBiZSBvdGhlciBwcm90b2NvbCBwYWNrZXRzLCB3aGljaCB1c3VhbGx5IGhh cHBlbiANCiAgICB3aGVuIENFIGFuZCBGRSBhcmUgam9pbnRseSBpbXBsZW1lbnRpbmcgc29tZSBo aWdoLXRvdWNoIA0KICAgIG9wZXJhdGlvbnMuIFBhY2tldHMgcmVkaXJlY3RlZCBmcm9tIEZFIHRv IENFIGFyZSB0aGUgZGF0YSANCiAgICBwYWNrZXRzIHRoYXQgY29tZSBmcm9tIGZvcndhcmRpbmcg cGxhbmUsIGFuZCB1c3VhbGx5IGFyZSB0aGUgDQogICAgZGF0YSBwYWNrZXRzIHRoYXQgbmVlZCBo aWdoLXRvdWNoIG9wZXJhdGlvbnMgaW4gQ0UuIC4uLiBvciBwYWNrZXRzIGZvciB3aGljaCB0aGUg SVAgZGVzdGluYXRpb24gYWRkcmVzcyBpcyB0aGUgTkUuIFtOb3RlIHRoYXQgSSBkaXN0aW5ndWlz aCBoaWdoLXRvdWNoIG9wZXJhdGlvbnMgZnJvbSBlbmRwb2ludCBwcm90b2NvbCBwcm9jZXNzaW5n XQ0KDQogUGFja2V0cyANCiAgICByZWRpcmVjdGVkIGZyb20gQ0UgdG8gRkUgYXJlIHRoZSBkYXRh IHBhY2tldHMgdGhhdCBhcmUgDQogICAgZ2VuZXJhdGVkIGJ5IENFIGFuZCBhcmUgZGVjaWRlZCBi eSBDRSB0byBwdXQgaW50byBmb3J3YXJkaW5nIA0KICAgIHBsYW5lIGluIEZFLjwvdD4NCg0KICBk b24ndCB3cml0ZSAiZ2VuZXJhdGVkIGJ5IHRoZSBDRSIuIFN1Y2ggcGFja2V0cyBjb3VsZCB2ZXJ5 IHdlbGwgYmUgcGFja2V0cyB0aGF0IGluaXRpYWxseSB3ZXJlIHJlZGlyZWN0ZWQgZnJvbSBhbiBG RS4gSW5zdGVhZCwganVzdCBzYXkgImNvbWUgZnJvbSB0aGUgQ0UiLg0KDQo8dD5CeSBwcm9wZXJs eSBjb25maWd1cmluZyByZWxhdGVkIExGQnMgaW4gRkUsIGEgcGFja2V0IGNhbiBhbHNvIA0KICAg IGJlIG1pcnJvcmVkIHRvIENFIGluc3RlYWQgb2YgcHVyZWx5IHJlZGlyZWN0ZWQgdG8gQ0UsIGku ZS4sIA0KICAgIHRoZSBwYWNrZXQgaXMgZHVwbGljYXRlZCBhbmQgb25lIGlzIHJlZGlyZWN0ZWQg dG8gQ0UgYW5kIHRoZSANCiAgICBvdGhlciBjb250aW51ZXMgaXRzIHdheSBpbiB0aGUgTEZCIHRv cG9sb2d5LiA8L3Q+DQoNCiAgU2lkZSBub3RlOiB3ZSB3aWxsIGhhdmUgdG8gZGVmaW5lIGhvdyB0 aGUgcGFja2V0IGhlYWRlciBvbmx5IGNhbiBiZSBwYXNzZWQgdG8gdGhlIENFLCBhbmQgbGVhdmUg dGhlIHBheWxvYWQgaW4gdGhlIEZFLCB1bnRpbCB0aGUgQ0UgZGVjaWRlcyB3aGF0IHRvIGRvIHdp dGggdGhlIHBhY2tldC4NCg0KICBTZWNvbmQgc2lkZSBub3RlOiB3ZSBuZWVkIHRvIHNwZWNpZnkg d2h5IHdlIGNvbnNpZGVyIHRoYXQgcGFja2V0X3JlZGlyZWN0IGRlc2VydmVzIGl0cyBvd24gbWVz c2FnZSB0eXBlLCBhbmQgbm90IHNpbXBseSBiZSB0cmVhdGVkIGFzIGFuIGV2ZW50IGZpcmVkIGJ5 IHRoZSBSZWRpcmVjdCBMRkIgdGhhdCBjb250YWlucywgYXMgcGFydCBvZiB0aGUgZXZlbnQgZGF0 YSwgdGhlIHBhY2tldCBpdHNlbGYuIE15IHRoaW5raW5nIGlzIHRoYXQgdXNpbmcgYSBzcGVjaWZp YyBtZXNzYWdlIHR5cGUgaXMgaW1wb3J0YW50IHRvIGxldCB0aGUgQ0UgZGlzdGluZ3Vpc2ggcHJv bXB0bHkgaWYgdGhlIG1lc3NhZ2UgaXMgYW4gRkUtaW50ZXJuYWwgZXZlbnQgb3IgYW4gZXh0ZXJu YWwgcGFja2V0IHRoYXQgd2FzIGp1c3QgZm9yd2FyZGVkLiBTb21ldGhpbmcgbGlrZSB0aGlzIHNo b3VsZCBiZSB3cml0dGVuIGluIHRoZSBpbnRybyBvZiB0aGlzIHNlY3Rpb24uIFdlaW1pbmcgPw0K DQo8dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8+DQo8bGlzdCBzdHlsZT0iaGFuZ2luZyIgaGFuZ0lu ZGVudD0iMTciPg0KPHQgaGFuZ1RleHQgPSAiRWRpdG9yaWFsIE5vdGU6ICI+IA0KVGhlcmUgYXJl IGFsc28gZGlzY3Vzc2lvbnMgb24gaG93IExGQnMgaW4gRkUgbW9kZWwgdGhhdCBhcmUgDQogICAg cmVsYXRlZCB0byBwYWNrZXQgcmVkaXJlY3Qgb3BlcmF0aW9ucyBzaG91bGQgYmUgZGVmaW5lZC4g QWx0aG91Z2ggDQogICAgaXQgaXMgb3V0IG9mIHRoZSBzY29wZSBvZiBmb3JjZXMgcHJvdG9jb2ws IGhvdyB0byBkZWZpbmUgdGhlIExGQnMgDQogICAgYWZmZWN0IHRoZSBQYWNrZXQgUmVkaXJlY3Qg TWVzc2FnZSBkZXNjcmliZWQgaGVyZS4gQmVjYXVzZSBjdXJyZW50bHkNCiAgICBpdCBpcyBzdGls bCBpbiBwcm9ncmVzcyBpbiBGRSBtb2RlbCBvbiBob3cgdG8gZGVmaW5lIHN1Y2ggTEZCcywgDQog ICAgd2UgdHJ5IHRvIHBvc3Qgc29tZSB0aG91Z2h0cyBvbiB0aGlzIGhlcmUgZm9yIGRpc2N1c3Np b24uIFRoZXkgDQogICAgd2lsbCBiZSByZW1vdmVkIGxhdGVyIGFsb25nIHdpdGggdGhlIHByb2dy ZXNzIG9mIHRoZSBGRSBtb2RlbCB3b3JrLg0KPC90Pg0KPHZzcGFjZSBibGFua0xpbmVzPSIxIiAv Pg0KPHQgaGFuZ1RleHQgPSIgICAgIFRob3VnaHQgMTogIj4NClRvIGRlZmluZSBMRkJzIGNhbGxl ZCAnUmVkaXJlY3RTaW5rJyBhbmQgJ1JlZGlyZWN0VGFwJyBmb3INCnBhY2tldCByZWRpcmVjdC48 L3Q+DQo8dD5BbiBMRkIgaW4gRkUgY2FsbGVkICdSZWRpcmVjdFNpbmsnIGlzIHJlc3BvbnNpYmxl IHRvIGNvbGxlY3QgDQogICAgZGF0YSBwYWNrZXRzIHRoYXQgbmVlZCB0byBiZSByZWRpcmVjdGVk IHRvIENFLiBGcm9tIHRoZSANCiAgICBwZXJzcGVjdGl2ZSBvZiB0aGUgRkUgTEZCIHRvcG9sb2d5 LCB0aGUgJ1JlZGlyZWN0U2luaycgTEZCIA0KICAgIGlzIGFuIExGQiB3aXRoIG9ubHkgb25lIGlu cHV0IHBvcnQgYW5kIHdpdGhvdXQgYW55IG91dHB1dCANCiAgICBwb3J0LCBhbmQgdGhlIGlucHV0 IHBvcnQgY2FuIHRoZW4gYmUgY29ubmVjdGVkIHRvIGFueSBvdGhlciANCiAgICBMRkIgaW4gRkUg bW9kZWwgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0aGUgZm9yd2FyZGluZyANCiAgICBwbGFu ZS4gRnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdGhlIEZvckNFUyBwcm90b2NvbCBsYXllciwgDQog ICAgdGhlICdSZWRpcmVjdFNpbmsnIExGQiB3aWxsIGdlbmVyYXRlIHRoZSBQYWNrZXQgUmVkaXJl Y3QgDQogICAgTWVzc2FnZXMgd2hlbiBpdCByZWNlaXZlcyBkYXRhIHBhY2tldHMgZnJvbSBmb3J3 YXJkaW5nIHBsYW5lLg0KPC90Pg0KPHZzcGFjZSBibGFua0xpbmVzPSIxIiAvPg0KPHQ+QW4gTEZC IGluIEZFIGNhbGxlZCAnUmVkaXJlY3RUYXAnIGlzIHJlc3BvbnNpYmxlIHRvIHJlY2VpdmUgDQog ICAgZGF0YSBwYWNrZXRzIHRoYXQgYXJlIHJlZGlyZWN0ZWQgZnJvbSBDRS4gRnJvbSB0aGUgcGVy c3BlY3RpdmUgDQogICAgb2YgdGhlIEZFIExGQiB0b3BvbG9neSwgdGhlICdSZWRpcmVjdFRhcCcg TEZCIGlzIGFuIExGQiB3aXRoIA0KICAgIG9ubHkgb25lIG91dHB1dCBwb3J0IGFuZCB3aXRob3V0 IGFueSBpbnB1dCBwb3J0LCBhbmQgdGhlIA0KICAgIG91dHB1dCBwb3J0IGNhbiB0aGVuIGJlIGNv bm5lY3RlZCB0byBhbnkgb3RoZXIgTEZCIGluIEZFIA0KICAgIG1vZGVsIGJ5IG1lYW5zIG9mIGEg ZGF0YXBhdGggaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuIEZyb20gDQogICAgdGhlIHBlcnNwZWN0 aXZlIG9mIEZvckNFUyBwcm90b2NvbCBsYXllciwgdGhlICdSZWRpcmVjdFRhcCcgDQogICAgTEZC IGNhbiByZWNlaXZlIHRoZSBQYWNrZXQgUmVkaXJlY3QgTWVzc2FnZXMgZnJvbSBDRSwgYW5kIA0K ICAgIHVuLWVuY2Fwc3VsYXRlIHRoZSBkYXRhIHBhY2tldHMgZnJvbSB0aGUgbWVzc2FnZSBhbmQg cHV0IA0KICAgIHRoZW0gdG8gZGF0YXBhdGhzIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lLiBBY3R1 YWxseSB0aGUgDQogICAgJ1JlY2lyZWN0VGFwJyBMRkIgYWN0cyBtb3JlIGxpa2UgYSB0cmFuc2Nv ZGVyIHRoYXQgdHJhbnNmZXJzIA0KICAgIHRoZSBGb3JDRVMgcHJvdG9jb2wgbWVzc2FnZXMgdG8g bm9ybWFsIGRhdGEgcGFja2V0cyBpbiBJUCANCiAgICBmb3J3YXJkaW5nIHBsYW5lLiBBcyBhIHJl c3VsdCwgaWYgd2UgbmVlZCB0byBoYXZlIHJlZGlyZWN0ZWQgDQogICAgcGFja2V0cyBjb25uZWN0 ZWQgdG8gc29tZSBMRkIgKHNheSBhIFNjaGVkdWxlcikgaW4gRkUgbW9kZWwsIA0KICAgIHdlIG9u bHkgbmVlZCB0byBjb25uZWN0IHRoZSAnUmVkaXJlY3RUYXAgTEZCIHRvIHRoZSBTY2hlZHVsZXIg DQogICAgTEZCIGRpcmVjdGx5IHZpYSBhIGRhdGFwYXRoIGFzIGZvbGxvd3M6DQo8dnNwYWNlIGJs YW5rTGluZXM9IjEiIC8+DQo8ZmlndXJlIGFuY2hvcj0iTEZCX1JlZGlyZWN0Ij48YXJ0d29yaz4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICArLS0t LS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgIHwgUmVkaXJlY3RUYXAgTEZCIHwt LS0tLS0+fCAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tLS0rICAgICAgIHwgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IFNjaGVkdWxlciB8DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBGcm9tIG90aGVyIExGQiAgIC0tLS0+fCAgICBMRkIgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0rDQo8L2FydHdvcms+PC9maWd1cmU+DQo8L3Q+DQo8dnNwYWNlIGJsYW5rTGlu ZXM9IjEiIC8+DQo8dD5CeSB1c2Ugb2Ygc2V2ZXJhbCAnUmVkaXJlY3RTaW5rJyBMRkJzIGFuZCBz ZXZlcmFsICdSZWRpcmVjdFRhcCcgDQogICAgTEZCcyB0aGF0IGNvbm5lY3QgdG8gc2V2ZXJhbCBk aWZmZXJlbnQgZGF0YXBhdGhzIGluIEZFIA0KICAgIGZvcndhcmRpbmcgcGxhbmUsIG11bHRpcGxl IHBhY2tldCByZWRpcmVjdCBwYXRocyBiZXR3ZWVuIA0KICAgIENFIGFuZCBGRSBjYW4gYmUgY29u c3RydWN0ZWQuIDwvdD4NCjx2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLz4NCjx0IGhhbmdUZXh0ID0i ICAgICBUaG91Z2h0IDI6ICI+DQogICAgVGhlcmUgbWlnaHQgYmUgYW5vdGhlciB3YXkgYSBwYWNr ZXQgY291bGQgYmUgcmVkaXJlY3RlZDoNCiAgICBkaXJlY3RseSBieSBhIGZvcndhcmRpbmcgcGF0 aCwgZS5nLiwgYnkgRlBHQS9BU0lDL05QIG1pY3JvY29kZS4gSW4gDQogICAgc3VjaCBhIGNhc2Ug d2UgZG8gbm90IG5lZWQgdG8gcHV0IGluIGEgbG90IG9mIHNtYXJ0bmVzcy4gUHJvYmFibHkgDQog ICAgYSBsaW5rIGxheWVyIG9yIGV2ZW4gbmV0d29yayBsZXZlbCBoZWFkZXIgaXMgZW5vdWdoLiBU aGUgcmVjZWl2ZXIgDQogICAgZGVtdXhlcyBpdCBvbmx5IGJhc2VkIG9uIHNvbWUgcHJvdG9jb2wg dHlwZSBpbiB0aGUgbGluayBsYXllciBvciANCiAgICBuZXR3b3JrIHRyYW5zcG9ydCBsYXllci4g VGhlIHByb3MgZm9yIHRoaXMgYXBwcmFvY2ggaXMgaXQgbWF5IA0KICAgIHByb3ZpZGUgYSBmYXN0 IGFuZCBjb3N0LWVmZmVjdGl2ZSBwYXRoIGZvciBwYWNrZXQgcmVkaXJlY3QuIFRoZSANCiAgICBj b25zIGZvciB0aGlzIGlzIGl0IG1heSBtb3JlIG9yIGxlc3MgY29uZnVzZXMgdGhlIEZwIHJlZmVy ZW5jZSANCiAgICBwb2ludCBkZWZpbml0aW9uIGluIEZvckNFUyBmcmFtZXdvcmsuIA0KPC90Pg0K PC9saXN0Pg0KPHZzcGFjZSBibGFua0xpbmVzPSIxIiAvPg0KPHQ+V2UgZGVzY3JpYmUgdGhlIFBh Y2tldCBSZWRpcmVjdCBNZXNzYWdlIGRhdGEgZm9ybWF0IGluIGRldGFpbHMgDQogICAgYXMgZm9s bG93czo8L3Q+DQo8bGlzdCBzdHlsZT0iaGFuZ2luZyIgaGFuZ0luZGVudD0iMSI+DQo8dCBoYW5n VGV4dD0gIk1lc3NhZ2UgRGlyZWN0aW9uOiAgIj48dnNwYWNlIC8+DQpDRSB0byBGRSBvciBGRSB0 byBDRQ0KPC90Pg0KDQoNCjx0IGhhbmdUZXh0PSAiTWVzc2FnZSBIZWFkZXI6ICAiPjx2c3BhY2Ug Lz4NClRoZSBNZXNzYWdlIFR5cGUgaW4gdGhlIGhlYWRlciBpcyBzZXQgdG8gDQogICAgTWVzc2Fn ZVR5cGU9ICdQYWNrZXRSZWRpcmVjdCcuIFRoZSBBQ0sgZmxhZ3MgaW4gdGhlIGhlYWRlciANCiAg ICBTSE9VTEQgYmUgc2V0ICdOb0FDSycsIG1lYW5pbmcgbm8gcmVzcG9uc2UgaXMgZXhwZWN0ZWQg YnkgdGhpcyANCiAgICBtZXNzYWdlLiBJZiB0aGUgQUNLIGZsYWcgaXMgc2V0IG90aGVyIHZhbHVl cywgdGhlIA0KICAgIG1lYW5pbmdzIHdpbGwgYmUgaWdub3JlZC4NCjwvdD4NCg0KDQo8dCBoYW5n VGV4dD0gIk1lc3NhZ2UgQm9keTogIj48dnNwYWNlIC8+DQpDb25zaXN0cyBvZiBvbmUgb3IgbW9y ZSBUTFZzLCB3aXRoIGV2ZXJ5IFRMViBoYXZpbmcgdGhlIA0KICAgIGZvbGxvd2luZyBkYXRhIGZv cm1hdDoNCjwvdD4NCg0KICA8ZmlndXJlIGFuY2hvcj0idGx2X1JlZGlyZWN0X0RhdGEiPg0KPGFy dHdvcms+DQogICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICBUeXBlID0g TEZCc2VsZWN0ICAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBMRkIgQ2xhc3MgSUQgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgTEZCIEluc3RhbmNlIElEICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgT3BlcmF0aW9pbiBUTFYg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAuICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K ICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgT3BlcmF0aW9pbiBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAuICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Lg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KICANCjwvYXJ0d29yaz48L2ZpZ3VyZT4NCg0KPHQgaGFuZ1RleHQ9 ICJMRkIgY2xhc3MgSUQ6ICI+PHZzcGFjZSAvPg0KVGhlcmUgYXJlIG9ubHkgdHdvIHBvc3NpYmxl IExGQiBjbGFzc2VzIGhlcmUsIHRoZSANCiAgICAnUmVkaXJlY3RTaW5rJyBMRkIgb3IgdGhlICdS ZWRpcmVjdFRhcCcgTEZCLiBJZiB0aGUgbWVzc2FnZSBpcyANCiAgICBmcm9tIEZFIHRvIENFLCB0 aGUgTEZCIGNsYXNzIHNob3VsZCBiZSAnUmVkaXJlY3RTaW5rJy4gSWYgdGhlIA0KICAgIG1lc3Nh Z2UgaXMgZnJvbSBDRSB0byBGRSwgdGhlIExGQiBjbGFzcyBzaG91bGQgYmUgJ1JlZGlyZWN0VGFw Jy4NCjwvdD4NCg0KICBXaHkgcmVzdHJpY3QgdGhpcyA/IElmIGFueSBvdGhlciBMRkIgd2FudHMg dG8gZ2VuZXJhdGUgYSBwYWNrZXQgcmVkaXJlY3QgdG8gdGhlIENFLCBsZXQgaGltIGRvIGl0ICEN Cg0KPHQgaGFuZ1RleHQ9ICJJbnN0YW5jZSBJRDogIj48dnNwYWNlIC8+DQpJbnN0YW5jZSBJRCBm b3IgdGhlICdSZWRpcmVjdFNpbmsnIExGQiBvciAnUmVkaXJlY3RUYXAnIExGQi4NCjwvdD4NCg0K DQo8dCBoYW5nVGV4dD0gIk9wZXJhdGlvbiBUTFY6ICI+PHZzcGFjZSAvPg0KVGhpcyBpcyBhIFRM ViBkZXNjcmliaW5nIG9uZSBwYWNrZXQgb2YgZGF0YSB0byBiZSBkaXJlY3RlZCANCiAgICB2aWEg dGhlIHNwZWNpZmllZCBMRkIgYWJvdmUuIFRoZSBvcmRlciBvZiB0aGUgZGF0YSBudW1iZXIgaXMg DQogICAgYWxzbyB0aGUgb3JkZXIgdGhlIGRhdGEgcGFja2V0IGFycml2ZXMgdGhlIHJlZGlyZWN0 b3IgTEZCLCB0aGF0IA0KICAgIGlzLCB0aGUgUmVkaXJlY3RlZCBEYXRhICMxIHNob3VsZCBhcnJp dmUgZWFybGllciB0aGFuIHRoZSANCiAgICBSZWRpcmVjdGVkIERhdGEgIzIgaW4gdGhpcyByZWRp cmVjdG9yIExGQi4gVGhlIFRMViBmb3JtYXQgaXMgDQogICAgYXMgZm9sbG93czoNCjwvdD4NCiAg SWYgd2hhdCB5b3UgbWVhbiBpcyBzZXF1ZW5jaW5nIHRoZSByZWRpcmVjdGVkIHBhY2tldCB0aGVu IEkgdGhpbmsgaXQgaXMgZGFuZ2Vyb3VzLiBBc3N1bWUgeW91IHVzZSBVRFAgdG8gdHJhbnNwb3J0 IHRoZSByZWRpcmVjdGVkIHBhY2tldHMgZnJvbSB0aGUgQ0UgdG8gdGhlIEZFLiBJZiBvbmUgaXMg bG9zdCwgdGhlbiB3aGF0IHdpbGwgdGhlIEZFIGRvIHdpdGggdGhlIG5leHQgb25lcyA/DQoNCg0K PGZpZ3VyZSBhbmNob3I9InRsdl9SZWRpcmVjdGVkX0RhdGEiPjxhcnR3b3JrPg0KICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICAgICB8ICAgIFR5cGUgPSBPcGVyYXRpb25zIChQQVlMT0FEKXwgICAgICAgICAgICAg ICBMZW5ndGggICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgUGF0aChvciBTZXF1ZW5jZSBOdW1iZXI/KSAgICAgICAgICAgICAgfA0KICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgUmVkaXJlY3RlZCBEYXRhICAg ICAgICAgICAgICAgICAgICAgICAgfg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPC9hcnR3b3JrPjwvZmlndXJl Pg0KPHQgaGFuZ1RleHQ9ICJQYXRoKG9yIFNlcXVlbmNlIE51bWJlcj8pOiAiPjx2c3BhY2UgLz4N CltVbmRlciBkaXNjdXNzaW9uIGFuZCBUQkRdDQo8L3Q+DQo8dCBoYW5nVGV4dD0gIlR5cGU6ICI+ PHZzcGFjZSAvPg0KW1RCRF0NCjwvdD4NCg0KPHQgaGFuZ1RleHQ9ICJSZWRpcmVjdGVkIERhdGE6 ICI+PHZzcGFjZSAvPg0KVGhpcyBmaWVsZCB3aWxsIG1ha2UgYSBkZXRhaWxlZCBkZXNjcmlwdGlv biBvZiB0aGUgZGF0YSB0byANCiAgICBiZSByZWRpcmVjdGVkIGFzIHdlbGwgYXMgdGhlIGRhdGEg aXRzZWxmLiBUaGUgZW5jb2Rpbmcgb2YgdGhlIA0KICAgIGRlc2NyaXB0aW9uIGlzIGJhc2VkIG9u IHRoZSBGb3JDRVMgRkUgbW9kZWwgaWYgdGhlIHJlZGlyZWN0b3IgDQogICAgTEZCIGlzIGRlZmlu ZWQgYnkgRkUgbW9kZWwsIG9yIGJhc2VkIG9uIHZlbmRvciBzcGVjaWZpY2F0aW9ucyANCiAgICBp ZiB0aGUgcmVkaXJlY3RvciBMRkIgaXMgZGVmaW5lZCBieSB2ZW5kb3JzLiBUaGUgZGVzY3JpcHRp b24gDQogICAgd2lsbCB1c3VhbGx5IGluY2x1ZGUgdGhlIG5hbWUgKG9yIHRoZSBuYW1lIElEKSBv ZiB0aGUgcmVkaXJlY3RlZCANCiAgICBwYWNrZXQgZGF0YSAoc3VjaCBhcyAnSVB2NCBQYWNrZXQn LCAnSVB2NiBQYWNrZXQnKSwgYW5kIHRoZSANCiAgICBwYWNrZXQgZGF0YSBpdHNlbGYuIEl0IG1h eSBhbHNvIGluY2x1ZGUgc29tZSBtZXRhZGF0YSAobWV0YWRhdGEgDQogICAgbmFtZSAob3IgbmFt ZSBJRCkgYW5kIGl0cyB2YWx1ZSlhc3NvY2lhdGVkIHdpdGggdGhlIHJlZGlyZWN0ZWQgDQogICAg ZGF0YSBwYWNrZXQuDQo8L3Q+DQo8L2xpc3Q+DQo8L3NlY3Rpb24+DQoNCjwhLS0gJExvZzogUmVk aXJlY3RNc2cueG1sLHYgJA0KPCEtLSBSZXdyaXR0ZW4gYnkgV2VpbWluZyBXYW5nIDIwMDQvMTAv MjINCjwhLS0gSW5jb3JwYXJhdGUgTEZCc2VsZWN0IGFuZCBPcGVyYXRpb24gVExWIA0KPCEtLQ0K PCEtLSBSZXZpc2lvbiAxLjcgIDIwMDQvMDcvMTkgMDk6Mzc6MDUgIGF2cmkNCjwhLS0gVmVyc2lv biAyIGNoZWNraW4NCjwhLS0NCjwhLS0gUmV2aXNpb24gMS42ICAyMDA0LzA2LzIzIDA1OjA1OjM0 ICBhdnJpDQo8IS0tIGZpbmFsIGVkaXQgZm9yIDAwDQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuNSAg MjAwNC8wNi8yMiAwNzowMjozNyAgYXZyaQ0KPCEtLSByZW1vdmUNCjwhLS0NCjwhLS0gUmV2aXNp b24gMS40ICAyMDA0LzA2LzIyIDA3OjAxOjAwICBhdnJpDQo8IS0tIFRlYW0gRWRpdCBmcm9tIDAw LTcNCjwhLS0NCjwhLS0gUmV2aXNpb24gMS4yICAyMDA0LTA2LTIxIDIxOjQwOjQxKzA4ICBhZG1p bmlzdHJhdG9yDQo8IS0tIEluY29ycGFyYXRlIHNvbWUgY29tbWVudHMgZnJvbSBKYW1hbCAoSnVu ZSAyMSwgMjAwNCAxMDo1MCBBTSkuIC1XZWltaW5nDQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuMSAg MjAwNC0wNi0yMSAyMTowOTo0MSswOCAgYWRtaW5pc3RyYXRvcg0KPCEtLSBSZXZpc2lvbiBoYW5k ZWQgZnJvbSBBdnJpLiAtIFdlaW1pbmcNCjwhLS0NCjwhLS0gUmV2aXNpb24gMS4zICAyMDA0LzA2 LzE5IDEzOjExOjEyICBhdnJpDQo8IS0tIExpbmVmZWVkcw0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAx LjIgIDIwMDQvMDYvMTkgMTM6MDU6MDAgIGF2cmkNCjwhLS0gYW5jaG9ycw0KPCEtLQ0KPCEtLSBS ZXZpc2lvbiAxLjEgIDIwMDQvMDYvMTcgMDM6NDU6NTUgIGF2cmkNCjwhLS0gSW5pdGlhbCByZXZp c2lvbg0KPCEtLSANCiAgICAgZWRpdGVkIHdpdGggPE9YeWdlbi8+WE1MIGVkaXRvciA0LjEsIGJ5 IFdlaW1pbmcgV2FuZyAmIExpZ2FuZyBEb25nIA0KICAgICAqKiogUmVkaXJlY3RNc2cgVjEuMCwg MjAwNC0wNi0xMywgY2hhbmdlcyBzaW5jZSBsYXN0IHZlcnNpb246DQogICAgIC0gTm9uZSwgYXMg dGhlIG9yaWdpbmFsIHZlcnNpb24uDQotLT4NCiAgPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu Zz0iVVRGLTgiPz4NCjwhLS0gZWRpdGVkIHdpdGggPE9YeWdlbi8+WE1MIGVkaXRvciA0LjEsIGJ5 IFdlaW1pbmcgV2FuZyAmIExpZ2FuZyBEb25nIA0KICAgICAqKiogUXVlcnlNc2cgVjEuMCwgMjAw NC0wNi0xMywgY2hhbmdlcyBzaW5jZSBsYXN0IHZlcnNpb246DQogICAgIC0gTm9uZSwgYXMgdGhl IG9yaWdpbmFsIHZlcnNpb24uDQogICAgICoqKiBRdWVyeU1zZ1YxLjEsIDIwMDQtMDYtMTgNCiAg ICAgLSBjaGFuZ2UgRW5jb2RpbmdUeXBlIHRvIFR5cGUNCiAgICAgKioqIFF1ZXJ5TXNnVjEuMiwg MjAwNC0xMC0yMA0KICAgICAtIGZvciBpZXRmLXByb3RvY29sLTAxDQotLT4NCg0KPHNlY3Rpb24g YW5jaG9yPSJRdWVyeU1zZyIgdGl0bGU9IlF1ZXJ5IGFuZCBSZXNwb25zZSBNZXNzYWdlcyI+DQog IEJlIG1vcmUgc3BlY2lmaWM6ICJRdWVyeSBhbmQgUXVlcnkgUmVzcG9uc2UgTWVzc2FnZXMiDQoN Cjx0PlRoZSBGb3JDRVMgcXVlcnkgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIGFyZSB1c2VkIGZvciBv bmUgRm9yQ0VTIA0KICAgIGVsZW1lbnQgKENFIG9yIEZFKSB0byBxdWVyeSBvdGhlciBGb3JDRVMg ZWxlbWVudChzKSBmb3IgdmFyaW91cyANCiAgICBraW5kcyBvZiBpbmZvcm1hdGlvbi4gQ3VycmVu dCB2ZXJzaW9uIG9mIEZvckNFUyBwcm90b2NvbCBsaW1pdHMgDQogICAgdGhlIHVzZSBvZiB0aGUg bWVzc2FnZXMgb25seSBmb3IgQ0UgdG8gcXVlcnkgaW5mb3JtYXRpb24gb2YgRkUuIA0KPC90Pg0K PHNlY3Rpb24gYW5jaG9yPSJRdWVyeSIgdGl0bGU9IlF1ZXJ5IE1lc3NhZ2UiPg0KDQo8dD5BcyB1 c3VhbCwgYSBxdWVyeSBtZXNzYWdlIGlzIGNvbXBvc2VkIG9mIGEgY29tbW9uIGhlYWRlciBhbmQg DQogICAgYSBtZXNzYWdlIGJvZHkgdGhhdCBjb25zaXN0cyBvZiBvbmUgb3IgbW9yZSBUTFYgZGF0 YSBmb3JtYXQuIA0KICAgIERldGFpbGVkIGRlc2NyaXB0aW9uIG9mIHRoZSBtZXNzYWdlIGlzIGFz IGJlbG93LjwvdD4NCjxsaXN0IHN0eWxlPSJoYW5naW5nIiBoYW5nSW5kZW50PSI0Ij4gPHZzcGFj ZSAvPg0KPHZzcGFjZSBibGFua0xpbmVzPSIxIiAvPg0KPHQgaGFuZ1RleHQ9ICJNZXNzYWdlIHRy YW5zZmVyIGRpcmVjdGlvbjoiPiA8dnNwYWNlIC8+DQpDdXJyZW50IHZlcnNpb24gbGltaXRzIHRo ZSBxdWVyeSBtZXNzYWdlIHRyYW5zZmVyIGRpcmVjdGlvbiANCiAgICBvbmx5IGZyb20gQ0UgdG8g RkUuPC90Pg0KDQo8dCBoYW5nVGV4dD0gIk1lc3NhZ2UgSGVhZGVyOiI+IDx2c3BhY2UgLz4NClRo ZSBNZXNzYWdlIFR5cGUgaW4gdGhlIGhlYWRlciBpcyBzZXQgdG8gTWVzc2FnZVR5cGU9ICdRdWVy eScuIA0KICAgIFRoZSBBQ0sgZmxhZyBpbiB0aGUgaGVhZGVyIFNIT1VMRCBiZSBzZXQgJ0FDS0Fs bCcsIG1lYW5pbmcgYSANCiAgICBmdWxsIHJlc3BvbnNlIGZvciBhIHF1ZXJ5IG1lc3NhZ2UgaXMg YWx3YXlzIGV4cGVjdGVkLiBJZiB0aGUgDQogICAgQUNLIGZsYWcgaXMgc2V0IG90aGVyIHZhbHVl cywgdGhlIG1lYW5pbmcgb2YgdGhlIA0KICAgIGZsYWcgd2lsbCB0aGVuIGJlIGlnbm9yZWQsIGFu ZCBhIGZ1bGwgcmVzcG9uc2Ugd2lsbCBzdGlsbCBiZSANCiAgICByZXR1cm5lZCBieSBtZXNzYWdl IHJlY2VpdmVyLjwvdD4NCg0KDQo8dCBoYW5nVGV4dCA9ICJNZXNzYWdlIGJvZHk6ICI+PHZzcGFj ZSAvPg0KVGhlIHF1ZXJ5IG1lc3NhZ2UgYm9keSBjb25zaXN0cyBvZiAoYXQgbGVhc3QpIG9uZSBv ciBtb3JlIHRoYW4gDQogICAgb25lIFRMVnMgdGhhdCBkZXNjcmliZSBlbnRyaWVzIHRvIGJlIHF1 ZXJpZWQuIFRoZSBUTFYgaXMgY2FsbGVkIA0KICAgIExGQnNlbGVjdCBUTFYgYW5kIHRoZSBkYXRh IGZvcm1hdCBpcyBhcyBiZWxvdzoNCjwvdD4NCjxmaWd1cmUgYW5jaG9yPSJtc2dfUXVlcnkiPg0K PGFydHdvcms+DQogDQogICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAg VHlwZSA9IExGQnNlbGVjdCAgICAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwN CiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgTEZCIENsYXNz IElEICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgIExGQiBJbnN0YW5jZSBJRCAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdGlv aW4gVExWICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIH4NCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgIE9wZXJhdGlvaW4gVExWICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAg LiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC4NCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgVHlwbyBpbiBhbGwgZmlndXJlczogY29ycmVjdCAi T3BlcmF0aW9pbiBUTFYiDQoNCiAgR2VuZXJhbCBjb21tZW50OiBpbiBtYW55IGNhc2VzIHRoZSBz YW1lIHR5cGUgaW4gVExWIGlzIHVzZWQgaW4gZGlmZmVyZW50IFBMIG1lc3NhZ2VzIChRdWVyeSB2 cyBSZXNwb25zZSwgZXRjKSBhbmQgdGhlbiB0aGUgViBpcyBkaWZmZXJlbnQuIFRoaXMgV0lMTCBi ZSBhIGJpZyBzb3VyY2Ugb2YgaW1wbGVtZW50YXRpb24gYnVncy4gSSB0aGluayB3ZSBzaG91bGQg ZGVmaW5lZCBvcGVyYXRpb24gVExWcyBkaWZmZXJlbnRseTogR0VUIGFuZCBHRVQtUkVTUCwgU0VU IGFuZCBTRVQtUkVTUCwgUkVQT1JUIGFuZCBSRVBPUlQtUkVTUC4NCiAgV2hhdCBkbyB5b3UgdGhp bmsgPw0KDQogICAgIA0KPC9hcnR3b3JrPg0KPC9maWd1cmU+DQo8dnNwYWNlIGJsYW5rTGluZXM9 IjEiIC8+DQo8bGlzdCBzdHlsZT0gImhhbmdpbmciIGhhbmdJbmRlbnQ9IjE3IiA+DQo8dCBoYW5n VGV4dCA9ICJFZGl0b3JpYWwgTm90ZTogIj4NCjwvdD4NCjxsaXN0IHN0eWxlPSJudW1iZXJzIiBo YW5nSW5kZW50PSIzIj4NCjx0PlVuZGVyIGRpc2N1c3Npb24gaXMgd2hldGhlciB0aGVyZSBpcyBh IG5lZWQgZm9yIGV4cGxpY2l0IG11bHRpcGxlIExGQiBpbnNhdGFuY2UNCiAgICBhZGRyZXNzaW5n IGhlcmUuIE9uZSB3YXkgdG8gcmVhbGl6ZSBpdCBpcyB0byBkZWZpbmUgYSBzcGVjaWZpYyBJbnN0 YW5jZSBzZWxlY3QNCiAgICBUTFYgdG8gc3Vic3RpdHV0ZSBhYm92ZSAnTEZCIEluc3RhbmNlIElE JyBmaWVsZC4gVGhlIFRMViBtYXkgaGF2ZSBmb2xsb3dpbmcgZm9ybWF0OjwvdD4NCjxmaWd1cmU+ PGFydHdvcms+DQogICAgICAgIElOU3NlbGVjdFRMViA6PSBUeXBlIExlbmd0aCBWYWx1ZQ0KICAg ICAgICBUeXBlIDo9IElOU3NlbGVjdA0KICAgICAgICBWYWx1ZSA6PSBJbnN0YW5jZUlEIChSYW5n ZU1hcmsgfCBJbnN0YW5jZSBJRCkrDQoNCjwvYXJ0d29yaz48L2ZpZ3VyZT4NCjx0PkFuIGFwcGxp Y2FibGUgUmFuZ2VNYXJrIGlzICcweGZmZmZmZmZmJywgdGhlIHZhbHVlIG9mIHdoaWNoIGlzIHRo ZSBzYW1lIGFzIA0KICAgIEluc3RhbmNlIGJyb2FkY2FzdCBJRC4gQmVjYXVzZSB0aGVyZSB3aWxs IGJlIG5vIGJyb2FkY2FzdCBhZGRyZXNzIGFwcGxpZWQNCiAgICBpbiB0aGlzIHBsYWNlLCB0aGVy ZSB3aWxsIGJlIG5vIHdvcnJ5IG9mIGFtYmlndWl0eSBoZXJlLjwvdD4NCjwvbGlzdD4gICANCjwv bGlzdD4NCjx2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLz4NCjx0IGhhbmdUZXh0PSAiT3BlcmF0aW9u IFRMViI+PHZzcGFjZSAvPg0KVGhlIE9wZXJhdGlvbiBUTFYgZm9yIHRoZSAnUXVlcnknIG1lc3Nh Z2UgaXMgZm9ybWF0dGVkIGFzOg0KPC90Pg0KPGZpZ3VyZSBhbmNob3I9InRsdl9RdWVyeSI+DQo8 YXJ0d29yaz4gICAgDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgVHlwZSA9IE9wZXJhdGlvbnMg KEdFVCkgICAgfCAgICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICB8DQogICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBQYXRoKG9yIEF0dHJpYnV0ZSBJRD8pICAg ICAgICAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUXVlcnkgRGF0YSAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgIC4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAuDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogDQogIEFnYWluLCBpbiBhbGwgeW91ciBzZWN0aW9ucywgY291 bGQgeW91IGNoYW5nZSAiVHlwZSA9IE9wZXJhdGlvbnMgKEdFVCkiIHRvICJUeXBlID0gR0VUIiBh bmQgc28gb24gPw0KDQo8L2FydHdvcms+PC9maWd1cmU+DQo8dCBoYW5nVGV4dD0gIlBhdGgob3Ig QXR0cmlidXRlIElEPyk6ICI+PHZzcGFjZSAvPg0KW1VuZGVyIGRpc2N1c3Npb24gYW5kIFRCRF0N CjwvdD4NCg0KPHZzcGFjZSBibGFua0xpbmVzID0gIjEiIC8+DQo8bGlzdCBzdHlsZT0iaGFuZ2lu ZyIgaGFuZ0luZGVudD0iMTciPg0KPHQgaGFuZ1RleHQgPSAiRWRpdG9yaWFsIE5vdGU6Ij4gDQpU aGVyZSBpcyBhIGRlYmF0ZSBvbiB3aGV0aGVyIHdlIHNob3VsZCB1c2UgYSAnUGF0aCcgb3Igc2lt cGx5IGFuICdBdHRyaWJ1dGUgSUQnIA0KICAgIG9yIGEgJ1RhYmxlIElEJyBoZXJlIGF0IHRoZSBw cm90b2NvbCBsYXllci4gQSBQYXRoIGlzIHVzZWQgZm9yIGRhdGEgDQogICAgaW5kZXhpbmcgZm9y IGEgdGFibGUsIHdoaWxlIGFuICdBdHRyaWJ1dGUgSUQnIG9yIGEgJ1RhYmxlIElEJyBvbmx5IHNw ZWNpZnkgDQogICAgd2hpY2ggYXR0cmlidXRlIG9yIHRhYmxlIHRvIHVzZSwgbGVhdmluZyB0YWJs ZSBpbmRleCB0byBiZSBpbmNsdWRlZCBpbiBmb2xsb3dlZCANCiAgICBkYXRhLg0KPC90Pg0KPC9s aXN0Pg0KPHZzcGFjZSBibGFua0xpbmVzPSIxIiAvPg0KPHQgaGFuZ1RleHQ9ICJRdWVyeSBEYXRh OiAiPjx2c3BhY2UgLz4NCiAgICBbVW5kZXIgZGlzY3Vzc2lvbiBhbmQgVEJEXQ0KPC90Pg0KPC9s aXN0Pg0KPHQ+VG8gYmV0dGVyIHVuZGVyc3RhbmQgdGhlIGFib3ZlIFBEVSBmb3JtYXQsIHdlIGNh biBzaG93IGEgdHJlZSBzdHJ1Y3R1cmUgZm9yIHRoZSANCiAgICBmb3JtYXQgYXMgYmVsb3c6DQo8 ZmlndXJlPg0KbWFpbiBoZHIgKHR5cGUgPSBRdWVyeSkNCiAgICAgfA0KICAgICB8DQogICAgICst LS0gVCA9IExGQnNlbGVjdA0KICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAgICstLSBMRkJD TEFTU0lEID0gdGFyZ2V0IExGQiBjbGFzcw0KICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAg IHwNCiAgICAgfCAgICAgICAgKy0tIExGQkluc3RhbmNlID0gdGFyZ2V0IExGQiBpbnN0YW5jZSAN CiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAgICstLSBUID0g b3BlcmF0aW9uIHsgR0VUIH0NCiAgICAgfCAgICAgICAgfCAgIHwNCiAgICAgfCAgICAgICAgfCAg ICstLSAgLy8gb25lIG9yIG1vcmUgcGF0aCB0YXJnZXRzIA0KICAgICB8ICAgICAgICB8ICAgICAg ICAvLyB1bmRlciBkaXNjdXNzaW9uDQogICAgIHwgICAgICAgICstLSBUID0gb3BlcmF0aW9uIHsg R0VUIH0NCiAgICAgfCAgICAgICAgfCAgIHwNCiAgICAgfCAgICAgICAgfCAgICstLSAgLy8gb25l IG9yIG1vcmUgcGF0aCB0YXJnZXRzIA0KICAgICB8ICAgICAgICB8IA0KDQo8L2ZpZ3VyZT4NCjwv c2VjdGlvbj4NCg0KPHNlY3Rpb24gYW5jaG9yPSJRdWVyeVJlc3BvbnNlIiB0aXRsZT0iUXVlcnkg UmVzcG9uc2UgTWVzc2FnZSI+DQo8dD5XaGVuIHJlY2VpdmluZyBhIHF1ZXJ5IG1lc3NhZ2UsIHRo ZSByZWNlaXZlciBzaG91bGQgcHJvY2VzcyB0aGUgDQogICAgbWVzc2FnZSBhbmQgY29tZSB1cCB3 aXRoIGEgcXVlcnkgcmVzdWx0LiBUaGUgcmVjZWl2ZXIgc2VuZHMgdGhlIA0KICAgIHF1ZXJ5IHJl c3VsdCBiYWNrIHRvIHRoZSBtZXNzYWdlIHNlbmRlciBieSB1c2Ugb2YgdGhlIFF1ZXJ5IA0KICAg IFJlc3BvbnNlIE1lc3NhZ2UuIFRoZSBxdWVyeSByZXN1bHQgY2FuIGJlIHRoZSBpbmZvcm1hdGlv biANCiAgICBiZWluZyBxdWVyaWVkIGlmIHRoZSBxdWVyeSBvcGVyYXRpb24gaXMgc3VjY2Vzc2Z1 bCwgb3IgY2FuIGFsc28gDQogICAgYmUgZXJyb3IgY29kZXMgaWYgdGhlIHF1ZXJ5IG9wZXJhdGlv biBmYWlscywgaW5kaWNhdGluZyB0aGUgDQogICAgcmVhc29ucyBmb3IgdGhlIGZhaWx1cmUuPC90 Pg0KDQo8dD5BIHF1ZXJ5IHJlc3BvbnNlIG1lc3NhZ2UgaXMgYWxzbyBjb21wb3NlZCBvZiBhIGNv bW1vbiBoZWFkZXIgYW5kIA0KICAgIGEgbWVzc2FnZSBib2R5IGNvbnNpc3RzIG9mIG9uZSBvciBt b3JlIFRMVnMgZGVzY3JpYmluZyB0aGUgcXVlcnkgDQogICAgcmVzdWx0LiBEZXRhaWxlZCBkZXNj cmlwdGlvbiBvZiB0aGUgbWVzc2FnZSBpcyBhcyBiZWxvdy48L3Q+DQo8dnNwYWNlIGJsYW5rTGlu ZXM9IjEiIC8+DQo8bGlzdCBzdHlsZT0gImhhbmdpbmciIGhhbmdJbmRlbnQ9IjQiPg0KPHQgaGFu Z1RleHQ9ICJNZXNzYWdlIHRyYW5zZmVyIGRpcmVjdGlvbjogIj48dnNwYWNlIC8+DQpDdXJyZW50 IHZlcnNpb24gbGltaXRzIHRoZSBxdWVyeSByZXNwb25zZSBtZXNzYWdlIHRyYW5zZmVyIGRpcmVj dGlvbiANCiAgICBvbmx5IGZyb20gRkUgdG8gQ0UuDQo8L3Q+DQogICAgDQo8dCBoYW5nVGV4dD0g Ik1lc3NhZ2UgSGVhZGVyOiAgIj48dnNwYWNlIC8+DQpUaGUgTWVzc2FnZSBUeXBlIGluIHRoZSBo ZWFkZXIgaXMgc2V0IHRvIE1lc3NhZ2VUeXBlPSAnUXVlcnlSZXNwb25zZScuIA0KICAgIFRoZSBB Q0sgZmxhZyBpbiB0aGUgaGVhZGVyIFNIT1VMRCBiZSBzZXQgJ05vQUNLJywgbWVhbmluZyBubyBm dXJ0aGVyIA0KICAgIHJlc3BvbnNlIGZvciBhIHF1ZXJ5IHJlc3BvbnNlIG1lc3NhZ2UgaXMgZXhw ZWN0ZWQuIElmIHRoZSBBQ0sgZmxhZyBpcyANCiAgICBzZXQgb3RoZXIgdmFsdWVzLCB0aGUgbWVh bmluZyBvZiB0aGUgZmxhZyB3aWxsIHRoZW4gYmUgDQogICAgaWdub3JlZC4gVGhlIFNlcXVlbmNl IE51bWJlciBpbiB0aGUgaGVhZGVyIFNIT1VMRCBrZWVwIHRoZSBzYW1lIGFzIA0KICAgIHRoYXQg b2YgdGhlIHF1ZXJ5IG1lc3NhZ2UgdG8gYmUgcmVzcG9uZGVkLCBzbyB0aGF0IHRoZSBxdWVyeSBt ZXNzYWdlIA0KICAgIHNlbmRlciBjYW4ga2VlcCB0cmFjayBvZiB0aGUgcmVzcG9uc2VzLiANCjwv dD4NCiAgICANCjx0IGhhbmdUZXh0PSAiTWVzc2FnZSBib2R5OiAiPjx2c3BhY2UgLz4NClRoZSBt ZXNzYWdlIGJvZHkgZm9yIGEgcXVlcnkgcmVzcG9uc2UgbWVzc2FnZSBjb25zaXN0cyBvZiAoYXQg bGVhc3QpIA0KICAgIG9uZSBvciBtb3JlIHRoYW4gb25lIFRMVnMgdGhhdCBkZXNjcmliZSBxdWVy eSByZXN1bHRzIGZvciBpbmRpdmlkdWFsIA0KICAgIHF1ZXJpZWQgZW50cmllcy4gVGhlIFRMViBp cyBhbHNvIGNhbGxlZCBMRkJzZWxlY3QgVExWLCBhbmQgaGFzIGV4YWN0bHkgDQogICAgdGhlIHNh bWUgZGF0YSBmb3JtYXQgYXMgcXVlcnkgbWVzc2FnZSwgZXhjZXB0IHRoZSBPcGVyYXRpb24gVExW IGluc2lkZQ0KICAgIHRoZSBUTFYgY29tcHJpc2VzIHRoZSAnUXVlcnkgUmVzcG9uc2UgRGF0YScs IGluc3RlYWQgb2YgdGhlICdRdWVyeSBEYXRhJywNCiAgICBhcyBiZWxvdzoNCjwvdD4NCg0KPGZp Z3VyZSBhbmNob3I9Im1zZ19RdWVyeV9SZXNwb25zZSI+DQo8YXJ0d29yaz4NCiAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgICAgfCAgICBUeXBlID0gT3BlcmF0aW9ucyAoR0VUKSAgICB8ICAgICAgICAgICAgICAg TGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIFBhdGgob3IgQXR0cmlidXRlIElEPykgICAgICAgICAgICAgICAgICB8DQogICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBRdWVyeSBSZXNwb25zZSBEYXRh ICAgICAgICAgICAgICAgICAgICB8DQogICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQogICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo8L2Fy dHdvcms+DQo8L2ZpZ3VyZT4NCiAgWW91IHNob3VsZCBzcGVjaWZ5IGhlcmUgdGhhdCB0aGUgb3Jk ZXIgb2YgdGhlIFRMViBpbiB0aGUgUXVlcnktUmVwb25zZSBtYXRjaGVzIHRoZSBUTFZzIGluIHRo ZSBRdWVyeS4gU28gdGhlcmUgaXMgYWx3YXlzIHRoZSBzYW1lIG51bWJlciBvZiBUTFZzIGluIHRo ZSByZXNwb25zZSBhcyBpbiB0aGUgcXVlcnkuDQoNCiAgU2lkZSBub3RlOiB3ZSBoYXZlIG5vdCB5 ZXQgcmVzb2x2ZWQgdGhlIHVzZSBvZiBhIHRyYW5zYWN0aW9uIG9yIHNlcXVlbmNlIG51bWJlciB0 aGF0IHdpbGwgYmUgdXNlZCBmb3IgZWFjaCBQTCBtZXNzYWdlLg0KDQoNCiANCjx0IGhhbmdUZXh0 PSAiUXVlcnkgUmVzcG9uc2UgRGF0YTogIj48dnNwYWNlIC8+DQpbVW5kZXIgZGlzY3Vzc2lvbiBh bmQgVEJEXQ0KPC90Pg0KPC9saXN0Pg0KICAgIA0KPC9zZWN0aW9uPg0KPC9zZWN0aW9uPg0KDQo8 IS0tICRMb2c6IFF1ZXJ5TXNnLnhtbCx2ICQNCjwhLS0gUmV3cml0dGVuIGJ5IFdlaW1pbmcgV2Fu ZyAyMDA0LzEwLzIyDQo8IS0tIEluY29ycGFyYXRlIExGQnNlbGVjdCBhbmQgT3BlcmF0aW9uIFRM ViANCjwhLS0NCjwhLS0gUmV2aXNpb24gMS4xMCAgMjAwNC8xMC8yMCAxNDo0OTozNiAgYXZyaQ0K PCEtLSBDaGFuZ2VzIGZvciBkcmFmdC1pZXRmLWZvcmNlcy1wcm90b2NvbC0wMA0KPCEtLQ0KPCEt LSBSZXZpc2lvbiAxLjkgIDIwMDQvMDcvMTkgMDk6Mzc6MjIgIGF2cmkNCjwhLS0gVmVyc2lvbiAy IGNoZWNraW4NCjwhLS0NCjwhLS0gUmV2aXNpb24gMS44ICAyMDA0LzA2LzIzIDA1OjA1OjQ3ICBh dnJpDQo8IS0tIGZpbmFsIGVkaXRzIGZvciAwMA0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAxLjcgIDIw MDQvMDYvMjIgMDY6NTQ6MTcgIGF2cmkNCjwhLS0gUmVtb3ZlDQo8IS0tDQo8IS0tIFJldmlzaW9u IDEuNiAgMjAwNC8wNi8yMiAwNjo1MjozMyAgYXZyaQ0KPCEtLSBJbmNvcnBvcmF0ZSBXVyBjaGFu Z2VzDQo8IS0tIEluY2x1ZGUgdGVhbSBlZGl0cyBvbiAwMC03DQo8IS0tDQo8IS0tIFJldmlzaW9u IDEuMiAgMjAwNC0wNi0yMSAyMTo0MDoyNSswOCAgYWRtaW5pc3RyYXRvcg0KPCEtLSBJbmNvcnBh cmF0ZSBzb21lIGNvbW1lbnRzIGZyb20gSmFtYWwgKEp1bmUgMjEsIDIwMDQgMTA6NTAgQU0pLiAt V2VpbWluZw0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAxLjEgIDIwMDQtMDYtMjEgMjA6MzY6NDArMDgg IGFkbWluaXN0cmF0b3INCjwhLS0gcmV2aXNpb24gaGFuZGVkIGZyb20gQXZyaQ0KPCEtLQ0KPCEt LSBSZXZpc2lvbiAxLjUgIDIwMDQvMDYvMTkgMTM6MTI6MzMgIGF2cmkNCjwhLS0gZm9ybWF0dGlu Zw0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAxLjQgIDIwMDQvMDYvMTkgMTM6MDM6MDMgIGF2cmkNCjwh LS0gZml4IGNyb3NzIHJlZmVyZW5jZQ0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAxLjMgIDIwMDQvMDYv MTkgMTI6MjE6MTEgIGF2cmkNCjwhLS0gLSBjaGFuZ2UgRW5jb2RpbmdUeXBlIHRvIFR5cGUgKGZy b20gV1cpDQo8IS0tIC0gZml4IGZvcm1hdGluZw0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAxLjIgIDIw MDQvMDYvMTcgMDM6NDM6NDcgIGF2cmkNCjwhLS0gUmVwbGFjZSB3aXRoIG5ldyBXVyBmaWxlcw0K PCEtLQ0KICAgIGVkaXRlZCB3aXRoIDxPWHlnZW4vPlhNTCBlZGl0b3IgNC4xLCBieSBXZWltaW5n IFdhbmcgJkxpZ2FuZyBEb25nIA0KICAgICAqKiogUXVlcnlNc2cgVjEuMCwgMjAwNC0wNi0xMywg Y2hhbmdlcyBzaW5jZSBsYXN0IHZlcnNpb246DQogICAgIC0gTm9uZSwgYXMgdGhlIG9yaWdpbmFs IHZlcnNpb24uDQotLT4NCiAgPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4N CjwhLS0gZWRpdGVkIHdpdGggPE9YeWdlbi8+WE1MIGVkaXRvciA0LjEsIGJ5IFdlaW1pbmcgV2Fu ZyAmTGlnYW5nIERvbmcgDQogICAgICoqKiBFdmVudE1zZyBWMS4wLCAyMDA0LTA2LTEzLCBjaGFu Z2VzIHNpbmNlIGxhc3QgdmVyc2lvbjoNCiAgICAgLSBOb25lLCBhcyB0aGUgb3JpZ2luYWwgdmVy c2lvbi4NCiAgICAgKioqIEV2ZW50TXNnVjEuMSwgMjAwNC0wNi0xODoNCiAgICAgLSBjaGFuZ2Ug RW5jb2RpbmdUeXBlIHRvIFR5cGUuDQotLT4NCg0KPHNlY3Rpb24gYW5jaG9yPSJFdmVudE1zZyIg dGl0bGU9IkV2ZW50IE5vdGlmaWNhdGlvbiBhbmQgUmVzcG9uc2UgTWVzc2FnZXMiPg0KDQo8dD5U aGUgRXZlbnQgTm90aWZpY2F0aW9uIE1lc3NhZ2UgaXMgdXNlZCBmb3Igb25lIEZvckNFUyBlbGVt ZW50IA0KICAgIHRvIGFzeW5jaHJvbm91c2x5IG5vdGlmeSBvbmUgb3IgbW9yZSBvdGhlciBGb3JD RVMgZWxlbWVudHMgDQogICAgaW4gdGhlIHNhbWUgRm9yQ0VTIE5FIG9uIGp1c3QgaGFwcGVuZWQg ZXZlbnRzIGluIGl0LiBUaGUgDQogICAgRXZlbnQgTm90aWZpY2F0aW9uIFJlc3BvbnNlIE1lc3Nh Z2UgaXMgdXNlZCBmb3IgdGhlIHJlY2VpdmVyIA0KICAgIG9mIHRoZSBFdmVudCBOb3RpZmljYXRp b24gTWVzc2FnZSB0byBhY2tub3dsZWRnZSB0aGUgcmVjZXB0aW9uIA0KICAgIG9mIHRoZSBldmVu dCBub3RpZmljYXRpb24uPC90Pg0KDQo8dD5FdmVudHMgaW4gY3VycmVudCBGb3JDRVMgcHJvdG9j b2wgY2FuIGJlIGNhdGVnb3JpemVkIGludG8gZm9sbG93aW5nIHR5cGVzOjwvdD4NCjx0PjxsaXN0 IHN0eWxlPSJzeW1ib2xzIj4NCjx0PkV2ZW50cyBoYXBwZW5lZCBpbiBDRTwvdD4NCjx0PkV2ZW50 cyBoYXBwZW5lZCBpbiBGRTwvdD4NCiAgV2h5IGRvZXMgdGhpcyBtYXR0ZXIgZm9yIHRoZSBwcm90 b2NvbCA/DQoNCjwvbGlzdD48L3Q+DQoNCjx0PkV2ZW50cyBjYW4gYWxzbyBiZSBjYXRlZ29yaXpl ZCBpbnRvIHR3byBjbGFzc2VzIGFjY29yZGluZyB0byANCiAgICB3aGV0aGVyIHRoZXkgbmVlZCBz dWJzY3JpcHRpb24gb3Igbm90LiBBbiBldmVudCBpbiBvbmUgRm9yQ0VTIA0KICAgIGVsZW1lbnQg dGhhdCBuZWVkcyB0byBiZSBzdWJzY3JpYmVkIHdpbGwgc2VuZCBub3RpZmljYXRpb25zIHRvIA0K ICAgIG90aGVyIEZvckNFUyBlbGVtZW50cyBvbmx5IHdoZW4gdGhlIG90aGVyIGVsZW1lbnRzIGhh dmUgc3Vic2NyaWJlZCANCiAgICB0byB0aGUgZWxlbWVudCBmb3IgdGhlIGV2ZW50IG5vdGlmaWNh dGlvbi4gSG93IHRvIA0KICAgIHN1YnNjcmliZS91bnN1YnNjcmliZSBmb3IgYW4gZXZlbnQgaXMg ZGVzY3JpYmVkIGluIHRoZSBDb25maWd1cmUgDQogICAgTWVzc2FnZSBpbiBTZWN0aW9uIDYuMy4g QW4gZXZlbnQgdGhhdCBuZWVkcyBub3QgdG8gYmUgc3Vic2NyaWJlZCANCiAgICB3aWxsIGFsd2F5 cyBzZW5kIG5vdGlmaWNhdGlvbnMgdG8gb3RoZXIgRm9yQ0VTIGVsZW1lbnRzIHdoZW4gdGhlIA0K ICAgIGV2ZW50IGhhcHBlbnMuIEFuIGV2ZW50IGRlZmluaXRpb24gbWFkZSBieSBGb3JDRVMgcHJv dG9jb2wsIEZvckNFUyANCiAgICBGRSBtb2RlbCwgb3IgYnkgdmVuZG9ycyB3aWxsIHN0YXRlIGlm IHRoZSBldmVudCBuZWVkcyBzdWJzY3JpcHRpb24gb3Igbm90LjwvdD4NCjx2c3BhY2UgYmxhbmtM aW5lcz0iMSIgLz4NCjxsaXN0IHN0eWxlPSJoYW5naW5nIiBoYW5nSW5kZW50PSIxNyIgPg0KPHQg aGFuZ1RleHQ9IkVkaXRvcmlhbCBOb3RlOiAiID4NClRoZXJlIGlzIGFuIGFyZ3VtZW50IHRoYXQg aXQgaXMgcHJlZmVyYWJsZSB0byBoYXZlIA0KYWxsIGV2ZW50cyBzdWJzY3JpYmFibGUuDQo8L3Q+ DQo8L2xpc3Q+DQoNCg0KPHNlY3Rpb24gdGl0bGU9IkV2ZW50IE5vdGlmaWNhdGlvbiBNZXNzYWdl Ij4NCg0KPHQ+QXMgdXN1YWwsIGFuIEV2ZW50IE5vdGlmaWNhdGlvbiBNZXNzYWdlIGlzIGNvbXBv c2VkIG9mIGEgY29tbW9uIA0KICAgIGhlYWRlciBhbmQgYSBtZXNzYWdlIGJvZHkgdGhhdCBjb25z aXN0cyBvZiBvbmUgb3IgbW9yZSBUTFYgZGF0YSANCiAgICBmb3JtYXQuIERldGFpbGVkIGRlc2Ny aXB0aW9uIG9mIHRoZSBtZXNzYWdlIGlzIGFzIGJlbG93LjwvdD4NCjxsaXN0IHN0eWxlPSJoYW5n aW5nIiBoYW5nSW5kZW50PSIxIj4NCjx0IGhhbmdUZXh0PSAiTWVzc2FnZSBUcmFuc2ZlciBEaXJl Y3Rpb246ICAiPjx2c3BhY2UgLz4NCkZFIHRvIENFLCBvciBDRSB0byBGRQ0KPC90Pg0KDQoNCjx0 IGhhbmdUZXh0PSAiTWVzc2FnZSBIZWFkZXI6ICAiPjx2c3BhY2UgLz4NClRoZSBNZXNzYWdlIFR5 cGUgaW4gdGhlIG1lc3NhZ2UgaGVhZGVyIGlzIHNldCB0byA8dnNwYWNlIC8+DQogICAgTWVzc2Fn ZVR5cGUgPSAnRXZlbnROb3RpZmljYXRpb24nLiBUaGUgQUNLIGZsYWcgaW4gdGhlIGhlYWRlciAN CiAgICBjYW4gYmUgc2V0IGFzOiBBQ0sgZmxhZyA9J05vQUNLJ3wnU3VjY2Vzc0Fjayd8J1Vuc3Vj Y2Vzc0FDSyd8J0FDS0FsbCcuIA0KICAgIE5vdGUgdGhhdCB0aGUgJ1N1Y2Nlc3MnIGhlcmUgb25s eSBtZWFucyB0aGUgcmVjZWl2ZXIgb2YgdGhlIG1lc3NhZ2UgDQogICAgaGFzIHN1Y2Nlc3NmdWxs eSByZWNlaXZlZCB0aGUgbWVzc2FnZS4NCjwvdD4NCg0KDQo8dCBoYW5nVGV4dD0gIk1lc3NhZ2Ug Qm9keTogIj48dnNwYWNlIC8+DQpUaGUgbWVzc2FnZSBib2R5IGZvciBhbiBldmVudCBub3RpZmlj YXRpb24gbWVzc2FnZSBjb25zaXN0cyANCiAgICBvZiAoYXQgbGVhc3QpIG9uZSBvciBtb3JlIHRo YW4gb25lIFRMVnMgdGhhdCBkZXNjcmliZSB0aGUgDQogICAgbm90aWZpZWQgZXZlbnRzLiBUaGUg VExWIGlzIGRlZmluZWQgYXMgZm9sbG93czoNCjx2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLz4NCjwv dD4NCg0KPGZpZ3VyZSBhbmNob3I9InRsdl9FdmVudF9Ob3RpZmljYXRpb24iPg0KPGFydHdvcms+ DQogICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDENCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgVHlwZSA9IExGQnNl bGVjdCAgICAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgTEZCIENsYXNzIElEICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIExGQiBJbnN0YW5jZSBJRCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdGlvaW4gVExWICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAg fiAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIH4NCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9w ZXJhdGlvaW4gVExWICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiANCjwvYXJ0d29yaz48L2ZpZ3VyZT4NCg0KPHQgaGFuZ1RleHQ9ICJPcGVy YXRpb24gVExWOiAiPjx2c3BhY2UgLz4NClRoaXMgaXMgYSBUTFYgdGhhdCBkZXNjcmliZXMgdGhl IGV2ZW50IHRvIGJlIG5vdGlmaWVkLCBhcyBmb2xsb3dzOg0KPC90Pg0KDQo8ZmlndXJlIGFuY2hv cj0idGx2X0V2ZW50Ij48YXJ0d29yaz4NCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICBUeXBlID0g T3BlcmF0aW9ucyAoUkVQT1JUKSB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIFBhdGgob3IgRXZlbnQg SUQ/KSAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICBFdmVudCBEYXRhICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC4NCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCjwvYXJ0d29yaz48L2ZpZ3VyZT4NCjx0IGhh bmdUZXh0PSAiUGF0aChvciBFdmVudCBJRCk6ICI+PHZzcGFjZSAvPg0KW1VuZGVyIGRpc2N1c3Np b24gYW5kIFRCRF0NCjwvdD4NCg0KPHQgaGFuZ1RleHQ9ICJFdmVudCBEYXRhOiAiPjx2c3BhY2Ug Lz4NCiAgICBbVW5kZXIgZGlzY3Vzc2lvbiBhbmQgVEJEXQ0KPC90Pg0KPC9saXN0Pg0KPHQ+VG8g YmV0dGVyIHVuZGVyc3RhbmQgdGhlIGFib3ZlIFBEVSBmb3JtYXQsIHdlIGNhbiBzaG93IGEgdHJl ZSBzdHJ1Y3R1cmUgZm9yIHRoZSANCiAgICBmb3JtYXQgYXMgYmVsb3c6DQo8ZmlndXJlPg0KbWFp biBoZHIgKHR5cGUgPSBFdmVudCBOb3RpZmljYXRpb24pDQogICAgIHwNCiAgICAgfA0KICAgICAr LS0tIFQgPSBMRkJzZWxlY3QNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gTEZC Q0xBU1NJRCA9IHRhcmdldCBMRkIgY2xhc3MNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAg ICB8DQogICAgIHwgICAgICAgICstLSBMRkJJbnN0YW5jZSA9IHRhcmdldCBMRkIgaW5zdGFuY2Ug DQogICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gVCA9 IG9wZXJhdGlvbiB7IFJFUE9SVCB9DQogICAgIHwgICAgICAgIHwgICB8DQogICAgIHwgICAgICAg IHwgICArLS0gIC8vIG9uZSBvciBtb3JlIHBhdGggdGFyZ2V0cyANCiAgICAgfCAgICAgICAgfCAg ICAgICAgLy8gdW5kZXIgZGlzY3Vzc2lvbg0KICAgICB8ICAgICAgICArLS0gVCA9IG9wZXJhdGlv biB7IFJFUE9SVCB9DQogICAgIHwgICAgICAgIHwgICB8DQogICAgIHwgICAgICAgIHwgICArLS0g IC8vIG9uZSBvciBtb3JlIHBhdGggdGFyZ2V0cyANCiAgICAgfCAgICAgICAgfCANCg0KPC9maWd1 cmU+DQo8L2xpc3Q+DQo8L3NlY3Rpb24+DQoNCjxzZWN0aW9uIHRpdGxlPSJFdmVudCBOb3RpZmlj YXRpb24gUmVzcG9uc2UgTWVzc2FnZSI+DQoNCjx0PkFmdGVyIHNlbmRpbmcgb3V0IGFuIEV2ZW50 IE5vdGlmaWNhdGlvbiBNZXNzYWdlLCB0aGUgc2VuZGVyIG1heSANCiAgICBiZSBpbnRlcmVzdGVk IGluIGVuc3VyaW5nIHRoYXQgdGhlIG1lc3NhZ2UgaGFzIGJlZW4gcmVjZWl2ZWQgDQogICAgYnkg cmVjZWl2ZXJzLCBlc3BlY2lhbGx5IHdoZW4gdGhlIHNlbmRlciB0aGlua3MgdGhlIGV2ZW50IA0K ICAgIG5vdGlmaWNhdGlvbiBpcyB2aXRhbCBmb3Igc3lzdGVtIG1hbmFnZW1lbnQuIEFuIEV2ZW50 IA0KICAgIE5vdGlmaWNhdGlvbiBSZXNwb25zZSBNZXNzYWdlIGlzIHVzZWQgZm9yIHRoaXMgcHVy cG9zZS4gVGhlIA0KICAgIEFDSyBmbGFnIGluIHRoZSBFdmVudCBOb3RpZmljYXRpb24gTWVzc2Fn ZSBoZWFkZXIgYXJlIHVzZWQgdG8gDQogICAgc2lnbmFsIGlmIHN1Y2ggYWNrbm93bGVkZ2UgaXMg cmVxdWVzdGVkIG9yIG5vdCBieSB0aGUgc2VuZGVyLjwvdD4gDQoNCjx0PkRldGFpbGVkIGRlc2Ny aXB0aW9uIG9mIHRoZSBtZXNzYWdlIGlzIGFzIGJlbG93OjwvdD4NCjxsaXN0IHN0eWxlPSJoYW5n aW5nIiBoYW5nSW5kZW50PSIxIj4NCjx0IGhhbmdUZXh0PSAiTWVzc2FnZSBUcmFuc2ZlciBEaXJl Y3Rpb246ICAiPjx2c3BhY2UgLz4NCkZyb20gRkUgdG8gQ0Ugb3IgZnJvbSBDRSB0byBGRSwganVz dCBpbnZlcnNlIHRvIHRoZSANCiAgICBkaXJlY3Rpb24gb2YgdGhlIEV2ZW50IE5vdGlmaWNhdGlv biBNZXNzYWdlIHRoYXQgaXQgcmVzcG9uc2VzLg0KPC90Pg0KDQoNCjx0IGhhbmdUZXh0PSAiTWVz c2FnZSBIZWFkZXI6ICAiPjx2c3BhY2UgLz4NClRoZSBNZXNzYWdlIFR5cGUgaW4gdGhlIGhlYWRl ciBpcyBzZXQgDQogICAgTWVzc2FnZVR5cGU9ICdFdmVudE5vdGlmaWNhdGlvblJlc3BvbnNlJy4g VGhlIEFDSyBmbGFnIGluIHRoZSANCiAgICBoZWFkZXIgU0hPVUxEIGJlIHNldCAnTm9BQ0snLCBt ZWFuaW5nIG5vIGZ1cnRoZXIgcmVzcG9uc2UgZm9yIA0KICAgIHRoZSBtZXNzYWdlIGlzIGV4cGVj dGVkLiBJZiB0aGUgQUNLIGZsYWcgaXMgc2V0IG90aGVyIHZhbHVlcywgDQogICAgdGhlIG1lYW5p bmcgb2YgdGhlIGZsYWcgd2lsbCB0aGVuIGJlIGlnbm9yZWQuIA0KICAgIFRoZSBTZXF1ZW5jZSBO dW1iZXIgaW4gdGhlIGhlYWRlciBTSE9VTEQga2VlcCB0aGUgc2FtZSBhcyB0aGF0IA0KICAgIG9m IHRoZSBtZXNzYWdlIHRvIGJlIHJlc3BvbmRlZCwgc28gdGhhdCB0aGUgZXZlbnQgbm90aWZpY2F0 aW4gDQogICAgbWVzc2FnZSBzZW5kZXIgY2FuIGtlZXAgdHJhY2sgb2YgdGhlIHJlc3BvbnNlcy4N CjwvdD4NCg0KPHQgaGFuZ1RleHQ9ICJNZXNzYWdlIEJvZHk6ICI+PHZzcGFjZSAvPg0KVGhlIG1l c3NhZ2UgYm9keSBmb3IgYW4gZXZlbnQgbm90aWZpY2F0aW9uIG1lc3NhZ2UgY29uc2lzdHMgDQog IGNvcnJlY3QgYWJvdmU6IGV2ZW50IG5vdGlmaWNhdGlvbiAicmVzcG9uc2UiIG1lc3NhZ2UNCg0K ICAgIG9mIChhdCBsZWFzdCkgb25lIG9yIG1vcmUgdGhhbiBvbmUgVExWcyB0aGF0IGRlc2NyaWJl IHRoZSANCiAgICBub3RpZmllZCBldmVudHMuIFRoZSBUTFYgaXMgYWxzbyBjYWxsZWQgTEZCc2Vs ZWN0IFRMViwgYW5kIGhhcyBleGFjdGx5IA0KICAgIHRoZSBzYW1lIGRhdGEgZm9ybWF0IGFzIEV2 ZW50IE5vdGlmaWNhdGlvbiBNZXNzYWdlLCBleGNlcHQgdGhlIE9wZXJhdGlvbiANCiAgICBUTFYg aW5zaWRlIHRoZSBUTFYgY29tcHJpc2VzIHRoZSBldmVudCByZXNwb25zZSBkYXRhLCBpbnN0ZWFk IG9mIHRoZSANCiAgICAnRXZlbnQgRGF0YScsIGFzIGJlbG93Og0KICBBZ2FpbiwgeW91IHNob3Vs ZCBtZW50aW9uIHRoYXQgdGhlIGVhY2ggIk9wZXJhdGlvbiBUTFYiIGluIHRoZSByZXNwb25zZSBj b3JyZXNwb25kcyBvbmUtdG8tb25lIHRvIGEgVExWIGluIHRoZSBub3RpZmljYXRpb24uDQoNCjx2 c3BhY2UgYmxhbmtMaW5lcz0iMSIgLz4NCg0KPGZpZ3VyZSBhbmNob3I9InRsdl9SZXBzb25zZV9S ZXN1bHQiPg0KPHByZWFtYmxlPg0KVGhpcyBjb250YWlucyBhIFRMViB0aGF0IGRlc2NyaWJlIHRo ZSByZXNwb25zZSByZXN1bHQgDQogICAgYXMgYmVsb3c6DQo8L3ByZWFtYmxlPg0KPGFydHdvcms+ DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogICAgIHwgICAgVHlwZSA9IE9wZXJhdGlvbnMgKFJFUE9SVCkgfCAg ICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICBQYXRoKG9yIEV2ZW50IElEPykgICAgICAgICAgICAgICAgICAg ICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgUmVzdWx0ICAgICB8ICAgUmVhc29uICAgICAg fCAgICAgICAgIENvZGUgICAgICAgICAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCjwvYXJ0 d29yaz48L2ZpZ3VyZT4NCjx0IGhhbmdUZXh0PSAiUGF0aChvciBFdmVudCBJRD8pOiAiPjx2c3Bh Y2UgLz4NCltVbmRlciBkaXNjdXNzaW9uIGFuZCBUQkRdDQo8L3Q+DQo8dCBoYW5nVGV4dD0gIlJl c3VsdDogIj48dnNwYWNlIC8+DQpUaGlzIGRlc2NyaWJlcyB0aGUgcmVjZXB0aW9uIHJlc3VsdCBv ZiB0aGUgZXZlbnQgbm90aWZpY2F0aW9uIA0KICAgIG1lc3NhZ2UgYXMgYmVsb3c6DQo8L3Q+DQo8 ZmlndXJlPjxhcnR3b3JrPg0KCVJlc3VsdCBWYWx1ZSAgICAgICAgICAgICBNZWFuaW5nDQoJJ1N1 Y2Nlc3MnICAgICAgIFRoZSBldmVudCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgcmVjZWl2ZWQuDQoJ J1Vuc3VjY2VzcycgICAgIFRoZSBldmVudCBoYXMgbm90IGJlZW4gc3VjY2Vzc2Z1bGx5IHJlY2Vp dmVkLg0KPC9hcnR3b3JrPjwvZmlndXJlPg0KDQo8dCBoYW5nVGV4dD0gIlJlYXNvbiwgQ29kZTog Ij48dnNwYWNlIC8+DQpUaGlzIGRlc2NyaWJlcyB0aGUgcmVhc29uIGFuZCBwb3NzaWJsZSBlcnJv ciBjb2RlIHdoZW4gDQogICAgdGhlIG1lc3NhZ2UgaXMgbm90IHN1Y2Nlc3NmdWxseSByZWNlaXZl ZC4gTm90ZSB0aGF0IG9ubHkgdGhlIA0KICAgIGZhaWx1cmUgYXQgdGhlIHByb3RvY29sIGxheWVy IHJhdGhlciB0aGFuIHRoZSB0cmFuc3BvcnQgbGF5ZXIgDQogICAgY2FuIGJlIGFsbG9jYXRlZCBo ZXJlLHR5cG86IG5vdCAiYWxsb2NhdGVkIiBidXQgImhhbmRsZWQiLg0KDQogdGhhdCBpcywgaWYg ZXZlbiB0aGUgaGVhZGVyIHBhcnQgb2YgdGhlIA0KICAgIG1lc3NhZ2UgdG8gYmUgcmVzcG9uZGVk IGNhbiBub3QgYmUgY29ycmVjdGx5IHJlY2VpdmVkLCB0aGUgDQogICAgcmVzcG9uc2UgdG8gdGhl IG1lc3NhZ2Ugd2lsbCBub3QgYmUgYWJsZSB0byBiZSBnZW5lcmF0ZWQgYnkgDQogICAgdGhlIHJl Y2VpdmVyLg0KPC90Pg0KPHZzcGFjZSBibGFua0xpbmVzPSIxIiAvPg0KPGxpc3Qgc3R5bGU9Imhh bmdpbmciIGhhbmdJbmRlbnQ9IjE3Ij4NCjx0IGhhbmdUZXh0PSJFZGl0b3JpYWwgTm90ZTogIj4g DQpUaGVyZSBpcyBhIGRlYmF0ZSBvbiB3aGV0aGVyIHRoZSBFdmVudCBOb3RpZmljYXRpb24gDQog ICAgUmVzcG9uc2UgTWVzc2FnZSBpcyBuZWNlc3Nhcnkgb3Igbm90LiBUaGUgcHJvIGZvciBpdCBp cyBzb21lIGV2ZW50IA0KICAgIG5vdGlmaWNhdGlvbiBzZW5kZXJzIG1heSBiZSBpbnRlcmVzdGVk IGluIGtub3dpbmcgaWYgcmVjZWl2ZXJzIA0KICAgIGhhdmUgaGFkIHN1Y2Nlc3MvdW5zdWNjZXNz IHJlY2VwdGlvbnMgb2YgdGhlIGV2ZW50cyBvciBub3QuIEFuIA0KICAgIGFsdGVybmF0aXZlIHRv IGdlbmVyYXRlIHN1Y2ggcmVzcG9uc2UgaXMgZm9yIHRoZSBwcm90b2NvbCB0byANCiAgICBkZWZp bmUgYSB1bml2ZXJzYWwgQUNLIG1lc3NhZ2Ugc28gdGhhdCBpdCBjYW4gYWN0IGFzIHJlc3BvbnNl cyANCiAgICBmb3IgYW55IHR5cGVzIG9mIG1lc3NhZ2VzIGFzIHdlbGwgYXMgdGhlIGV2ZW50IG5v dGlmaWNhdGlvbiANCiAgICBtZXNzYWdlcywgd2hlbiB0aGUgbWVzc2FnZSBzZW5kZXJzIGFyZSBp bnRlcmVzdGVkIGluIGtub3dpbmcgDQogICAgd2hldGhlciB0aGUgbWVzc2FnZXMgaGF2ZSBiZWVu IHN1Y2Nlc3NmdWxseSByZWNlaXZlZCBvciBub3QgDQogICAgKGRpZmZlcmVudCBmcm9tIHRoZSBy ZXNwb25zZXMgZm9yIHRoZSBtZXNzYWdlIHByb2Nlc3NpbmcgcmVzdWx0cykuDQo8L3Q+IA0KPC9s aXN0Pg0KPC9saXN0Pg0KPC9zZWN0aW9uPg0KPC9zZWN0aW9uPg0KDQo8IS0tICRMb2c6IEV2ZW50 TXNnLnhtbCx2ICQNCjwhLS0gUmV3cml0dGVuIGJ5IFdlaW1pbmcgV2FuZyAyMDA0LzEwLzIyDQo8 IS0tIEluY29ycGFyYXRlIExGQnNlbGVjdCBhbmQgT3BlcmF0aW9uIFRMViANCjwhLS0NCjwhLS0g UmV2aXNpb24gMS43ICAyMDA0LzA3LzE5IDA5OjM4OjE2ICBhdnJpDQo8IS0tIFZlcnNpb24gMiBj aGVja2luDQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuNiAgMjAwNC8wNi8yMyAwNTowNToyMCAgYXZy aQ0KPCEtLSBmaW5hbCBlZGl0IGZvciAwMA0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAxLjUgIDIwMDQv MDYvMjIgMDY6NTk6MjMgIGF2cmkNCjwhLS0gcmVtb3ZlDQo8IS0tDQo8IS0tIFJldmlzaW9uIDEu NCAgMjAwNC8wNi8yMiAwNjo1ODoyNSAgYXZyaQ0KPCEtLSBUZWFtIGVkaXRzIGZyb20gMDAtNw0K PCEtLQ0KPCEtLSBSZXZpc2lvbiAxLjIgIDIwMDQtMDYtMjEgMjE6NDA6NTgrMDggIGFkbWluaXN0 cmF0b3INCjwhLS0gSW5jb3JwYXJhdGUgc29tZSBjb21tZW50cyBmcm9tIEphbWFsIChKdW5lIDIx LCAyMDA0IDEwOjUwIEFNKS4gLVdlaW1pbmcNCjwhLS0NCjwhLS0gUmV2aXNpb24gMS4xICAyMDA0 LTA2LTIxIDIxOjA3OjU0KzA4ICBhZG1pbmlzdHJhdG9yDQo8IS0tIFJldmlzaW9uIGhhbmRlZCBm cm9tIEF2cmkgIC0gV2VpbWluZw0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAxLjMgIDIwMDQvMDYvMTkg MTM6MTM6MzAgIGF2cmkNCjwhLS0gRm9ybWF0dGluZw0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAxLjIg IDIwMDQvMDYvMTkgMTI6Mjk6NTIgIGF2cmkNCjwhLS0gLSBjaGFuZ2UgRW5jb2RpbmdUeXBlIHRv IFR5cGUuIChmcm9tIFdXKQ0KPCEtLSBGaWNlIGZvcm1hdHRpbmcNCjwhLS0NCjwhLS0gUmV2aXNp b24gMS4xICAyMDA0LzA2LzE3IDAzOjQ1OjAyICBhdnJpDQo8IS0tIEluaXRpYWwgcmV2aXNpb24N CjwhLS0NCiAgICAgZWRpdGVkIHdpdGggPE9YeWdlbi8+WE1MIGVkaXRvciA0LjEsIGJ5IFdlaW1p bmcgV2FuZyAmTGlnYW5nIERvbmcNCiAgICAgKioqIEV2ZW50TXNnIFYxLjAsIDIwMDQtMDYtMTMs IGNoYW5nZXMgc2luY2UgbGFzdCB2ZXJzaW9uOg0KICAgICAtIE5vbmUsIGFzIHRoZSBvcmlnaW5h bCB2ZXJzaW9uLg0KLS0+DQogIA0KDQotLSANClJvYmVydCBIYWFzDQpJQk0gWnVyaWNoIFJlc2Vh cmNoIExhYm9yYXRvcnkNClPkdW1lcnN0cmFzc2UgNA0KQ0gtODgwMyBS/HNjaGxpa29uL1N3aXR6 ZXJsYW5kDQpwaG9uZSArNDEtMS03MjQtODY5OCAgZmF4ICs0MS0xLTcyNC04NTc4ICBodHRwOi8v d3d3Lnp1cmljaC5pYm0uY29tL35yaGE= ------=_NextPart_000_0090_01C4B8F9.4151BDA0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD10ZXh0L2h0bWw7Y2hhcnNldD1JU08tODg1OS0xPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjgwMC4xMjc2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NU WUxFPg0KPC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5IaSBSb2JlcnQsPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5JIGZpbmQgbW9z dCBvZiB5b3VyIGNvbW1lbnRzIGFyZSB2YWx1YWJsZS4gSSdtIHRyeWluZyANCnRvIGluY29ycGFy YXRlIGl0LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNp emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3 OyBzaXplPTI+QXZyaSwgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMy MDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1 OyYjMjAzMDc7IHNpemU9Mj5EbyB5b3Ugd2FudCBtZSB0byBtYWtlIHRoZSBjaGFuZ2VzIG9yIHlv dSBtYWtlIGl0PyBJZiANCmZvcm1lciwgcGxzIHNlbmQgbWUgYmFjayB0aGUgbW9kaWZpZWQgWE1M IGZpbGVzIEkganVzdCB1cGRhdGVkLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIz NDM1OyYjMjAzMDc7IHNpemU9Mj5JZiBsYXR0ZXIsIEkgd2lsbCBtYXJrIHRoZSBjaGFuZ2VzLjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+ UGxzIHJlcGx5IG1lIGFzYXAgd2hlbiB5b3Ugc2VlIHRoaXMuIA0KVGhhbmtzLjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+V2VpbWluZzwv Rk9OVD48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgDQpzdHlsZT0iUEFERElORy1SSUdIVDog MHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMw MDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYgc3R5bGU9IkZPTlQ6 IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElW Pg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsm IzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9cmhh QHp1cmljaC5pYm0uY29tIGhyZWY9Im1haWx0bzpyaGFAenVyaWNoLmlibS5jb20iPlJvYmVydCBI YWFzPC9BPiANCiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAz MDc7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPXdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuIA0KICBocmVm PSJtYWlsdG86d213YW5nQG1haWwuaHppYy5lZHUuY24iPldhbmcsV2VpbWluZzwvQT4gPC9ESVY+ DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5DYzo8L0I+IDxB IHRpdGxlPWF2cmlAYWNtLm9yZyANCiAgaHJlZj0ibWFpbHRvOmF2cmlAYWNtLm9yZyI+YXZyaUBh Y20ub3JnPC9BPiA7IDxBIA0KICB0aXRsZT1ob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tIA0K ICBocmVmPSJtYWlsdG86aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbSI+S2hvc3JhdmksIEhv cm11emQgTTwvQT4gOyA8QSANCiAgdGl0bGU9Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0KICBo cmVmPSJtYWlsdG86Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIj5mb3JjZXMtcHJvdG9jb2xAaWV0 Zi5vcmc8L0E+IDsgPEEgDQogIHRpdGxlPWRvbmdsZ0BtYWlsLmh6aWMuZWR1LmNuIGhyZWY9Im1h aWx0bzpkb25nbGdAbWFpbC5oemljLmVkdS5jbiI+TGlnYW5nIA0KICBEb25nPC9BPiA7IDxBIHRp dGxlPXJhbS5nb3BhbEBub2tpYS5jb20gDQogIGhyZWY9Im1haWx0bzpyYW0uZ29wYWxAbm9raWEu Y29tIj5yYW0uZ29wYWxAbm9raWEuY29tPC9BPiA7IDxBIA0KICB0aXRsZT1oYWRpQHpueXguY29t IGhyZWY9Im1haWx0bzpoYWRpQHpueXguY29tIj5KYW1hbCBIYWRpIFNhbGltPC9BPiA8L0RJVj4N CiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlNlbnQ6PC9CPiBT YXR1cmRheSwgT2N0b2JlciAyMywgMjAwNCAyOjUzIA0KQU08L0RJVj4NCiAgPERJViBzdHlsZT0i Rk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlN1YmplY3Q6PC9CPiBSZTogW0ZvcmNlcy1w cm90b2NvbF0gUkU6IA0KICBkcmFmdC1pZXRmLWZvcmNlcy1wcm90b2NvbC0wMS0wLnR4dDwvRElW Pg0KICA8RElWPjxCUj48L0RJVj5XZWltaW5nLDxCUj5JIGhhdmUgYSBmZXcgc3VnZ2VzdGlvbnMg Zm9yIHlvdXIgc2VjdGlvbnMuIFNlZSANCiAgaW5saW5lLiBQbGVhc2UgcmV2aWV3IHRoZW0gYW5k IGluZGljYXRlIHRvIEF2cmkgaWYgc2hlIHNob3VsZCBpbmNvcnBvcmF0ZSANCiAgdGhlc2UgaW50 byB0aGUgZmluYWwgZHJhZnQuIEl0IHdvdWxkIGJlIGdvb2QgaWYgQXZyaSBjb3VsZCBkbyB0aGUg DQogIGVuZ2xpc2gtY2hlY2sgb24gdGhlc2Ugc2VjdGlvbnMgdG8gYXMgSSBhbSBub3QgYSBuYXRp dmUgZW5nbGlzaCBzcGVha2VyIA0KICBuZWl0aGVyPEJSPlJlZ2FyZHMsPEJSPi1Sb2JlcnQ8QlI+ PEJSPldhbmcsV2VpbWluZyB3cm90ZTo8QlI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkMTA4NzAx YzRiODRhJDgwMjhiYTYwJDg0NWMyMWQyQE5lY29tLmh6aWMuZWR1LmNuIA0KICB0eXBlPSJjaXRl Ij48UFJFIHdyYXA9IiI+SGkgQXZyaSwNCg0KSSd2IHVwZGF0ZWQgdGhlIFJlZGlyZWN0TXNnLCBR dWVyeU1zZywgYW5kIEV2ZW50TXNnIGFzIFhNTCBmaWxlIGluIHRoZQ0KYXR0YWNobWVudHMuIEl0 J3MgYSBwaXR5IHRoYXQgSSBqdXN0IGZpbmQgSSBjYW4gbm90IHBhc3MgdG8gcGFyc2UgdGhlIGZp bGUgYnkNCnhtbDJyZmMgYmVjYXVzZSBpdCBpbmNsdWRlZCBzb21lIG9mIHRoZSBmb3JtYXQgZGVm aW5lZCBieSB5b3UsIHRoZXJlZm9yZSBpdA0Kc2VlbXMgSSBjYW4gbm90IHZlcmlmeSB0aGUgY29y cmVjdG5lc3Mgb2YgdGhlICBmaWxlIGZvciB0aGUgeG1sIGZvcm1hdC4gSSByZWFsbHkNCndhbnQg dG8gc2F2ZSBzb21lIG9mIHlvdXIgd29yayBidXQgaXQgc2VlbXMgSSdtIG5vdCBhYmxlIHRvLiBJ ZiB5b3UgbGlrZSwgbmV4dA0KdGltZSBJIHdvdWxkIGp1c3QgdXNlIHR4dCBsaWtlIEhvcm11emQg ZGlkLg0KDQpUaGVyZSBpcyBubyBjaGFuZ2UgdG8gdGhlIGRlZmluaXRpb24gcGFydC4NCg0KSG9y bXV6ZCwgSSBoYXZlIG1vc3RseSB0cmllZCBiZXN0IHRvIGZvbGxvdyB5b3VyIGZvcm1hdCwgYnV0 IHN0aWxsIHRoZXJlIGFyZQ0Kc29tZSBwbGFjZXMgdGhhdCBJIHByZWZlciBteSBzdHlsZS4gQW55 d2F5LCBpdCBtYXR0ZXJzIGxlc3MuDQoNCnRoYW5rIHlvdS4NCldlaW1pbmcNCi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IDxBIGNsYXNzPW1vei10eHQtbGluay1yZmMyMzk2RSBo cmVmPSJtYWlsdG86YXZyaUBhY20ub3JnIj4mbHQ7YXZyaUBhY20ub3JnJmd0OzwvQT4NCiAgPC9Q UkU+DQogICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPk9uIDIyIG9rdCAy MDA0LCBhdCAwMi4xOSwgS2hvc3JhdmksIEhvcm11emQgTSB3cm90ZToNCg0KICAgIDwvUFJFPg0K ICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPkkgc2VudCB5b3UgdGhl IGVudGlyZSBzZWN0aW9uIHNvIHlvdSBjYW4ganVzdCBwdXQgaXQgaW4uIFlvdSBkb24ndCBoYXZl DQp0byBmaW5kIGFueSBkaWZmcy4gSSBoYXZlIGF0dGFjaGVkIGl0IGFnYWluIGZvciB5b3VyIGNv bnZlbmllbmNlLg0KICAgICAgPC9QUkU+PC9CTE9DS1FVT1RFPjxQUkUgd3JhcD0iIj5kb2Vzbid0 IHF1aXRlIHdvcmsgbGlrZSB0aGF0Lg0KYnV0IGkgaGF2ZSBwdXQgaW4gdGhlIGNoYW5nZXMgYXMg ZmFyIGFzIGkgY2FuIHRlbGwuIGNoZWNrIHRvIG1ha2Ugc3VyZQ0KaSBnb3QgaXQgcmlnaHQuDQoN CjxBIGNsYXNzPW1vei10eHQtbGluay1mcmVldGV4dCBocmVmPSJodHRwOi8vcHNnLmNvbS9+YXZy aS9mb3JjZXMvZHJhZnQvZHJhZnQtaWV0Zi1mb3JjZXMtcHJvdG9jb2wtMDEtMS50eHQiPmh0dHA6 Ly9wc2cuY29tL35hdnJpL2ZvcmNlcy9kcmFmdC9kcmFmdC1pZXRmLWZvcmNlcy1wcm90b2NvbC0w MS0xLnR4dDwvQT4NCg0KICAgIDwvUFJFPg0KICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+ PFBSRSB3cmFwPSIiPkJUVywgd2hlcmUgYXJlIHlvdSBhdCB0aGlzIG1vbWVudD8gaW4gdGhlIFVT IG9yIEV1cm9wZT8gSnVzdCBjdXJpb3VzIGluDQpjYXNlIHdlIG5lZWQgdG8gc2V0dXAgc29tZSBj b25mZXJlbmNlIGNhbGxzLg0KICAgICAgPC9QUkU+PC9CTE9DS1FVT1RFPjxQUkUgd3JhcD0iIj50 aGlzIHdlZWsgaW4gdGhlIHVzIC0gZWFzdCBjb2FzdC4NCg0KYS4NCg0KICAgIDwvUFJFPjwvQkxP Q0tRVU9URT48UFJFIHdyYXA9IiI+PCEtLS0tPg0KDQogIDwvUFJFPjxQUkUgd3JhcD0iIj4mbHQ7 P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Jmd0Ow0KJmx0OyEtLSBlZGl0ZWQg d2l0aCAmbHQ7T1h5Z2VuLyZndDtYTUwgZWRpdG9yIDQuMSwgYnkgV2VpbWluZyBXYW5nICZhbXA7 IExpZ2FuZyBEb25nIA0KICAgICAqKiogUmVkaXJlY3RNc2cgVjEuMCwgMjAwNC0wNi0xMywgY2hh bmdlcyBzaW5jZSBsYXN0IHZlcnNpb246DQogICAgIC0gTm9uZSwgYXMgdGhlIG9yaWdpbmFsIHZl cnNpb24uDQogICAgICoqKiBSZWRpcmVjdE1zZ1YxLjEsIDIwMDQtMDYtMTguDQotLSZndDsNCg0K Jmx0O3NlY3Rpb24gYW5jaG9yPSJSZWRpcmVjdE1zZyIgdGl0bGU9IlBhY2tldCBSZWRpcmVjdCBN ZXNzYWdlIiZndDsNCg0KJmx0O3QmZ3Q7UGFja2V0IHJlZGlyZWN0IG1lc3NhZ2UgaXMgdXNlZCB0 byB0cmFuc2ZlciBkYXRhIHBhY2tldHMgDQogICAgYmV0d2VlbiBDRSBhbmQgRkUuIFVzdWFsbHkg dGhlc2UgZGF0YSBwYWNrZXRzIGFyZSBJUCBwYWNrZXRzLCANCiAgICB0aG91Z2ggdGhleSBtYXkg c29tZXRpbWVzIGFzc29jaWF0ZWQgd2l0aCBzb21lIG1ldGFkYXRhIA0KICAgIGdlbmVyYXRlZCBi eSBvdGhlciBMRkJzIGluIHRoZSBtb2RlbCwgb3IgdGhleSBtYXkgDQogICAgb2NjYXNpb25hbGx5 IGJlIG90aGVyIHByb3RvY29sIHBhY2tldHMsIHdoaWNoIHVzdWFsbHkgaGFwcGVuIA0KICAgIHdo ZW4gQ0UgYW5kIEZFIGFyZSBqb2ludGx5IGltcGxlbWVudGluZyBzb21lIGhpZ2gtdG91Y2ggDQog ICAgb3BlcmF0aW9ucy4gUGFja2V0cyByZWRpcmVjdGVkIGZyb20gRkUgdG8gQ0UgYXJlIHRoZSBk YXRhIA0KICAgIHBhY2tldHMgdGhhdCBjb21lIGZyb20gZm9yd2FyZGluZyBwbGFuZSwgYW5kIHVz dWFsbHkgYXJlIHRoZSANCiAgICBkYXRhIHBhY2tldHMgdGhhdCBuZWVkIGhpZ2gtdG91Y2ggb3Bl cmF0aW9ucyBpbiBDRS48L1BSRT48L0JMT0NLUVVPVEU+Jm5ic3A7Li4uIA0KICBvciBwYWNrZXRz IGZvciB3aGljaCB0aGUgSVAgZGVzdGluYXRpb24gYWRkcmVzcyBpcyB0aGUgTkUuIFtOb3RlIHRo YXQgSSANCiAgZGlzdGluZ3Vpc2ggaGlnaC10b3VjaCBvcGVyYXRpb25zIGZyb20gZW5kcG9pbnQg cHJvdG9jb2wgcHJvY2Vzc2luZ108QlI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkMTA4NzAxYzRi ODRhJDgwMjhiYTYwJDg0NWMyMWQyQE5lY29tLmh6aWMuZWR1LmNuIA0KICB0eXBlPSJjaXRlIj48 UFJFIHdyYXA9IiI+IFBhY2tldHMgDQogICAgcmVkaXJlY3RlZCBmcm9tIENFIHRvIEZFIGFyZSB0 aGUgZGF0YSBwYWNrZXRzIHRoYXQgYXJlIA0KICAgIGdlbmVyYXRlZCBieSBDRSBhbmQgYXJlIGRl Y2lkZWQgYnkgQ0UgdG8gcHV0IGludG8gZm9yd2FyZGluZyANCiAgICBwbGFuZSBpbiBGRS4mbHQ7 L3QmZ3Q7DQoNCiAgPC9QUkU+PC9CTE9DS1FVT1RFPmRvbid0IHdyaXRlICJnZW5lcmF0ZWQgYnkg dGhlIENFIi4gU3VjaCBwYWNrZXRzIGNvdWxkIA0KICB2ZXJ5IHdlbGwgYmUgcGFja2V0cyB0aGF0 IGluaXRpYWxseSB3ZXJlIHJlZGlyZWN0ZWQgZnJvbSBhbiBGRS4gSW5zdGVhZCwganVzdCANCiAg c2F5ICJjb21lIGZyb20gdGhlIENFIi48QlI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkMTA4NzAx YzRiODRhJDgwMjhiYTYwJDg0NWMyMWQyQE5lY29tLmh6aWMuZWR1LmNuIA0KICB0eXBlPSJjaXRl Ij48UFJFIHdyYXA9IiI+Jmx0O3QmZ3Q7QnkgcHJvcGVybHkgY29uZmlndXJpbmcgcmVsYXRlZCBM RkJzIGluIEZFLCBhIHBhY2tldCBjYW4gYWxzbyANCiAgICBiZSBtaXJyb3JlZCB0byBDRSBpbnN0 ZWFkIG9mIHB1cmVseSByZWRpcmVjdGVkIHRvIENFLCBpLmUuLCANCiAgICB0aGUgcGFja2V0IGlz IGR1cGxpY2F0ZWQgYW5kIG9uZSBpcyByZWRpcmVjdGVkIHRvIENFIGFuZCB0aGUgDQogICAgb3Ro ZXIgY29udGludWVzIGl0cyB3YXkgaW4gdGhlIExGQiB0b3BvbG9neS4gJmx0Oy90Jmd0Ow0KDQog IDwvUFJFPjwvQkxPQ0tRVU9URT5TaWRlIG5vdGU6IHdlIHdpbGwgaGF2ZSB0byBkZWZpbmUgaG93 IHRoZSBwYWNrZXQgaGVhZGVyIA0KICBvbmx5IGNhbiBiZSBwYXNzZWQgdG8gdGhlIENFLCBhbmQg bGVhdmUgdGhlIHBheWxvYWQgaW4gdGhlIEZFLCB1bnRpbCB0aGUgQ0UgDQogIGRlY2lkZXMgd2hh dCB0byBkbyB3aXRoIHRoZSBwYWNrZXQuPEJSPjxCUj5TZWNvbmQgc2lkZSBub3RlOiB3ZSBuZWVk IHRvIA0KICBzcGVjaWZ5IHdoeSB3ZSBjb25zaWRlciB0aGF0IHBhY2tldF9yZWRpcmVjdCBkZXNl cnZlcyBpdHMgb3duIG1lc3NhZ2UgdHlwZSwgDQogIGFuZCBub3Qgc2ltcGx5IGJlIHRyZWF0ZWQg YXMgYW4gZXZlbnQgZmlyZWQgYnkgdGhlIFJlZGlyZWN0IExGQiB0aGF0IGNvbnRhaW5zLCANCiAg YXMgcGFydCBvZiB0aGUgZXZlbnQgZGF0YSwgdGhlIHBhY2tldCBpdHNlbGYuIE15IHRoaW5raW5n IGlzIHRoYXQgdXNpbmcgYSANCiAgc3BlY2lmaWMgbWVzc2FnZSB0eXBlIGlzIGltcG9ydGFudCB0 byBsZXQgdGhlIENFIGRpc3Rpbmd1aXNoIHByb21wdGx5IGlmIHRoZSANCiAgbWVzc2FnZSBpcyBh biBGRS1pbnRlcm5hbCBldmVudCBvciBhbiBleHRlcm5hbCBwYWNrZXQgdGhhdCB3YXMganVzdCBm b3J3YXJkZWQuIA0KICBTb21ldGhpbmcgbGlrZSB0aGlzIHNob3VsZCBiZSB3cml0dGVuIGluIHRo ZSBpbnRybyBvZiB0aGlzIHNlY3Rpb24uIFdlaW1pbmcgDQogID88QlI+DQogIDxCTE9DS1FVT1RF IGNpdGU9bWlkMTA4NzAxYzRiODRhJDgwMjhiYTYwJDg0NWMyMWQyQE5lY29tLmh6aWMuZWR1LmNu IA0KICB0eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+Jmx0O3ZzcGFjZSBibGFua0xpbmVzPSIxIiAv Jmd0Ow0KJmx0O2xpc3Qgc3R5bGU9ImhhbmdpbmciIGhhbmdJbmRlbnQ9IjE3IiZndDsNCiZsdDt0 IGhhbmdUZXh0ID0gIkVkaXRvcmlhbCBOb3RlOiAiJmd0OyANClRoZXJlIGFyZSBhbHNvIGRpc2N1 c3Npb25zIG9uIGhvdyBMRkJzIGluIEZFIG1vZGVsIHRoYXQgYXJlIA0KICAgIHJlbGF0ZWQgdG8g cGFja2V0IHJlZGlyZWN0IG9wZXJhdGlvbnMgc2hvdWxkIGJlIGRlZmluZWQuIEFsdGhvdWdoIA0K ICAgIGl0IGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgZm9yY2VzIHByb3RvY29sLCBob3cgdG8gZGVm aW5lIHRoZSBMRkJzIA0KICAgIGFmZmVjdCB0aGUgUGFja2V0IFJlZGlyZWN0IE1lc3NhZ2UgZGVz Y3JpYmVkIGhlcmUuIEJlY2F1c2UgY3VycmVudGx5DQogICAgaXQgaXMgc3RpbGwgaW4gcHJvZ3Jl c3MgaW4gRkUgbW9kZWwgb24gaG93IHRvIGRlZmluZSBzdWNoIExGQnMsIA0KICAgIHdlIHRyeSB0 byBwb3N0IHNvbWUgdGhvdWdodHMgb24gdGhpcyBoZXJlIGZvciBkaXNjdXNzaW9uLiBUaGV5IA0K ICAgIHdpbGwgYmUgcmVtb3ZlZCBsYXRlciBhbG9uZyB3aXRoIHRoZSBwcm9ncmVzcyBvZiB0aGUg RkUgbW9kZWwgd29yay4NCiZsdDsvdCZndDsNCiZsdDt2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLyZn dDsNCiZsdDt0IGhhbmdUZXh0ID0iICAgICBUaG91Z2h0IDE6ICImZ3Q7DQpUbyBkZWZpbmUgTEZC cyBjYWxsZWQgJ1JlZGlyZWN0U2luaycgYW5kICdSZWRpcmVjdFRhcCcgZm9yDQpwYWNrZXQgcmVk aXJlY3QuJmx0Oy90Jmd0Ow0KJmx0O3QmZ3Q7QW4gTEZCIGluIEZFIGNhbGxlZCAnUmVkaXJlY3RT aW5rJyBpcyByZXNwb25zaWJsZSB0byBjb2xsZWN0IA0KICAgIGRhdGEgcGFja2V0cyB0aGF0IG5l ZWQgdG8gYmUgcmVkaXJlY3RlZCB0byBDRS4gRnJvbSB0aGUgDQogICAgcGVyc3BlY3RpdmUgb2Yg dGhlIEZFIExGQiB0b3BvbG9neSwgdGhlICdSZWRpcmVjdFNpbmsnIExGQiANCiAgICBpcyBhbiBM RkIgd2l0aCBvbmx5IG9uZSBpbnB1dCBwb3J0IGFuZCB3aXRob3V0IGFueSBvdXRwdXQgDQogICAg cG9ydCwgYW5kIHRoZSBpbnB1dCBwb3J0IGNhbiB0aGVuIGJlIGNvbm5lY3RlZCB0byBhbnkgb3Ro ZXIgDQogICAgTEZCIGluIEZFIG1vZGVsIGJ5IG1lYW5zIG9mIGEgZGF0YXBhdGggaW4gdGhlIGZv cndhcmRpbmcgDQogICAgcGxhbmUuIEZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBGb3JDRVMg cHJvdG9jb2wgbGF5ZXIsIA0KICAgIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgd2lsbCBnZW5lcmF0 ZSB0aGUgUGFja2V0IFJlZGlyZWN0IA0KICAgIE1lc3NhZ2VzIHdoZW4gaXQgcmVjZWl2ZXMgZGF0 YSBwYWNrZXRzIGZyb20gZm9yd2FyZGluZyBwbGFuZS4NCiZsdDsvdCZndDsNCiZsdDt2c3BhY2Ug YmxhbmtMaW5lcz0iMSIgLyZndDsNCiZsdDt0Jmd0O0FuIExGQiBpbiBGRSBjYWxsZWQgJ1JlZGly ZWN0VGFwJyBpcyByZXNwb25zaWJsZSB0byByZWNlaXZlIA0KICAgIGRhdGEgcGFja2V0cyB0aGF0 IGFyZSByZWRpcmVjdGVkIGZyb20gQ0UuIEZyb20gdGhlIHBlcnNwZWN0aXZlIA0KICAgIG9mIHRo ZSBGRSBMRkIgdG9wb2xvZ3ksIHRoZSAnUmVkaXJlY3RUYXAnIExGQiBpcyBhbiBMRkIgd2l0aCAN CiAgICBvbmx5IG9uZSBvdXRwdXQgcG9ydCBhbmQgd2l0aG91dCBhbnkgaW5wdXQgcG9ydCwgYW5k IHRoZSANCiAgICBvdXRwdXQgcG9ydCBjYW4gdGhlbiBiZSBjb25uZWN0ZWQgdG8gYW55IG90aGVy IExGQiBpbiBGRSANCiAgICBtb2RlbCBieSBtZWFucyBvZiBhIGRhdGFwYXRoIGluIHRoZSBmb3J3 YXJkaW5nIHBsYW5lLiBGcm9tIA0KICAgIHRoZSBwZXJzcGVjdGl2ZSBvZiBGb3JDRVMgcHJvdG9j b2wgbGF5ZXIsIHRoZSAnUmVkaXJlY3RUYXAnIA0KICAgIExGQiBjYW4gcmVjZWl2ZSB0aGUgUGFj a2V0IFJlZGlyZWN0IE1lc3NhZ2VzIGZyb20gQ0UsIGFuZCANCiAgICB1bi1lbmNhcHN1bGF0ZSB0 aGUgZGF0YSBwYWNrZXRzIGZyb20gdGhlIG1lc3NhZ2UgYW5kIHB1dCANCiAgICB0aGVtIHRvIGRh dGFwYXRocyBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS4gQWN0dWFsbHkgdGhlIA0KICAgICdSZWNp cmVjdFRhcCcgTEZCIGFjdHMgbW9yZSBsaWtlIGEgdHJhbnNjb2RlciB0aGF0IHRyYW5zZmVycyAN CiAgICB0aGUgRm9yQ0VTIHByb3RvY29sIG1lc3NhZ2VzIHRvIG5vcm1hbCBkYXRhIHBhY2tldHMg aW4gSVAgDQogICAgZm9yd2FyZGluZyBwbGFuZS4gQXMgYSByZXN1bHQsIGlmIHdlIG5lZWQgdG8g aGF2ZSByZWRpcmVjdGVkIA0KICAgIHBhY2tldHMgY29ubmVjdGVkIHRvIHNvbWUgTEZCIChzYXkg YSBTY2hlZHVsZXIpIGluIEZFIG1vZGVsLCANCiAgICB3ZSBvbmx5IG5lZWQgdG8gY29ubmVjdCB0 aGUgJ1JlZGlyZWN0VGFwIExGQiB0byB0aGUgU2NoZWR1bGVyIA0KICAgIExGQiBkaXJlY3RseSB2 aWEgYSBkYXRhcGF0aCBhcyBmb2xsb3dzOg0KJmx0O3ZzcGFjZSBibGFua0xpbmVzPSIxIiAvJmd0 Ow0KJmx0O2ZpZ3VyZSBhbmNob3I9IkxGQl9SZWRpcmVjdCImZ3Q7Jmx0O2FydHdvcmsmZ3Q7DQog ICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgKy0tLS0t LS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICB8IFJlZGlyZWN0VGFwIExGQiB8LS0t LS0tJmd0O3wgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tKyAgICAgICB8ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBTY2hlZHVsZXIgfA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRnJvbSBvdGhlciBMRkIgICAtLS0tJmd0O3wgICAgTEZCICAgIHwNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tKw0KJmx0Oy9hcnR3b3JrJmd0OyZsdDsvZmlndXJlJmd0Ow0KJmx0Oy90 Jmd0Ow0KJmx0O3ZzcGFjZSBibGFua0xpbmVzPSIxIiAvJmd0Ow0KJmx0O3QmZ3Q7QnkgdXNlIG9m IHNldmVyYWwgJ1JlZGlyZWN0U2luaycgTEZCcyBhbmQgc2V2ZXJhbCAnUmVkaXJlY3RUYXAnIA0K ICAgIExGQnMgdGhhdCBjb25uZWN0IHRvIHNldmVyYWwgZGlmZmVyZW50IGRhdGFwYXRocyBpbiBG RSANCiAgICBmb3J3YXJkaW5nIHBsYW5lLCBtdWx0aXBsZSBwYWNrZXQgcmVkaXJlY3QgcGF0aHMg YmV0d2VlbiANCiAgICBDRSBhbmQgRkUgY2FuIGJlIGNvbnN0cnVjdGVkLiAmbHQ7L3QmZ3Q7DQom bHQ7dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8mZ3Q7DQombHQ7dCBoYW5nVGV4dCA9IiAgICAgVGhv dWdodCAyOiAiJmd0Ow0KICAgIFRoZXJlIG1pZ2h0IGJlIGFub3RoZXIgd2F5IGEgcGFja2V0IGNv dWxkIGJlIHJlZGlyZWN0ZWQ6DQogICAgZGlyZWN0bHkgYnkgYSBmb3J3YXJkaW5nIHBhdGgsIGUu Zy4sIGJ5IEZQR0EvQVNJQy9OUCBtaWNyb2NvZGUuIEluIA0KICAgIHN1Y2ggYSBjYXNlIHdlIGRv IG5vdCBuZWVkIHRvIHB1dCBpbiBhIGxvdCBvZiBzbWFydG5lc3MuIFByb2JhYmx5IA0KICAgIGEg bGluayBsYXllciBvciBldmVuIG5ldHdvcmsgbGV2ZWwgaGVhZGVyIGlzIGVub3VnaC4gVGhlIHJl Y2VpdmVyIA0KICAgIGRlbXV4ZXMgaXQgb25seSBiYXNlZCBvbiBzb21lIHByb3RvY29sIHR5cGUg aW4gdGhlIGxpbmsgbGF5ZXIgb3IgDQogICAgbmV0d29yayB0cmFuc3BvcnQgbGF5ZXIuIFRoZSBw cm9zIGZvciB0aGlzIGFwcHJhb2NoIGlzIGl0IG1heSANCiAgICBwcm92aWRlIGEgZmFzdCBhbmQg Y29zdC1lZmZlY3RpdmUgcGF0aCBmb3IgcGFja2V0IHJlZGlyZWN0LiBUaGUgDQogICAgY29ucyBm b3IgdGhpcyBpcyBpdCBtYXkgbW9yZSBvciBsZXNzIGNvbmZ1c2VzIHRoZSBGcCByZWZlcmVuY2Ug DQogICAgcG9pbnQgZGVmaW5pdGlvbiBpbiBGb3JDRVMgZnJhbWV3b3JrLiANCiZsdDsvdCZndDsN CiZsdDsvbGlzdCZndDsNCiZsdDt2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLyZndDsNCiZsdDt0Jmd0 O1dlIGRlc2NyaWJlIHRoZSBQYWNrZXQgUmVkaXJlY3QgTWVzc2FnZSBkYXRhIGZvcm1hdCBpbiBk ZXRhaWxzIA0KICAgIGFzIGZvbGxvd3M6Jmx0Oy90Jmd0Ow0KJmx0O2xpc3Qgc3R5bGU9Imhhbmdp bmciIGhhbmdJbmRlbnQ9IjEiJmd0Ow0KJmx0O3QgaGFuZ1RleHQ9ICJNZXNzYWdlIERpcmVjdGlv bjogICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KQ0UgdG8gRkUgb3IgRkUgdG8gQ0UNCiZsdDsvdCZn dDsNCg0KDQombHQ7dCBoYW5nVGV4dD0gIk1lc3NhZ2UgSGVhZGVyOiAgIiZndDsmbHQ7dnNwYWNl IC8mZ3Q7DQpUaGUgTWVzc2FnZSBUeXBlIGluIHRoZSBoZWFkZXIgaXMgc2V0IHRvIA0KICAgIE1l c3NhZ2VUeXBlPSAnUGFja2V0UmVkaXJlY3QnLiBUaGUgQUNLIGZsYWdzIGluIHRoZSBoZWFkZXIg DQogICAgU0hPVUxEIGJlIHNldCAnTm9BQ0snLCBtZWFuaW5nIG5vIHJlc3BvbnNlIGlzIGV4cGVj dGVkIGJ5IHRoaXMgDQogICAgbWVzc2FnZS4gSWYgdGhlIEFDSyBmbGFnIGlzIHNldCBvdGhlciB2 YWx1ZXMsIHRoZSANCiAgICBtZWFuaW5ncyB3aWxsIGJlIGlnbm9yZWQuDQombHQ7L3QmZ3Q7DQoN Cg0KJmx0O3QgaGFuZ1RleHQ9ICJNZXNzYWdlIEJvZHk6ICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0K Q29uc2lzdHMgb2Ygb25lIG9yIG1vcmUgVExWcywgd2l0aCBldmVyeSBUTFYgaGF2aW5nIHRoZSAN CiAgICBmb2xsb3dpbmcgZGF0YSBmb3JtYXQ6DQombHQ7L3QmZ3Q7DQoNCiAgPC9QUkU+PC9CTE9D S1FVT1RFPg0KICA8QkxPQ0tRVU9URSBjaXRlPW1pZDEwODcwMWM0Yjg0YSQ4MDI4YmE2MCQ4NDVj MjFkMkBOZWNvbS5oemljLmVkdS5jbiANCiAgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPiZsdDtm aWd1cmUgYW5jaG9yPSJ0bHZfUmVkaXJlY3RfRGF0YSImZ3Q7DQombHQ7YXJ0d29yayZndDsNCiAg ICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgIFR5cGUgPSBMRkJzZWxlY3Qg ICAgICAgfCAgICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICB8DQogICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIExGQiBDbGFzcyBJRCAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICBMRkIgSW5zdGFuY2UgSUQgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBPcGVyYXRpb2luIFRMViAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQogICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIH4gICAg ICAgICAgICAgICAgICAgICAgICAgICAuLi4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB+DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBPcGVyYXRp b2luIFRMViAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgIC4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQogICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogIA0KJmx0Oy9hcnR3b3JrJmd0OyZsdDsvZmlndXJlJmd0Ow0KDQombHQ7dCBoYW5n VGV4dD0gIkxGQiBjbGFzcyBJRDogIiZndDsmbHQ7dnNwYWNlIC8mZ3Q7DQpUaGVyZSBhcmUgb25s eSB0d28gcG9zc2libGUgTEZCIGNsYXNzZXMgaGVyZSwgdGhlIA0KICAgICdSZWRpcmVjdFNpbmsn IExGQiBvciB0aGUgJ1JlZGlyZWN0VGFwJyBMRkIuIElmIHRoZSBtZXNzYWdlIGlzIA0KICAgIGZy b20gRkUgdG8gQ0UsIHRoZSBMRkIgY2xhc3Mgc2hvdWxkIGJlICdSZWRpcmVjdFNpbmsnLiBJZiB0 aGUgDQogICAgbWVzc2FnZSBpcyBmcm9tIENFIHRvIEZFLCB0aGUgTEZCIGNsYXNzIHNob3VsZCBi ZSAnUmVkaXJlY3RUYXAnLg0KJmx0Oy90Jmd0Ow0KDQogIDwvUFJFPjwvQkxPQ0tRVU9URT5XaHkg cmVzdHJpY3QgdGhpcyA/IElmIGFueSBvdGhlciBMRkIgd2FudHMgdG8gZ2VuZXJhdGUgYSANCiAg cGFja2V0IHJlZGlyZWN0IHRvIHRoZSBDRSwgbGV0IGhpbSBkbyBpdCAhPEJSPg0KICA8QkxPQ0tR VU9URSBjaXRlPW1pZDEwODcwMWM0Yjg0YSQ4MDI4YmE2MCQ4NDVjMjFkMkBOZWNvbS5oemljLmVk dS5jbiANCiAgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPiZsdDt0IGhhbmdUZXh0PSAiSW5zdGFu Y2UgSUQ6ICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KSW5zdGFuY2UgSUQgZm9yIHRoZSAnUmVkaXJl Y3RTaW5rJyBMRkIgb3IgJ1JlZGlyZWN0VGFwJyBMRkIuDQombHQ7L3QmZ3Q7DQoNCg0KJmx0O3Qg aGFuZ1RleHQ9ICJPcGVyYXRpb24gVExWOiAiJmd0OyZsdDt2c3BhY2UgLyZndDsNClRoaXMgaXMg YSBUTFYgZGVzY3JpYmluZyBvbmUgcGFja2V0IG9mIGRhdGEgdG8gYmUgZGlyZWN0ZWQgDQogICAg dmlhIHRoZSBzcGVjaWZpZWQgTEZCIGFib3ZlLiBUaGUgb3JkZXIgb2YgdGhlIGRhdGEgbnVtYmVy IGlzIA0KICAgIGFsc28gdGhlIG9yZGVyIHRoZSBkYXRhIHBhY2tldCBhcnJpdmVzIHRoZSByZWRp cmVjdG9yIExGQiwgdGhhdCANCiAgICBpcywgdGhlIFJlZGlyZWN0ZWQgRGF0YSAjMSBzaG91bGQg YXJyaXZlIGVhcmxpZXIgdGhhbiB0aGUgDQogICAgUmVkaXJlY3RlZCBEYXRhICMyIGluIHRoaXMg cmVkaXJlY3RvciBMRkIuIFRoZSBUTFYgZm9ybWF0IGlzIA0KICAgIGFzIGZvbGxvd3M6DQombHQ7 L3QmZ3Q7DQogIDwvUFJFPjwvQkxPQ0tRVU9URT5JZiB3aGF0IHlvdSBtZWFuIGlzIHNlcXVlbmNp bmcgdGhlIHJlZGlyZWN0ZWQgcGFja2V0IHRoZW4gDQogIEkgdGhpbmsgaXQgaXMgZGFuZ2Vyb3Vz LiBBc3N1bWUgeW91IHVzZSBVRFAgdG8gdHJhbnNwb3J0IHRoZSByZWRpcmVjdGVkIA0KICBwYWNr ZXRzIGZyb20gdGhlIENFIHRvIHRoZSBGRS4gSWYgb25lIGlzIGxvc3QsIHRoZW4gd2hhdCB3aWxs IHRoZSBGRSBkbyB3aXRoIA0KICB0aGUgbmV4dCBvbmVzID88QlI+DQogIDxCTE9DS1FVT1RFIGNp dGU9bWlkMTA4NzAxYzRiODRhJDgwMjhiYTYwJDg0NWMyMWQyQE5lY29tLmh6aWMuZWR1LmNuIA0K ICB0eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+DQombHQ7ZmlndXJlIGFuY2hvcj0idGx2X1JlZGly ZWN0ZWRfRGF0YSImZ3Q7Jmx0O2FydHdvcmsmZ3Q7DQogICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAg VHlwZSA9IE9wZXJhdGlvbnMgKFBBWUxPQUQpfCAgICAgICAgICAgICAgIExlbmd0aCAgICAgICAg ICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBQYXRoKG9y IFNlcXVlbmNlIE51bWJlcj8pICAgICAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIH4g ICAgICAgICAgICAgICAgICAgICAgICBSZWRpcmVjdGVkIERhdGEgICAgICAgICAgICAgICAgICAg ICAgICB+DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQombHQ7L2FydHdvcmsmZ3Q7Jmx0Oy9maWd1cmUmZ3Q7DQom bHQ7dCBoYW5nVGV4dD0gIlBhdGgob3IgU2VxdWVuY2UgTnVtYmVyPyk6ICImZ3Q7Jmx0O3ZzcGFj ZSAvJmd0Ow0KW1VuZGVyIGRpc2N1c3Npb24gYW5kIFRCRF0NCiZsdDsvdCZndDsNCiZsdDt0IGhh bmdUZXh0PSAiVHlwZTogIiZndDsmbHQ7dnNwYWNlIC8mZ3Q7DQpbVEJEXQ0KJmx0Oy90Jmd0Ow0K DQombHQ7dCBoYW5nVGV4dD0gIlJlZGlyZWN0ZWQgRGF0YTogIiZndDsmbHQ7dnNwYWNlIC8mZ3Q7 DQpUaGlzIGZpZWxkIHdpbGwgbWFrZSBhIGRldGFpbGVkIGRlc2NyaXB0aW9uIG9mIHRoZSBkYXRh IHRvIA0KICAgIGJlIHJlZGlyZWN0ZWQgYXMgd2VsbCBhcyB0aGUgZGF0YSBpdHNlbGYuIFRoZSBl bmNvZGluZyBvZiB0aGUgDQogICAgZGVzY3JpcHRpb24gaXMgYmFzZWQgb24gdGhlIEZvckNFUyBG RSBtb2RlbCBpZiB0aGUgcmVkaXJlY3RvciANCiAgICBMRkIgaXMgZGVmaW5lZCBieSBGRSBtb2Rl bCwgb3IgYmFzZWQgb24gdmVuZG9yIHNwZWNpZmljYXRpb25zIA0KICAgIGlmIHRoZSByZWRpcmVj dG9yIExGQiBpcyBkZWZpbmVkIGJ5IHZlbmRvcnMuIFRoZSBkZXNjcmlwdGlvbiANCiAgICB3aWxs IHVzdWFsbHkgaW5jbHVkZSB0aGUgbmFtZSAob3IgdGhlIG5hbWUgSUQpIG9mIHRoZSByZWRpcmVj dGVkIA0KICAgIHBhY2tldCBkYXRhIChzdWNoIGFzICdJUHY0IFBhY2tldCcsICdJUHY2IFBhY2tl dCcpLCBhbmQgdGhlIA0KICAgIHBhY2tldCBkYXRhIGl0c2VsZi4gSXQgbWF5IGFsc28gaW5jbHVk ZSBzb21lIG1ldGFkYXRhIChtZXRhZGF0YSANCiAgICBuYW1lIChvciBuYW1lIElEKSBhbmQgaXRz IHZhbHVlKWFzc29jaWF0ZWQgd2l0aCB0aGUgcmVkaXJlY3RlZCANCiAgICBkYXRhIHBhY2tldC4N CiZsdDsvdCZndDsNCiZsdDsvbGlzdCZndDsNCiZsdDsvc2VjdGlvbiZndDsNCg0KJmx0OyEtLSAk TG9nOiBSZWRpcmVjdE1zZy54bWwsdiAkDQombHQ7IS0tIFJld3JpdHRlbiBieSBXZWltaW5nIFdh bmcgMjAwNC8xMC8yMg0KJmx0OyEtLSBJbmNvcnBhcmF0ZSBMRkJzZWxlY3QgYW5kIE9wZXJhdGlv biBUTFYgDQombHQ7IS0tDQombHQ7IS0tIFJldmlzaW9uIDEuNyAgMjAwNC8wNy8xOSAwOTozNzow NSAgYXZyaQ0KJmx0OyEtLSBWZXJzaW9uIDIgY2hlY2tpbg0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZp c2lvbiAxLjYgIDIwMDQvMDYvMjMgMDU6MDU6MzQgIGF2cmkNCiZsdDshLS0gZmluYWwgZWRpdCBm b3IgMDANCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS41ICAyMDA0LzA2LzIyIDA3OjAyOjM3 ICBhdnJpDQombHQ7IS0tIHJlbW92ZQ0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZpc2lvbiAxLjQgIDIw MDQvMDYvMjIgMDc6MDE6MDAgIGF2cmkNCiZsdDshLS0gVGVhbSBFZGl0IGZyb20gMDAtNw0KJmx0 OyEtLQ0KJmx0OyEtLSBSZXZpc2lvbiAxLjIgIDIwMDQtMDYtMjEgMjE6NDA6NDErMDggIGFkbWlu aXN0cmF0b3INCiZsdDshLS0gSW5jb3JwYXJhdGUgc29tZSBjb21tZW50cyBmcm9tIEphbWFsIChK dW5lIDIxLCAyMDA0IDEwOjUwIEFNKS4gLVdlaW1pbmcNCiZsdDshLS0NCiZsdDshLS0gUmV2aXNp b24gMS4xICAyMDA0LTA2LTIxIDIxOjA5OjQxKzA4ICBhZG1pbmlzdHJhdG9yDQombHQ7IS0tIFJl dmlzaW9uIGhhbmRlZCBmcm9tIEF2cmkuIC0gV2VpbWluZw0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZp c2lvbiAxLjMgIDIwMDQvMDYvMTkgMTM6MTE6MTIgIGF2cmkNCiZsdDshLS0gTGluZWZlZWRzDQom bHQ7IS0tDQombHQ7IS0tIFJldmlzaW9uIDEuMiAgMjAwNC8wNi8xOSAxMzowNTowMCAgYXZyaQ0K Jmx0OyEtLSBhbmNob3JzDQombHQ7IS0tDQombHQ7IS0tIFJldmlzaW9uIDEuMSAgMjAwNC8wNi8x NyAwMzo0NTo1NSAgYXZyaQ0KJmx0OyEtLSBJbml0aWFsIHJldmlzaW9uDQombHQ7IS0tIA0KICAg ICBlZGl0ZWQgd2l0aCAmbHQ7T1h5Z2VuLyZndDtYTUwgZWRpdG9yIDQuMSwgYnkgV2VpbWluZyBX YW5nICZhbXA7IExpZ2FuZyBEb25nIA0KICAgICAqKiogUmVkaXJlY3RNc2cgVjEuMCwgMjAwNC0w Ni0xMywgY2hhbmdlcyBzaW5jZSBsYXN0IHZlcnNpb246DQogICAgIC0gTm9uZSwgYXMgdGhlIG9y aWdpbmFsIHZlcnNpb24uDQotLSZndDsNCiAgPC9QUkU+PFBSRSB3cmFwPSIiPiZsdDs/eG1sIHZl cnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8mZ3Q7DQombHQ7IS0tIGVkaXRlZCB3aXRoICZs dDtPWHlnZW4vJmd0O1hNTCBlZGl0b3IgNC4xLCBieSBXZWltaW5nIFdhbmcgJmFtcDsgTGlnYW5n IERvbmcgDQogICAgICoqKiBRdWVyeU1zZyBWMS4wLCAyMDA0LTA2LTEzLCBjaGFuZ2VzIHNpbmNl IGxhc3QgdmVyc2lvbjoNCiAgICAgLSBOb25lLCBhcyB0aGUgb3JpZ2luYWwgdmVyc2lvbi4NCiAg ICAgKioqIFF1ZXJ5TXNnVjEuMSwgMjAwNC0wNi0xOA0KICAgICAtIGNoYW5nZSBFbmNvZGluZ1R5 cGUgdG8gVHlwZQ0KICAgICAqKiogUXVlcnlNc2dWMS4yLCAyMDA0LTEwLTIwDQogICAgIC0gZm9y IGlldGYtcHJvdG9jb2wtMDENCi0tJmd0Ow0KDQombHQ7c2VjdGlvbiBhbmNob3I9IlF1ZXJ5TXNn IiB0aXRsZT0iUXVlcnkgYW5kIFJlc3BvbnNlIE1lc3NhZ2VzIiZndDsNCiAgPC9QUkU+PC9CTE9D S1FVT1RFPkJlIG1vcmUgc3BlY2lmaWM6ICJRdWVyeSBhbmQgUXVlcnkgUmVzcG9uc2UgTWVzc2Fn ZXMiPEJSPg0KICA8QkxPQ0tRVU9URSBjaXRlPW1pZDEwODcwMWM0Yjg0YSQ4MDI4YmE2MCQ4NDVj MjFkMkBOZWNvbS5oemljLmVkdS5jbiANCiAgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPiZsdDt0 Jmd0O1RoZSBGb3JDRVMgcXVlcnkgYW5kIHJlc3BvbnNlIG1lc3NhZ2VzIGFyZSB1c2VkIGZvciBv bmUgRm9yQ0VTIA0KICAgIGVsZW1lbnQgKENFIG9yIEZFKSB0byBxdWVyeSBvdGhlciBGb3JDRVMg ZWxlbWVudChzKSBmb3IgdmFyaW91cyANCiAgICBraW5kcyBvZiBpbmZvcm1hdGlvbi4gQ3VycmVu dCB2ZXJzaW9uIG9mIEZvckNFUyBwcm90b2NvbCBsaW1pdHMgDQogICAgdGhlIHVzZSBvZiB0aGUg bWVzc2FnZXMgb25seSBmb3IgQ0UgdG8gcXVlcnkgaW5mb3JtYXRpb24gb2YgRkUuIA0KJmx0Oy90 Jmd0Ow0KJmx0O3NlY3Rpb24gYW5jaG9yPSJRdWVyeSIgdGl0bGU9IlF1ZXJ5IE1lc3NhZ2UiJmd0 Ow0KDQombHQ7dCZndDtBcyB1c3VhbCwgYSBxdWVyeSBtZXNzYWdlIGlzIGNvbXBvc2VkIG9mIGEg Y29tbW9uIGhlYWRlciBhbmQgDQogICAgYSBtZXNzYWdlIGJvZHkgdGhhdCBjb25zaXN0cyBvZiBv bmUgb3IgbW9yZSBUTFYgZGF0YSBmb3JtYXQuIA0KICAgIERldGFpbGVkIGRlc2NyaXB0aW9uIG9m IHRoZSBtZXNzYWdlIGlzIGFzIGJlbG93LiZsdDsvdCZndDsNCiZsdDtsaXN0IHN0eWxlPSJoYW5n aW5nIiBoYW5nSW5kZW50PSI0IiZndDsgJmx0O3ZzcGFjZSAvJmd0Ow0KJmx0O3ZzcGFjZSBibGFu a0xpbmVzPSIxIiAvJmd0Ow0KJmx0O3QgaGFuZ1RleHQ9ICJNZXNzYWdlIHRyYW5zZmVyIGRpcmVj dGlvbjoiJmd0OyAmbHQ7dnNwYWNlIC8mZ3Q7DQpDdXJyZW50IHZlcnNpb24gbGltaXRzIHRoZSBx dWVyeSBtZXNzYWdlIHRyYW5zZmVyIGRpcmVjdGlvbiANCiAgICBvbmx5IGZyb20gQ0UgdG8gRkUu Jmx0Oy90Jmd0Ow0KDQombHQ7dCBoYW5nVGV4dD0gIk1lc3NhZ2UgSGVhZGVyOiImZ3Q7ICZsdDt2 c3BhY2UgLyZndDsNClRoZSBNZXNzYWdlIFR5cGUgaW4gdGhlIGhlYWRlciBpcyBzZXQgdG8gTWVz c2FnZVR5cGU9ICdRdWVyeScuIA0KICAgIFRoZSBBQ0sgZmxhZyBpbiB0aGUgaGVhZGVyIFNIT1VM RCBiZSBzZXQgJ0FDS0FsbCcsIG1lYW5pbmcgYSANCiAgICBmdWxsIHJlc3BvbnNlIGZvciBhIHF1 ZXJ5IG1lc3NhZ2UgaXMgYWx3YXlzIGV4cGVjdGVkLiBJZiB0aGUgDQogICAgQUNLIGZsYWcgaXMg c2V0IG90aGVyIHZhbHVlcywgdGhlIG1lYW5pbmcgb2YgdGhlIA0KICAgIGZsYWcgd2lsbCB0aGVu IGJlIGlnbm9yZWQsIGFuZCBhIGZ1bGwgcmVzcG9uc2Ugd2lsbCBzdGlsbCBiZSANCiAgICByZXR1 cm5lZCBieSBtZXNzYWdlIHJlY2VpdmVyLiZsdDsvdCZndDsNCg0KDQombHQ7dCBoYW5nVGV4dCA9 ICJNZXNzYWdlIGJvZHk6ICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KVGhlIHF1ZXJ5IG1lc3NhZ2Ug Ym9keSBjb25zaXN0cyBvZiAoYXQgbGVhc3QpIG9uZSBvciBtb3JlIHRoYW4gDQogICAgb25lIFRM VnMgdGhhdCBkZXNjcmliZSBlbnRyaWVzIHRvIGJlIHF1ZXJpZWQuIFRoZSBUTFYgaXMgY2FsbGVk IA0KICAgIExGQnNlbGVjdCBUTFYgYW5kIHRoZSBkYXRhIGZvcm1hdCBpcyBhcyBiZWxvdzoNCiZs dDsvdCZndDsNCiZsdDtmaWd1cmUgYW5jaG9yPSJtc2dfUXVlcnkiJmd0Ow0KJmx0O2FydHdvcmsm Z3Q7DQogDQogICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgVHlwZSA9 IExGQnNlbGVjdCAgICAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgTEZCIENsYXNzIElEICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgIExGQiBJbnN0YW5jZSBJRCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdGlvaW4gVExW ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiAgICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIH4NCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgIE9wZXJhdGlvaW4gVExWICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IC4NCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgPC9QUkU+PC9CTE9DS1FVT1RFPlR5cG8gaW4gYWxsIGZpZ3Vy ZXM6IGNvcnJlY3QgIk9wZXJhdGlvaW4gDQogIFRMViI8QlI+PEJSPkdlbmVyYWwgY29tbWVudDog aW4gbWFueSBjYXNlcyB0aGUgc2FtZSB0eXBlIGluIFRMViBpcyB1c2VkIGluIA0KICBkaWZmZXJl bnQgUEwgbWVzc2FnZXMgKFF1ZXJ5IHZzIFJlc3BvbnNlLCBldGMpIGFuZCB0aGVuIHRoZSBWIGlz IGRpZmZlcmVudC4gDQogIFRoaXMgV0lMTCBiZSBhIGJpZyBzb3VyY2Ugb2YgaW1wbGVtZW50YXRp b24gYnVncy4gSSB0aGluayB3ZSBzaG91bGQgZGVmaW5lZCANCiAgb3BlcmF0aW9uIFRMVnMgZGlm ZmVyZW50bHk6IEdFVCBhbmQgR0VULVJFU1AsIFNFVCBhbmQgU0VULVJFU1AsIFJFUE9SVCBhbmQg DQogIFJFUE9SVC1SRVNQLjxCUj5XaGF0IGRvIHlvdSB0aGluayA/PEJSPg0KICA8QkxPQ0tRVU9U RSBjaXRlPW1pZDEwODcwMWM0Yjg0YSQ4MDI4YmE2MCQ4NDVjMjFkMkBOZWNvbS5oemljLmVkdS5j biANCiAgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPiAgICAgDQombHQ7L2FydHdvcmsmZ3Q7DQom bHQ7L2ZpZ3VyZSZndDsNCiZsdDt2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLyZndDsNCiZsdDtsaXN0 IHN0eWxlPSAiaGFuZ2luZyIgaGFuZ0luZGVudD0iMTciICZndDsNCiZsdDt0IGhhbmdUZXh0ID0g IkVkaXRvcmlhbCBOb3RlOiAiJmd0Ow0KJmx0Oy90Jmd0Ow0KJmx0O2xpc3Qgc3R5bGU9Im51bWJl cnMiIGhhbmdJbmRlbnQ9IjMiJmd0Ow0KJmx0O3QmZ3Q7VW5kZXIgZGlzY3Vzc2lvbiBpcyB3aGV0 aGVyIHRoZXJlIGlzIGEgbmVlZCBmb3IgZXhwbGljaXQgbXVsdGlwbGUgTEZCIGluc2F0YW5jZQ0K ICAgIGFkZHJlc3NpbmcgaGVyZS4gT25lIHdheSB0byByZWFsaXplIGl0IGlzIHRvIGRlZmluZSBh IHNwZWNpZmljIEluc3RhbmNlIHNlbGVjdA0KICAgIFRMViB0byBzdWJzdGl0dXRlIGFib3ZlICdM RkIgSW5zdGFuY2UgSUQnIGZpZWxkLiBUaGUgVExWIG1heSBoYXZlIGZvbGxvd2luZyBmb3JtYXQ6 Jmx0Oy90Jmd0Ow0KJmx0O2ZpZ3VyZSZndDsmbHQ7YXJ0d29yayZndDsNCiAgICAgICAgSU5Tc2Vs ZWN0VExWIDo9IFR5cGUgTGVuZ3RoIFZhbHVlDQogICAgICAgIFR5cGUgOj0gSU5Tc2VsZWN0DQog ICAgICAgIFZhbHVlIDo9IEluc3RhbmNlSUQgKFJhbmdlTWFyayB8IEluc3RhbmNlIElEKSsNCg0K Jmx0Oy9hcnR3b3JrJmd0OyZsdDsvZmlndXJlJmd0Ow0KJmx0O3QmZ3Q7QW4gYXBwbGljYWJsZSBS YW5nZU1hcmsgaXMgJzB4ZmZmZmZmZmYnLCB0aGUgdmFsdWUgb2Ygd2hpY2ggaXMgdGhlIHNhbWUg YXMgDQogICAgSW5zdGFuY2UgYnJvYWRjYXN0IElELiBCZWNhdXNlIHRoZXJlIHdpbGwgYmUgbm8g YnJvYWRjYXN0IGFkZHJlc3MgYXBwbGllZA0KICAgIGluIHRoaXMgcGxhY2UsIHRoZXJlIHdpbGwg YmUgbm8gd29ycnkgb2YgYW1iaWd1aXR5IGhlcmUuJmx0Oy90Jmd0Ow0KJmx0Oy9saXN0Jmd0OyAg IA0KJmx0Oy9saXN0Jmd0Ow0KJmx0O3ZzcGFjZSBibGFua0xpbmVzPSIxIiAvJmd0Ow0KJmx0O3Qg aGFuZ1RleHQ9ICJPcGVyYXRpb24gVExWIiZndDsmbHQ7dnNwYWNlIC8mZ3Q7DQpUaGUgT3BlcmF0 aW9uIFRMViBmb3IgdGhlICdRdWVyeScgbWVzc2FnZSBpcyBmb3JtYXR0ZWQgYXM6DQombHQ7L3Qm Z3Q7DQombHQ7ZmlndXJlIGFuY2hvcj0idGx2X1F1ZXJ5IiZndDsNCiZsdDthcnR3b3JrJmd0OyAg ICANCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICBUeXBlID0gT3BlcmF0aW9ucyAoR0VUKSAgICB8 ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgIFBhdGgob3IgQXR0cmlidXRlIElEPykgICAgICAgICAgICAg ICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICBR dWVyeSBEYXRhICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiANCiAgPC9QUkU+PC9CTE9DS1FVT1RFPkFnYWluLCBpbiBhbGwgeW91ciBzZWN0 aW9ucywgY291bGQgeW91IGNoYW5nZSAiVHlwZSA9IA0KICBPcGVyYXRpb25zIChHRVQpIiB0byAi VHlwZSA9IEdFVCIgYW5kIHNvIG9uID88QlI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkMTA4NzAx YzRiODRhJDgwMjhiYTYwJDg0NWMyMWQyQE5lY29tLmh6aWMuZWR1LmNuIA0KICB0eXBlPSJjaXRl Ij48UFJFIHdyYXA9IiI+Jmx0Oy9hcnR3b3JrJmd0OyZsdDsvZmlndXJlJmd0Ow0KJmx0O3QgaGFu Z1RleHQ9ICJQYXRoKG9yIEF0dHJpYnV0ZSBJRD8pOiAiJmd0OyZsdDt2c3BhY2UgLyZndDsNCltV bmRlciBkaXNjdXNzaW9uIGFuZCBUQkRdDQombHQ7L3QmZ3Q7DQoNCiZsdDt2c3BhY2UgYmxhbmtM aW5lcyA9ICIxIiAvJmd0Ow0KJmx0O2xpc3Qgc3R5bGU9ImhhbmdpbmciIGhhbmdJbmRlbnQ9IjE3 IiZndDsNCiZsdDt0IGhhbmdUZXh0ID0gIkVkaXRvcmlhbCBOb3RlOiImZ3Q7IA0KVGhlcmUgaXMg YSBkZWJhdGUgb24gd2hldGhlciB3ZSBzaG91bGQgdXNlIGEgJ1BhdGgnIG9yIHNpbXBseSBhbiAn QXR0cmlidXRlIElEJyANCiAgICBvciBhICdUYWJsZSBJRCcgaGVyZSBhdCB0aGUgcHJvdG9jb2wg bGF5ZXIuIEEgUGF0aCBpcyB1c2VkIGZvciBkYXRhIA0KICAgIGluZGV4aW5nIGZvciBhIHRhYmxl LCB3aGlsZSBhbiAnQXR0cmlidXRlIElEJyBvciBhICdUYWJsZSBJRCcgb25seSBzcGVjaWZ5IA0K ICAgIHdoaWNoIGF0dHJpYnV0ZSBvciB0YWJsZSB0byB1c2UsIGxlYXZpbmcgdGFibGUgaW5kZXgg dG8gYmUgaW5jbHVkZWQgaW4gZm9sbG93ZWQgDQogICAgZGF0YS4NCiZsdDsvdCZndDsNCiZsdDsv bGlzdCZndDsNCiZsdDt2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLyZndDsNCiZsdDt0IGhhbmdUZXh0 PSAiUXVlcnkgRGF0YTogIiZndDsmbHQ7dnNwYWNlIC8mZ3Q7DQogICAgW1VuZGVyIGRpc2N1c3Np b24gYW5kIFRCRF0NCiZsdDsvdCZndDsNCiZsdDsvbGlzdCZndDsNCiZsdDt0Jmd0O1RvIGJldHRl ciB1bmRlcnN0YW5kIHRoZSBhYm92ZSBQRFUgZm9ybWF0LCB3ZSBjYW4gc2hvdyBhIHRyZWUgc3Ry dWN0dXJlIGZvciB0aGUgDQogICAgZm9ybWF0IGFzIGJlbG93Og0KJmx0O2ZpZ3VyZSZndDsNCm1h aW4gaGRyICh0eXBlID0gUXVlcnkpDQogICAgIHwNCiAgICAgfA0KICAgICArLS0tIFQgPSBMRkJz ZWxlY3QNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gTEZCQ0xBU1NJRCA9IHRh cmdldCBMRkIgY2xhc3MNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICB8DQogICAgIHwg ICAgICAgICstLSBMRkJJbnN0YW5jZSA9IHRhcmdldCBMRkIgaW5zdGFuY2UgDQogICAgIHwgICAg ICAgIHwNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gVCA9IG9wZXJhdGlvbiB7 IEdFVCB9DQogICAgIHwgICAgICAgIHwgICB8DQogICAgIHwgICAgICAgIHwgICArLS0gIC8vIG9u ZSBvciBtb3JlIHBhdGggdGFyZ2V0cyANCiAgICAgfCAgICAgICAgfCAgICAgICAgLy8gdW5kZXIg ZGlzY3Vzc2lvbg0KICAgICB8ICAgICAgICArLS0gVCA9IG9wZXJhdGlvbiB7IEdFVCB9DQogICAg IHwgICAgICAgIHwgICB8DQogICAgIHwgICAgICAgIHwgICArLS0gIC8vIG9uZSBvciBtb3JlIHBh dGggdGFyZ2V0cyANCiAgICAgfCAgICAgICAgfCANCg0KJmx0Oy9maWd1cmUmZ3Q7DQombHQ7L3Nl Y3Rpb24mZ3Q7DQoNCiZsdDtzZWN0aW9uIGFuY2hvcj0iUXVlcnlSZXNwb25zZSIgdGl0bGU9IlF1 ZXJ5IFJlc3BvbnNlIE1lc3NhZ2UiJmd0Ow0KJmx0O3QmZ3Q7V2hlbiByZWNlaXZpbmcgYSBxdWVy eSBtZXNzYWdlLCB0aGUgcmVjZWl2ZXIgc2hvdWxkIHByb2Nlc3MgdGhlIA0KICAgIG1lc3NhZ2Ug YW5kIGNvbWUgdXAgd2l0aCBhIHF1ZXJ5IHJlc3VsdC4gVGhlIHJlY2VpdmVyIHNlbmRzIHRoZSAN CiAgICBxdWVyeSByZXN1bHQgYmFjayB0byB0aGUgbWVzc2FnZSBzZW5kZXIgYnkgdXNlIG9mIHRo ZSBRdWVyeSANCiAgICBSZXNwb25zZSBNZXNzYWdlLiBUaGUgcXVlcnkgcmVzdWx0IGNhbiBiZSB0 aGUgaW5mb3JtYXRpb24gDQogICAgYmVpbmcgcXVlcmllZCBpZiB0aGUgcXVlcnkgb3BlcmF0aW9u IGlzIHN1Y2Nlc3NmdWwsIG9yIGNhbiBhbHNvIA0KICAgIGJlIGVycm9yIGNvZGVzIGlmIHRoZSBx dWVyeSBvcGVyYXRpb24gZmFpbHMsIGluZGljYXRpbmcgdGhlIA0KICAgIHJlYXNvbnMgZm9yIHRo ZSBmYWlsdXJlLiZsdDsvdCZndDsNCg0KJmx0O3QmZ3Q7QSBxdWVyeSByZXNwb25zZSBtZXNzYWdl IGlzIGFsc28gY29tcG9zZWQgb2YgYSBjb21tb24gaGVhZGVyIGFuZCANCiAgICBhIG1lc3NhZ2Ug Ym9keSBjb25zaXN0cyBvZiBvbmUgb3IgbW9yZSBUTFZzIGRlc2NyaWJpbmcgdGhlIHF1ZXJ5IA0K ICAgIHJlc3VsdC4gRGV0YWlsZWQgZGVzY3JpcHRpb24gb2YgdGhlIG1lc3NhZ2UgaXMgYXMgYmVs b3cuJmx0Oy90Jmd0Ow0KJmx0O3ZzcGFjZSBibGFua0xpbmVzPSIxIiAvJmd0Ow0KJmx0O2xpc3Qg c3R5bGU9ICJoYW5naW5nIiBoYW5nSW5kZW50PSI0IiZndDsNCiZsdDt0IGhhbmdUZXh0PSAiTWVz c2FnZSB0cmFuc2ZlciBkaXJlY3Rpb246ICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KQ3VycmVudCB2 ZXJzaW9uIGxpbWl0cyB0aGUgcXVlcnkgcmVzcG9uc2UgbWVzc2FnZSB0cmFuc2ZlciBkaXJlY3Rp b24gDQogICAgb25seSBmcm9tIEZFIHRvIENFLg0KJmx0Oy90Jmd0Ow0KICAgIA0KJmx0O3QgaGFu Z1RleHQ9ICJNZXNzYWdlIEhlYWRlcjogICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KVGhlIE1lc3Nh Z2UgVHlwZSBpbiB0aGUgaGVhZGVyIGlzIHNldCB0byBNZXNzYWdlVHlwZT0gJ1F1ZXJ5UmVzcG9u c2UnLiANCiAgICBUaGUgQUNLIGZsYWcgaW4gdGhlIGhlYWRlciBTSE9VTEQgYmUgc2V0ICdOb0FD SycsIG1lYW5pbmcgbm8gZnVydGhlciANCiAgICByZXNwb25zZSBmb3IgYSBxdWVyeSByZXNwb25z ZSBtZXNzYWdlIGlzIGV4cGVjdGVkLiBJZiB0aGUgQUNLIGZsYWcgaXMgDQogICAgc2V0IG90aGVy IHZhbHVlcywgdGhlIG1lYW5pbmcgb2YgdGhlIGZsYWcgd2lsbCB0aGVuIGJlIA0KICAgIGlnbm9y ZWQuIFRoZSBTZXF1ZW5jZSBOdW1iZXIgaW4gdGhlIGhlYWRlciBTSE9VTEQga2VlcCB0aGUgc2Ft ZSBhcyANCiAgICB0aGF0IG9mIHRoZSBxdWVyeSBtZXNzYWdlIHRvIGJlIHJlc3BvbmRlZCwgc28g dGhhdCB0aGUgcXVlcnkgbWVzc2FnZSANCiAgICBzZW5kZXIgY2FuIGtlZXAgdHJhY2sgb2YgdGhl IHJlc3BvbnNlcy4gDQombHQ7L3QmZ3Q7DQogICAgDQombHQ7dCBoYW5nVGV4dD0gIk1lc3NhZ2Ug Ym9keTogIiZndDsmbHQ7dnNwYWNlIC8mZ3Q7DQpUaGUgbWVzc2FnZSBib2R5IGZvciBhIHF1ZXJ5 IHJlc3BvbnNlIG1lc3NhZ2UgY29uc2lzdHMgb2YgKGF0IGxlYXN0KSANCiAgICBvbmUgb3IgbW9y ZSB0aGFuIG9uZSBUTFZzIHRoYXQgZGVzY3JpYmUgcXVlcnkgcmVzdWx0cyBmb3IgaW5kaXZpZHVh bCANCiAgICBxdWVyaWVkIGVudHJpZXMuIFRoZSBUTFYgaXMgYWxzbyBjYWxsZWQgTEZCc2VsZWN0 IFRMViwgYW5kIGhhcyBleGFjdGx5IA0KICAgIHRoZSBzYW1lIGRhdGEgZm9ybWF0IGFzIHF1ZXJ5 IG1lc3NhZ2UsIGV4Y2VwdCB0aGUgT3BlcmF0aW9uIFRMViBpbnNpZGUNCiAgICB0aGUgVExWIGNv bXByaXNlcyB0aGUgJ1F1ZXJ5IFJlc3BvbnNlIERhdGEnLCBpbnN0ZWFkIG9mIHRoZSAnUXVlcnkg RGF0YScsDQogICAgYXMgYmVsb3c6DQombHQ7L3QmZ3Q7DQoNCiZsdDtmaWd1cmUgYW5jaG9yPSJt c2dfUXVlcnlfUmVzcG9uc2UiJmd0Ow0KJmx0O2FydHdvcmsmZ3Q7DQogICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICAgIHwgICAgVHlwZSA9IE9wZXJhdGlvbnMgKEdFVCkgICAgfCAgICAgICAgICAgICAgIExlbmd0 aCAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICBQYXRoKG9yIEF0dHJpYnV0ZSBJRD8pICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgUXVlcnkgUmVzcG9uc2UgRGF0YSAgICAg ICAgICAgICAgICAgICAgfA0KICAgICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KJmx0Oy9hcnR3 b3JrJmd0Ow0KJmx0Oy9maWd1cmUmZ3Q7DQogIDwvUFJFPjwvQkxPQ0tRVU9URT5Zb3Ugc2hvdWxk IHNwZWNpZnkgaGVyZSB0aGF0IHRoZSBvcmRlciBvZiB0aGUgVExWIGluIHRoZSANCiAgUXVlcnkt UmVwb25zZSBtYXRjaGVzIHRoZSBUTFZzIGluIHRoZSBRdWVyeS4gU28gdGhlcmUgaXMgYWx3YXlz IHRoZSBzYW1lIA0KICBudW1iZXIgb2YgVExWcyBpbiB0aGUgcmVzcG9uc2UgYXMgaW4gdGhlIHF1 ZXJ5LjxCUj48QlI+U2lkZSBub3RlOiB3ZSBoYXZlIG5vdCANCiAgeWV0IHJlc29sdmVkIHRoZSB1 c2Ugb2YgYSB0cmFuc2FjdGlvbiBvciBzZXF1ZW5jZSBudW1iZXIgdGhhdCB3aWxsIGJlIHVzZWQg Zm9yIA0KICBlYWNoIFBMIG1lc3NhZ2UuPEJSPjxCUj4NCiAgPEJMT0NLUVVPVEUgY2l0ZT1taWQx MDg3MDFjNGI4NGEkODAyOGJhNjAkODQ1YzIxZDJATmVjb20uaHppYy5lZHUuY24gDQogIHR5cGU9 ImNpdGUiPjxQUkUgd3JhcD0iIj4gDQombHQ7dCBoYW5nVGV4dD0gIlF1ZXJ5IFJlc3BvbnNlIERh dGE6ICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KW1VuZGVyIGRpc2N1c3Npb24gYW5kIFRCRF0NCiZs dDsvdCZndDsNCiZsdDsvbGlzdCZndDsNCiAgICANCiZsdDsvc2VjdGlvbiZndDsNCiZsdDsvc2Vj dGlvbiZndDsNCg0KJmx0OyEtLSAkTG9nOiBRdWVyeU1zZy54bWwsdiAkDQombHQ7IS0tIFJld3Jp dHRlbiBieSBXZWltaW5nIFdhbmcgMjAwNC8xMC8yMg0KJmx0OyEtLSBJbmNvcnBhcmF0ZSBMRkJz ZWxlY3QgYW5kIE9wZXJhdGlvbiBUTFYgDQombHQ7IS0tDQombHQ7IS0tIFJldmlzaW9uIDEuMTAg IDIwMDQvMTAvMjAgMTQ6NDk6MzYgIGF2cmkNCiZsdDshLS0gQ2hhbmdlcyBmb3IgZHJhZnQtaWV0 Zi1mb3JjZXMtcHJvdG9jb2wtMDANCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS45ICAyMDA0 LzA3LzE5IDA5OjM3OjIyICBhdnJpDQombHQ7IS0tIFZlcnNpb24gMiBjaGVja2luDQombHQ7IS0t DQombHQ7IS0tIFJldmlzaW9uIDEuOCAgMjAwNC8wNi8yMyAwNTowNTo0NyAgYXZyaQ0KJmx0OyEt LSBmaW5hbCBlZGl0cyBmb3IgMDANCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS43ICAyMDA0 LzA2LzIyIDA2OjU0OjE3ICBhdnJpDQombHQ7IS0tIFJlbW92ZQ0KJmx0OyEtLQ0KJmx0OyEtLSBS ZXZpc2lvbiAxLjYgIDIwMDQvMDYvMjIgMDY6NTI6MzMgIGF2cmkNCiZsdDshLS0gSW5jb3Jwb3Jh dGUgV1cgY2hhbmdlcw0KJmx0OyEtLSBJbmNsdWRlIHRlYW0gZWRpdHMgb24gMDAtNw0KJmx0OyEt LQ0KJmx0OyEtLSBSZXZpc2lvbiAxLjIgIDIwMDQtMDYtMjEgMjE6NDA6MjUrMDggIGFkbWluaXN0 cmF0b3INCiZsdDshLS0gSW5jb3JwYXJhdGUgc29tZSBjb21tZW50cyBmcm9tIEphbWFsIChKdW5l IDIxLCAyMDA0IDEwOjUwIEFNKS4gLVdlaW1pbmcNCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24g MS4xICAyMDA0LTA2LTIxIDIwOjM2OjQwKzA4ICBhZG1pbmlzdHJhdG9yDQombHQ7IS0tIHJldmlz aW9uIGhhbmRlZCBmcm9tIEF2cmkNCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS41ICAyMDA0 LzA2LzE5IDEzOjEyOjMzICBhdnJpDQombHQ7IS0tIGZvcm1hdHRpbmcNCiZsdDshLS0NCiZsdDsh LS0gUmV2aXNpb24gMS40ICAyMDA0LzA2LzE5IDEzOjAzOjAzICBhdnJpDQombHQ7IS0tIGZpeCBj cm9zcyByZWZlcmVuY2UNCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS4zICAyMDA0LzA2LzE5 IDEyOjIxOjExICBhdnJpDQombHQ7IS0tIC0gY2hhbmdlIEVuY29kaW5nVHlwZSB0byBUeXBlIChm cm9tIFdXKQ0KJmx0OyEtLSAtIGZpeCBmb3JtYXRpbmcNCiZsdDshLS0NCiZsdDshLS0gUmV2aXNp b24gMS4yICAyMDA0LzA2LzE3IDAzOjQzOjQ3ICBhdnJpDQombHQ7IS0tIFJlcGxhY2Ugd2l0aCBu ZXcgV1cgZmlsZXMNCiZsdDshLS0NCiAgICBlZGl0ZWQgd2l0aCAmbHQ7T1h5Z2VuLyZndDtYTUwg ZWRpdG9yIDQuMSwgYnkgV2VpbWluZyBXYW5nICZhbXA7TGlnYW5nIERvbmcgDQogICAgICoqKiBR dWVyeU1zZyBWMS4wLCAyMDA0LTA2LTEzLCBjaGFuZ2VzIHNpbmNlIGxhc3QgdmVyc2lvbjoNCiAg ICAgLSBOb25lLCBhcyB0aGUgb3JpZ2luYWwgdmVyc2lvbi4NCi0tJmd0Ow0KICA8L1BSRT48UFJF IHdyYXA9IiI+Jmx0Oz94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPyZndDsNCiZs dDshLS0gZWRpdGVkIHdpdGggJmx0O09YeWdlbi8mZ3Q7WE1MIGVkaXRvciA0LjEsIGJ5IFdlaW1p bmcgV2FuZyAmYW1wO0xpZ2FuZyBEb25nIA0KICAgICAqKiogRXZlbnRNc2cgVjEuMCwgMjAwNC0w Ni0xMywgY2hhbmdlcyBzaW5jZSBsYXN0IHZlcnNpb246DQogICAgIC0gTm9uZSwgYXMgdGhlIG9y aWdpbmFsIHZlcnNpb24uDQogICAgICoqKiBFdmVudE1zZ1YxLjEsIDIwMDQtMDYtMTg6DQogICAg IC0gY2hhbmdlIEVuY29kaW5nVHlwZSB0byBUeXBlLg0KLS0mZ3Q7DQoNCiZsdDtzZWN0aW9uIGFu Y2hvcj0iRXZlbnRNc2ciIHRpdGxlPSJFdmVudCBOb3RpZmljYXRpb24gYW5kIFJlc3BvbnNlIE1l c3NhZ2VzIiZndDsNCg0KJmx0O3QmZ3Q7VGhlIEV2ZW50IE5vdGlmaWNhdGlvbiBNZXNzYWdlIGlz IHVzZWQgZm9yIG9uZSBGb3JDRVMgZWxlbWVudCANCiAgICB0byBhc3luY2hyb25vdXNseSBub3Rp Znkgb25lIG9yIG1vcmUgb3RoZXIgRm9yQ0VTIGVsZW1lbnRzIA0KICAgIGluIHRoZSBzYW1lIEZv ckNFUyBORSBvbiBqdXN0IGhhcHBlbmVkIGV2ZW50cyBpbiBpdC4gVGhlIA0KICAgIEV2ZW50IE5v dGlmaWNhdGlvbiBSZXNwb25zZSBNZXNzYWdlIGlzIHVzZWQgZm9yIHRoZSByZWNlaXZlciANCiAg ICBvZiB0aGUgRXZlbnQgTm90aWZpY2F0aW9uIE1lc3NhZ2UgdG8gYWNrbm93bGVkZ2UgdGhlIHJl Y2VwdGlvbiANCiAgICBvZiB0aGUgZXZlbnQgbm90aWZpY2F0aW9uLiZsdDsvdCZndDsNCg0KJmx0 O3QmZ3Q7RXZlbnRzIGluIGN1cnJlbnQgRm9yQ0VTIHByb3RvY29sIGNhbiBiZSBjYXRlZ29yaXpl ZCBpbnRvIGZvbGxvd2luZyB0eXBlczombHQ7L3QmZ3Q7DQombHQ7dCZndDsmbHQ7bGlzdCBzdHls ZT0ic3ltYm9scyImZ3Q7DQombHQ7dCZndDtFdmVudHMgaGFwcGVuZWQgaW4gQ0UmbHQ7L3QmZ3Q7 DQombHQ7dCZndDtFdmVudHMgaGFwcGVuZWQgaW4gRkUmbHQ7L3QmZ3Q7DQogIDwvUFJFPjwvQkxP Q0tRVU9URT5XaHkgZG9lcyB0aGlzIG1hdHRlciBmb3IgdGhlIHByb3RvY29sID88QlI+DQogIDxC TE9DS1FVT1RFIGNpdGU9bWlkMTA4NzAxYzRiODRhJDgwMjhiYTYwJDg0NWMyMWQyQE5lY29tLmh6 aWMuZWR1LmNuIA0KICB0eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+Jmx0Oy9saXN0Jmd0OyZsdDsv dCZndDsNCg0KJmx0O3QmZ3Q7RXZlbnRzIGNhbiBhbHNvIGJlIGNhdGVnb3JpemVkIGludG8gdHdv IGNsYXNzZXMgYWNjb3JkaW5nIHRvIA0KICAgIHdoZXRoZXIgdGhleSBuZWVkIHN1YnNjcmlwdGlv biBvciBub3QuIEFuIGV2ZW50IGluIG9uZSBGb3JDRVMgDQogICAgZWxlbWVudCB0aGF0IG5lZWRz IHRvIGJlIHN1YnNjcmliZWQgd2lsbCBzZW5kIG5vdGlmaWNhdGlvbnMgdG8gDQogICAgb3RoZXIg Rm9yQ0VTIGVsZW1lbnRzIG9ubHkgd2hlbiB0aGUgb3RoZXIgZWxlbWVudHMgaGF2ZSBzdWJzY3Jp YmVkIA0KICAgIHRvIHRoZSBlbGVtZW50IGZvciB0aGUgZXZlbnQgbm90aWZpY2F0aW9uLiBIb3cg dG8gDQogICAgc3Vic2NyaWJlL3Vuc3Vic2NyaWJlIGZvciBhbiBldmVudCBpcyBkZXNjcmliZWQg aW4gdGhlIENvbmZpZ3VyZSANCiAgICBNZXNzYWdlIGluIFNlY3Rpb24gNi4zLiBBbiBldmVudCB0 aGF0IG5lZWRzIG5vdCB0byBiZSBzdWJzY3JpYmVkIA0KICAgIHdpbGwgYWx3YXlzIHNlbmQgbm90 aWZpY2F0aW9ucyB0byBvdGhlciBGb3JDRVMgZWxlbWVudHMgd2hlbiB0aGUgDQogICAgZXZlbnQg aGFwcGVucy4gQW4gZXZlbnQgZGVmaW5pdGlvbiBtYWRlIGJ5IEZvckNFUyBwcm90b2NvbCwgRm9y Q0VTIA0KICAgIEZFIG1vZGVsLCBvciBieSB2ZW5kb3JzIHdpbGwgc3RhdGUgaWYgdGhlIGV2ZW50 IG5lZWRzIHN1YnNjcmlwdGlvbiBvciBub3QuJmx0Oy90Jmd0Ow0KJmx0O3ZzcGFjZSBibGFua0xp bmVzPSIxIiAvJmd0Ow0KJmx0O2xpc3Qgc3R5bGU9ImhhbmdpbmciIGhhbmdJbmRlbnQ9IjE3IiAm Z3Q7DQombHQ7dCBoYW5nVGV4dD0iRWRpdG9yaWFsIE5vdGU6ICIgJmd0Ow0KVGhlcmUgaXMgYW4g YXJndW1lbnQgdGhhdCBpdCBpcyBwcmVmZXJhYmxlIHRvIGhhdmUgDQphbGwgZXZlbnRzIHN1YnNj cmliYWJsZS4NCiZsdDsvdCZndDsNCiZsdDsvbGlzdCZndDsNCg0KDQombHQ7c2VjdGlvbiB0aXRs ZT0iRXZlbnQgTm90aWZpY2F0aW9uIE1lc3NhZ2UiJmd0Ow0KDQombHQ7dCZndDtBcyB1c3VhbCwg YW4gRXZlbnQgTm90aWZpY2F0aW9uIE1lc3NhZ2UgaXMgY29tcG9zZWQgb2YgYSBjb21tb24gDQog ICAgaGVhZGVyIGFuZCBhIG1lc3NhZ2UgYm9keSB0aGF0IGNvbnNpc3RzIG9mIG9uZSBvciBtb3Jl IFRMViBkYXRhIA0KICAgIGZvcm1hdC4gRGV0YWlsZWQgZGVzY3JpcHRpb24gb2YgdGhlIG1lc3Nh Z2UgaXMgYXMgYmVsb3cuJmx0Oy90Jmd0Ow0KJmx0O2xpc3Qgc3R5bGU9ImhhbmdpbmciIGhhbmdJ bmRlbnQ9IjEiJmd0Ow0KJmx0O3QgaGFuZ1RleHQ9ICJNZXNzYWdlIFRyYW5zZmVyIERpcmVjdGlv bjogICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KRkUgdG8gQ0UsIG9yIENFIHRvIEZFDQombHQ7L3Qm Z3Q7DQoNCg0KJmx0O3QgaGFuZ1RleHQ9ICJNZXNzYWdlIEhlYWRlcjogICImZ3Q7Jmx0O3ZzcGFj ZSAvJmd0Ow0KVGhlIE1lc3NhZ2UgVHlwZSBpbiB0aGUgbWVzc2FnZSBoZWFkZXIgaXMgc2V0IHRv ICZsdDt2c3BhY2UgLyZndDsNCiAgICBNZXNzYWdlVHlwZSA9ICdFdmVudE5vdGlmaWNhdGlvbicu IFRoZSBBQ0sgZmxhZyBpbiB0aGUgaGVhZGVyIA0KICAgIGNhbiBiZSBzZXQgYXM6IEFDSyBmbGFn ID0nTm9BQ0snfCdTdWNjZXNzQWNrJ3wnVW5zdWNjZXNzQUNLJ3wnQUNLQWxsJy4gDQogICAgTm90 ZSB0aGF0IHRoZSAnU3VjY2VzcycgaGVyZSBvbmx5IG1lYW5zIHRoZSByZWNlaXZlciBvZiB0aGUg bWVzc2FnZSANCiAgICBoYXMgc3VjY2Vzc2Z1bGx5IHJlY2VpdmVkIHRoZSBtZXNzYWdlLg0KJmx0 Oy90Jmd0Ow0KDQoNCiZsdDt0IGhhbmdUZXh0PSAiTWVzc2FnZSBCb2R5OiAiJmd0OyZsdDt2c3Bh Y2UgLyZndDsNClRoZSBtZXNzYWdlIGJvZHkgZm9yIGFuIGV2ZW50IG5vdGlmaWNhdGlvbiBtZXNz YWdlIGNvbnNpc3RzIA0KICAgIG9mIChhdCBsZWFzdCkgb25lIG9yIG1vcmUgdGhhbiBvbmUgVExW cyB0aGF0IGRlc2NyaWJlIHRoZSANCiAgICBub3RpZmllZCBldmVudHMuIFRoZSBUTFYgaXMgZGVm aW5lZCBhcyBmb2xsb3dzOg0KJmx0O3ZzcGFjZSBibGFua0xpbmVzPSIxIiAvJmd0Ow0KJmx0Oy90 Jmd0Ow0KDQombHQ7ZmlndXJlIGFuY2hvcj0idGx2X0V2ZW50X05vdGlmaWNhdGlvbiImZ3Q7DQom bHQ7YXJ0d29yayZndDsNCiAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAg ICBUeXBlID0gTEZCc2VsZWN0ICAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAg fA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBMRkIgQ2xh c3MgSUQgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgTEZCIEluc3RhbmNlIElEICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgT3BlcmF0 aW9pbiBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAuICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgT3BlcmF0aW9pbiBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg ICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KIA0KJmx0Oy9hcnR3b3JrJmd0OyZsdDsvZmlndXJl Jmd0Ow0KDQombHQ7dCBoYW5nVGV4dD0gIk9wZXJhdGlvbiBUTFY6ICImZ3Q7Jmx0O3ZzcGFjZSAv Jmd0Ow0KVGhpcyBpcyBhIFRMViB0aGF0IGRlc2NyaWJlcyB0aGUgZXZlbnQgdG8gYmUgbm90aWZp ZWQsIGFzIGZvbGxvd3M6DQombHQ7L3QmZ3Q7DQoNCiZsdDtmaWd1cmUgYW5jaG9yPSJ0bHZfRXZl bnQiJmd0OyZsdDthcnR3b3JrJmd0Ow0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgIFR5cGUgPSBP cGVyYXRpb25zIChSRVBPUlQpIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgUGF0aChvciBFdmVudCBJ RD8pICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEV2ZW50IERhdGEgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KJmx0Oy9hcnR3b3JrJmd0OyZsdDsvZmlndXJl Jmd0Ow0KJmx0O3QgaGFuZ1RleHQ9ICJQYXRoKG9yIEV2ZW50IElEKTogIiZndDsmbHQ7dnNwYWNl IC8mZ3Q7DQpbVW5kZXIgZGlzY3Vzc2lvbiBhbmQgVEJEXQ0KJmx0Oy90Jmd0Ow0KDQombHQ7dCBo YW5nVGV4dD0gIkV2ZW50IERhdGE6ICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KICAgIFtVbmRlciBk aXNjdXNzaW9uIGFuZCBUQkRdDQombHQ7L3QmZ3Q7DQombHQ7L2xpc3QmZ3Q7DQombHQ7dCZndDtU byBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUgYWJvdmUgUERVIGZvcm1hdCwgd2UgY2FuIHNob3cgYSB0 cmVlIHN0cnVjdHVyZSBmb3IgdGhlIA0KICAgIGZvcm1hdCBhcyBiZWxvdzoNCiZsdDtmaWd1cmUm Z3Q7DQptYWluIGhkciAodHlwZSA9IEV2ZW50IE5vdGlmaWNhdGlvbikNCiAgICAgfA0KICAgICB8 DQogICAgICstLS0gVCA9IExGQnNlbGVjdA0KICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAg ICstLSBMRkJDTEFTU0lEID0gdGFyZ2V0IExGQiBjbGFzcw0KICAgICB8ICAgICAgICB8DQogICAg IHwgICAgICAgIHwNCiAgICAgfCAgICAgICAgKy0tIExGQkluc3RhbmNlID0gdGFyZ2V0IExGQiBp bnN0YW5jZSANCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAg ICstLSBUID0gb3BlcmF0aW9uIHsgUkVQT1JUIH0NCiAgICAgfCAgICAgICAgfCAgIHwNCiAgICAg fCAgICAgICAgfCAgICstLSAgLy8gb25lIG9yIG1vcmUgcGF0aCB0YXJnZXRzIA0KICAgICB8ICAg ICAgICB8ICAgICAgICAvLyB1bmRlciBkaXNjdXNzaW9uDQogICAgIHwgICAgICAgICstLSBUID0g b3BlcmF0aW9uIHsgUkVQT1JUIH0NCiAgICAgfCAgICAgICAgfCAgIHwNCiAgICAgfCAgICAgICAg fCAgICstLSAgLy8gb25lIG9yIG1vcmUgcGF0aCB0YXJnZXRzIA0KICAgICB8ICAgICAgICB8IA0K DQombHQ7L2ZpZ3VyZSZndDsNCiZsdDsvbGlzdCZndDsNCiZsdDsvc2VjdGlvbiZndDsNCg0KJmx0 O3NlY3Rpb24gdGl0bGU9IkV2ZW50IE5vdGlmaWNhdGlvbiBSZXNwb25zZSBNZXNzYWdlIiZndDsN Cg0KJmx0O3QmZ3Q7QWZ0ZXIgc2VuZGluZyBvdXQgYW4gRXZlbnQgTm90aWZpY2F0aW9uIE1lc3Nh Z2UsIHRoZSBzZW5kZXIgbWF5IA0KICAgIGJlIGludGVyZXN0ZWQgaW4gZW5zdXJpbmcgdGhhdCB0 aGUgbWVzc2FnZSBoYXMgYmVlbiByZWNlaXZlZCANCiAgICBieSByZWNlaXZlcnMsIGVzcGVjaWFs bHkgd2hlbiB0aGUgc2VuZGVyIHRoaW5rcyB0aGUgZXZlbnQgDQogICAgbm90aWZpY2F0aW9uIGlz IHZpdGFsIGZvciBzeXN0ZW0gbWFuYWdlbWVudC4gQW4gRXZlbnQgDQogICAgTm90aWZpY2F0aW9u IFJlc3BvbnNlIE1lc3NhZ2UgaXMgdXNlZCBmb3IgdGhpcyBwdXJwb3NlLiBUaGUgDQogICAgQUNL IGZsYWcgaW4gdGhlIEV2ZW50IE5vdGlmaWNhdGlvbiBNZXNzYWdlIGhlYWRlciBhcmUgdXNlZCB0 byANCiAgICBzaWduYWwgaWYgc3VjaCBhY2tub3dsZWRnZSBpcyByZXF1ZXN0ZWQgb3Igbm90IGJ5 IHRoZSBzZW5kZXIuJmx0Oy90Jmd0OyANCg0KJmx0O3QmZ3Q7RGV0YWlsZWQgZGVzY3JpcHRpb24g b2YgdGhlIG1lc3NhZ2UgaXMgYXMgYmVsb3c6Jmx0Oy90Jmd0Ow0KJmx0O2xpc3Qgc3R5bGU9Imhh bmdpbmciIGhhbmdJbmRlbnQ9IjEiJmd0Ow0KJmx0O3QgaGFuZ1RleHQ9ICJNZXNzYWdlIFRyYW5z ZmVyIERpcmVjdGlvbjogICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KRnJvbSBGRSB0byBDRSBvciBm cm9tIENFIHRvIEZFLCBqdXN0IGludmVyc2UgdG8gdGhlIA0KICAgIGRpcmVjdGlvbiBvZiB0aGUg RXZlbnQgTm90aWZpY2F0aW9uIE1lc3NhZ2UgdGhhdCBpdCByZXNwb25zZXMuDQombHQ7L3QmZ3Q7 DQoNCg0KJmx0O3QgaGFuZ1RleHQ9ICJNZXNzYWdlIEhlYWRlcjogICImZ3Q7Jmx0O3ZzcGFjZSAv Jmd0Ow0KVGhlIE1lc3NhZ2UgVHlwZSBpbiB0aGUgaGVhZGVyIGlzIHNldCANCiAgICBNZXNzYWdl VHlwZT0gJ0V2ZW50Tm90aWZpY2F0aW9uUmVzcG9uc2UnLiBUaGUgQUNLIGZsYWcgaW4gdGhlIA0K ICAgIGhlYWRlciBTSE9VTEQgYmUgc2V0ICdOb0FDSycsIG1lYW5pbmcgbm8gZnVydGhlciByZXNw b25zZSBmb3IgDQogICAgdGhlIG1lc3NhZ2UgaXMgZXhwZWN0ZWQuIElmIHRoZSBBQ0sgZmxhZyBp cyBzZXQgb3RoZXIgdmFsdWVzLCANCiAgICB0aGUgbWVhbmluZyBvZiB0aGUgZmxhZyB3aWxsIHRo ZW4gYmUgaWdub3JlZC4gDQogICAgVGhlIFNlcXVlbmNlIE51bWJlciBpbiB0aGUgaGVhZGVyIFNI T1VMRCBrZWVwIHRoZSBzYW1lIGFzIHRoYXQgDQogICAgb2YgdGhlIG1lc3NhZ2UgdG8gYmUgcmVz cG9uZGVkLCBzbyB0aGF0IHRoZSBldmVudCBub3RpZmljYXRpbiANCiAgICBtZXNzYWdlIHNlbmRl ciBjYW4ga2VlcCB0cmFjayBvZiB0aGUgcmVzcG9uc2VzLg0KJmx0Oy90Jmd0Ow0KDQombHQ7dCBo YW5nVGV4dD0gIk1lc3NhZ2UgQm9keTogIiZndDsmbHQ7dnNwYWNlIC8mZ3Q7DQpUaGUgbWVzc2Fn ZSBib2R5IGZvciBhbiBldmVudCBub3RpZmljYXRpb24gbWVzc2FnZSBjb25zaXN0cyANCiAgPC9Q UkU+PC9CTE9DS1FVT1RFPmNvcnJlY3QgYWJvdmU6IGV2ZW50IG5vdGlmaWNhdGlvbiAicmVzcG9u c2UiIG1lc3NhZ2U8QlI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkMTA4NzAxYzRiODRhJDgwMjhi YTYwJDg0NWMyMWQyQE5lY29tLmh6aWMuZWR1LmNuIA0KICB0eXBlPSJjaXRlIj48UFJFIHdyYXA9 IiI+ICAgIG9mIChhdCBsZWFzdCkgb25lIG9yIG1vcmUgdGhhbiBvbmUgVExWcyB0aGF0IGRlc2Ny aWJlIHRoZSANCiAgICBub3RpZmllZCBldmVudHMuIFRoZSBUTFYgaXMgYWxzbyBjYWxsZWQgTEZC c2VsZWN0IFRMViwgYW5kIGhhcyBleGFjdGx5IA0KICAgIHRoZSBzYW1lIGRhdGEgZm9ybWF0IGFz IEV2ZW50IE5vdGlmaWNhdGlvbiBNZXNzYWdlLCBleGNlcHQgdGhlIE9wZXJhdGlvbiANCiAgICBU TFYgaW5zaWRlIHRoZSBUTFYgY29tcHJpc2VzIHRoZSBldmVudCByZXNwb25zZSBkYXRhLCBpbnN0 ZWFkIG9mIHRoZSANCiAgICAnRXZlbnQgRGF0YScsIGFzIGJlbG93Og0KICA8L1BSRT48L0JMT0NL UVVPVEU+QWdhaW4sIHlvdSBzaG91bGQgbWVudGlvbiB0aGF0IHRoZSBlYWNoICJPcGVyYXRpb24g VExWIiANCiAgaW4gdGhlIHJlc3BvbnNlIGNvcnJlc3BvbmRzIG9uZS10by1vbmUgdG8gYSBUTFYg aW4gdGhlIG5vdGlmaWNhdGlvbi48QlI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkMTA4NzAxYzRi ODRhJDgwMjhiYTYwJDg0NWMyMWQyQE5lY29tLmh6aWMuZWR1LmNuIA0KICB0eXBlPSJjaXRlIj48 UFJFIHdyYXA9IiI+Jmx0O3ZzcGFjZSBibGFua0xpbmVzPSIxIiAvJmd0Ow0KDQombHQ7ZmlndXJl IGFuY2hvcj0idGx2X1JlcHNvbnNlX1Jlc3VsdCImZ3Q7DQombHQ7cHJlYW1ibGUmZ3Q7DQpUaGlz IGNvbnRhaW5zIGEgVExWIHRoYXQgZGVzY3JpYmUgdGhlIHJlc3BvbnNlIHJlc3VsdCANCiAgICBh cyBiZWxvdzoNCiZsdDsvcHJlYW1ibGUmZ3Q7DQombHQ7YXJ0d29yayZndDsNCiAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgICAgfCAgICBUeXBlID0gT3BlcmF0aW9ucyAoUkVQT1JUKSB8ICAgICAgICAgICAgICAg TGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgIFBhdGgob3IgRXZlbnQgSUQ/KSAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgICAgfCAgICBSZXN1bHQgICAgIHwgICBSZWFzb24gICAgICB8ICAgICAgICAgQ29k ZSAgICAgICAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KJmx0Oy9hcnR3b3JrJmd0OyZs dDsvZmlndXJlJmd0Ow0KJmx0O3QgaGFuZ1RleHQ9ICJQYXRoKG9yIEV2ZW50IElEPyk6ICImZ3Q7 Jmx0O3ZzcGFjZSAvJmd0Ow0KW1VuZGVyIGRpc2N1c3Npb24gYW5kIFRCRF0NCiZsdDsvdCZndDsN CiZsdDt0IGhhbmdUZXh0PSAiUmVzdWx0OiAiJmd0OyZsdDt2c3BhY2UgLyZndDsNClRoaXMgZGVz Y3JpYmVzIHRoZSByZWNlcHRpb24gcmVzdWx0IG9mIHRoZSBldmVudCBub3RpZmljYXRpb24gDQog ICAgbWVzc2FnZSBhcyBiZWxvdzoNCiZsdDsvdCZndDsNCiZsdDtmaWd1cmUmZ3Q7Jmx0O2FydHdv cmsmZ3Q7DQoJUmVzdWx0IFZhbHVlICAgICAgICAgICAgIE1lYW5pbmcNCgknU3VjY2VzcycgICAg ICAgVGhlIGV2ZW50IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSByZWNlaXZlZC4NCgknVW5zdWNjZXNz JyAgICAgVGhlIGV2ZW50IGhhcyBub3QgYmVlbiBzdWNjZXNzZnVsbHkgcmVjZWl2ZWQuDQombHQ7 L2FydHdvcmsmZ3Q7Jmx0Oy9maWd1cmUmZ3Q7DQoNCiZsdDt0IGhhbmdUZXh0PSAiUmVhc29uLCBD b2RlOiAiJmd0OyZsdDt2c3BhY2UgLyZndDsNClRoaXMgZGVzY3JpYmVzIHRoZSByZWFzb24gYW5k IHBvc3NpYmxlIGVycm9yIGNvZGUgd2hlbiANCiAgICB0aGUgbWVzc2FnZSBpcyBub3Qgc3VjY2Vz c2Z1bGx5IHJlY2VpdmVkLiBOb3RlIHRoYXQgb25seSB0aGUgDQogICAgZmFpbHVyZSBhdCB0aGUg cHJvdG9jb2wgbGF5ZXIgcmF0aGVyIHRoYW4gdGhlIHRyYW5zcG9ydCBsYXllciANCiAgICBjYW4g YmUgYWxsb2NhdGVkIGhlcmUsPC9QUkU+PC9CTE9DS1FVT1RFPnR5cG86IG5vdCAiYWxsb2NhdGVk IiBidXQgDQogICJoYW5kbGVkIi48QlI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkMTA4NzAxYzRi ODRhJDgwMjhiYTYwJDg0NWMyMWQyQE5lY29tLmh6aWMuZWR1LmNuIA0KICB0eXBlPSJjaXRlIj48 UFJFIHdyYXA9IiI+IHRoYXQgaXMsIGlmIGV2ZW4gdGhlIGhlYWRlciBwYXJ0IG9mIHRoZSANCiAg ICBtZXNzYWdlIHRvIGJlIHJlc3BvbmRlZCBjYW4gbm90IGJlIGNvcnJlY3RseSByZWNlaXZlZCwg dGhlIA0KICAgIHJlc3BvbnNlIHRvIHRoZSBtZXNzYWdlIHdpbGwgbm90IGJlIGFibGUgdG8gYmUg Z2VuZXJhdGVkIGJ5IA0KICAgIHRoZSByZWNlaXZlci4NCiZsdDsvdCZndDsNCiZsdDt2c3BhY2Ug YmxhbmtMaW5lcz0iMSIgLyZndDsNCiZsdDtsaXN0IHN0eWxlPSJoYW5naW5nIiBoYW5nSW5kZW50 PSIxNyImZ3Q7DQombHQ7dCBoYW5nVGV4dD0iRWRpdG9yaWFsIE5vdGU6ICImZ3Q7IA0KVGhlcmUg aXMgYSBkZWJhdGUgb24gd2hldGhlciB0aGUgRXZlbnQgTm90aWZpY2F0aW9uIA0KICAgIFJlc3Bv bnNlIE1lc3NhZ2UgaXMgbmVjZXNzYXJ5IG9yIG5vdC4gVGhlIHBybyBmb3IgaXQgaXMgc29tZSBl dmVudCANCiAgICBub3RpZmljYXRpb24gc2VuZGVycyBtYXkgYmUgaW50ZXJlc3RlZCBpbiBrbm93 aW5nIGlmIHJlY2VpdmVycyANCiAgICBoYXZlIGhhZCBzdWNjZXNzL3Vuc3VjY2VzcyByZWNlcHRp b25zIG9mIHRoZSBldmVudHMgb3Igbm90LiBBbiANCiAgICBhbHRlcm5hdGl2ZSB0byBnZW5lcmF0 ZSBzdWNoIHJlc3BvbnNlIGlzIGZvciB0aGUgcHJvdG9jb2wgdG8gDQogICAgZGVmaW5lIGEgdW5p dmVyc2FsIEFDSyBtZXNzYWdlIHNvIHRoYXQgaXQgY2FuIGFjdCBhcyByZXNwb25zZXMgDQogICAg Zm9yIGFueSB0eXBlcyBvZiBtZXNzYWdlcyBhcyB3ZWxsIGFzIHRoZSBldmVudCBub3RpZmljYXRp b24gDQogICAgbWVzc2FnZXMsIHdoZW4gdGhlIG1lc3NhZ2Ugc2VuZGVycyBhcmUgaW50ZXJlc3Rl ZCBpbiBrbm93aW5nIA0KICAgIHdoZXRoZXIgdGhlIG1lc3NhZ2VzIGhhdmUgYmVlbiBzdWNjZXNz ZnVsbHkgcmVjZWl2ZWQgb3Igbm90IA0KICAgIChkaWZmZXJlbnQgZnJvbSB0aGUgcmVzcG9uc2Vz IGZvciB0aGUgbWVzc2FnZSBwcm9jZXNzaW5nIHJlc3VsdHMpLg0KJmx0Oy90Jmd0OyANCiZsdDsv bGlzdCZndDsNCiZsdDsvbGlzdCZndDsNCiZsdDsvc2VjdGlvbiZndDsNCiZsdDsvc2VjdGlvbiZn dDsNCg0KJmx0OyEtLSAkTG9nOiBFdmVudE1zZy54bWwsdiAkDQombHQ7IS0tIFJld3JpdHRlbiBi eSBXZWltaW5nIFdhbmcgMjAwNC8xMC8yMg0KJmx0OyEtLSBJbmNvcnBhcmF0ZSBMRkJzZWxlY3Qg YW5kIE9wZXJhdGlvbiBUTFYgDQombHQ7IS0tDQombHQ7IS0tIFJldmlzaW9uIDEuNyAgMjAwNC8w Ny8xOSAwOTozODoxNiAgYXZyaQ0KJmx0OyEtLSBWZXJzaW9uIDIgY2hlY2tpbg0KJmx0OyEtLQ0K Jmx0OyEtLSBSZXZpc2lvbiAxLjYgIDIwMDQvMDYvMjMgMDU6MDU6MjAgIGF2cmkNCiZsdDshLS0g ZmluYWwgZWRpdCBmb3IgMDANCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS41ICAyMDA0LzA2 LzIyIDA2OjU5OjIzICBhdnJpDQombHQ7IS0tIHJlbW92ZQ0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZp c2lvbiAxLjQgIDIwMDQvMDYvMjIgMDY6NTg6MjUgIGF2cmkNCiZsdDshLS0gVGVhbSBlZGl0cyBm cm9tIDAwLTcNCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS4yICAyMDA0LTA2LTIxIDIxOjQw OjU4KzA4ICBhZG1pbmlzdHJhdG9yDQombHQ7IS0tIEluY29ycGFyYXRlIHNvbWUgY29tbWVudHMg ZnJvbSBKYW1hbCAoSnVuZSAyMSwgMjAwNCAxMDo1MCBBTSkuIC1XZWltaW5nDQombHQ7IS0tDQom bHQ7IS0tIFJldmlzaW9uIDEuMSAgMjAwNC0wNi0yMSAyMTowNzo1NCswOCAgYWRtaW5pc3RyYXRv cg0KJmx0OyEtLSBSZXZpc2lvbiBoYW5kZWQgZnJvbSBBdnJpICAtIFdlaW1pbmcNCiZsdDshLS0N CiZsdDshLS0gUmV2aXNpb24gMS4zICAyMDA0LzA2LzE5IDEzOjEzOjMwICBhdnJpDQombHQ7IS0t IEZvcm1hdHRpbmcNCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS4yICAyMDA0LzA2LzE5IDEy OjI5OjUyICBhdnJpDQombHQ7IS0tIC0gY2hhbmdlIEVuY29kaW5nVHlwZSB0byBUeXBlLiAoZnJv bSBXVykNCiZsdDshLS0gRmljZSBmb3JtYXR0aW5nDQombHQ7IS0tDQombHQ7IS0tIFJldmlzaW9u IDEuMSAgMjAwNC8wNi8xNyAwMzo0NTowMiAgYXZyaQ0KJmx0OyEtLSBJbml0aWFsIHJldmlzaW9u DQombHQ7IS0tDQogICAgIGVkaXRlZCB3aXRoICZsdDtPWHlnZW4vJmd0O1hNTCBlZGl0b3IgNC4x LCBieSBXZWltaW5nIFdhbmcgJmFtcDtMaWdhbmcgRG9uZw0KICAgICAqKiogRXZlbnRNc2cgVjEu MCwgMjAwNC0wNi0xMywgY2hhbmdlcyBzaW5jZSBsYXN0IHZlcnNpb246DQogICAgIC0gTm9uZSwg YXMgdGhlIG9yaWdpbmFsIHZlcnNpb24uDQotLSZndDsNCiAgPC9QUkU+PC9CTE9DS1FVT1RFPjxC Uj48UFJFIGNsYXNzPW1vei1zaWduYXR1cmUgY29scz0iNzIiPi0tIA0KUm9iZXJ0IEhhYXMNCklC TSBadXJpY2ggUmVzZWFyY2ggTGFib3JhdG9yeQ0KU+R1bWVyc3RyYXNzZSA0DQpDSC04ODAzIFL8 c2NobGlrb24vU3dpdHplcmxhbmQNCnBob25lICs0MS0xLTcyNC04Njk4ICBmYXggKzQxLTEtNzI0 LTg1NzggIDxBIGNsYXNzPW1vei10eHQtbGluay1mcmVldGV4dCBocmVmPSJodHRwOi8vd3d3Lnp1 cmljaC5pYm0uY29tL35yaGEiPmh0dHA6Ly93d3cuenVyaWNoLmlibS5jb20vfnJoYTwvQT48L1BS RT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0090_01C4B8F9.4151BDA0-- --===============0145242418== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0145242418==-- From forces-protocol-bounces@ietf.org Sat Oct 23 00:24:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10726 for ; Sat, 23 Oct 2004 00:24:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLDfC-0005Go-8n for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 00:37:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLDNn-0001Ei-9Z; Sat, 23 Oct 2004 00:19:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLDKd-0006j9-NY for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 00:16:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10362 for ; Sat, 23 Oct 2004 00:16:41 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLDXW-00058f-Op for forces-protocol@ietf.org; Sat, 23 Oct 2004 00:30:07 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9N3qDep028497; Sat, 23 Oct 2004 05:52:14 +0200 In-Reply-To: <1098500299.1255.33.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02FD9935@orsmsx408> <1098500299.1255.33.camel@jzny.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5186A928-24AA-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Header Section Date: Sat, 23 Oct 2004 00:16:31 -0400 To: hadi@znyx.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit On 22 okt 2004, at 22.58, Jamal Hadi Salim wrote: > So my suggestion is lets have Avri make the changes to the major:minor done > and probably get rid of the resvd field what should i do with it. make a 8 bit version number? i would just ass soon leave it reserved for now. > and leave the rest for the next > round. agree. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 02:23:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02269 for ; Sat, 23 Oct 2004 02:23:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLFWh-00079Y-SW for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 02:37:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLFFy-0003cF-CG; Sat, 23 Oct 2004 02:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLF4B-0005Kg-LA for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 02:07:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23883 for ; Sat, 23 Oct 2004 02:07:49 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLFH9-0006qS-7R for forces-protocol@ietf.org; Sat, 23 Oct 2004 02:21:15 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9N66tBO028963; Sat, 23 Oct 2004 06:06:55 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9N6AsfW022066; Sat, 23 Oct 2004 06:10:58 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102223071710138 ; Fri, 22 Oct 2004 23:07:18 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 22 Oct 2004 23:07:18 -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 Subject: RE: [Forces-protocol] Header Section Date: Fri, 22 Oct 2004 23:07:00 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> Thread-Topic: [Forces-protocol] Header Section Thread-Index: AcS4rCoBn0Gh10urTIKMGQ2b/wLugwAF4rBg From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 23 Oct 2004 06:07:18.0085 (UTC) FILETIME=[8CF0E750:01C4B8C6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: forces-protocol@ietf.org, ram.gopal@nokia.com, Weiming Wang , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Sounds good, Jamal. Just wanted to make sure it got a pair of eyes on it :) BTW, I thought we had 3 bits for Priority in the Flags in the header. When I just looked it was missing,=20 Avri is this an XML problem with the draft?? Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 On Fri, 2004-10-22 at 19:11, Khosravi, Hormuzd M wrote: > Jamal, >=20 > Pls take care of the Header section, no one seems to be looking at it. >=20 Hormuzd, Main comment on header was todo with version to remove the major minor and just have one flat space. The other thing i dont remember is whether we should get rid of the resvd field or not. Some of the falgs need revisiting; however i think the revisit will make more sense once the operations and data-path dust settles. So my suggestion is lets have Avri make the changes to the major:minor and probably get rid of the resvd field and leave the rest for the next round. Thoughts? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 02:53:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03755 for ; Sat, 23 Oct 2004 02:53:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLFzD-0007Y8-9K for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 03:06:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLFiB-0002eI-HZ; Sat, 23 Oct 2004 02:49:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLFed-0001IQ-Hv for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 02:45:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03394 for ; Sat, 23 Oct 2004 02:45:29 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLFrb-0007Qr-C9 for forces-protocol@ietf.org; Sat, 23 Oct 2004 02:58:56 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9N6L6ep028728; Sat, 23 Oct 2004 08:21:06 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Header Section Date: Sat, 23 Oct 2004 02:45:25 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, hadi@znyx.com, Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit On 23 okt 2004, at 02.07, Khosravi, Hormuzd M wrote: > BTW, I thought we had 3 bits for Priority in the Flags in the header. > When I just looked it was missing, > > Avri is this an XML problem with the draft?? yes fixed i think i included Hormuzd's section 6 changes. http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-3.txt will include Weiming's latest changes after i receive them. will try to do a read through and clean up + language edit tomorrow. Are there any other changes that have been submitted that I have missed? a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 03:26:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05034 for ; Sat, 23 Oct 2004 03:26:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLGVP-00083O-PJ for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 03:40:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLGEi-0007Ox-I5; Sat, 23 Oct 2004 03:22:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLG6P-0004ca-GV for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 03:14:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04346 for ; Sat, 23 Oct 2004 03:14:10 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLGGH-0007lR-Ew for forces-protocol@ietf.org; Sat, 23 Oct 2004 03:27:38 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Sat, 23 Oct 2004 15:28:58 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Sat, 23 Oct 2004 15:05:06 +0800 Message-ID: <115301c4b8ce$eaae4600$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Robert Haas" References: <468F3FDA28AA87429AD807992E22D07E02579209@orsmsx408><420441FF-23F7-11D9-9DB1-000393CC2112@acm.org><108701c4b84a$8028ba60$845c21d2@Necom.hzic.edu.cn> <4179571E.2080400@zurich.ibm.com> Subject: Re: [Forces-protocol] RE: draft-ietf-forces-protocol-01-0.txt Date: Sat, 23 Oct 2004 15:07:11 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.7 (+++) X-Scan-Signature: f07f95bec527e0e7fb026594d783cab5 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, avri@acm.org, forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1618796184==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 3.7 (+++) X-Scan-Signature: dfc1655f2189092f4fafe696b2c0f089 This is a multi-part message in MIME format. --===============1618796184== Content-Type: multipart/alternative; boundary="----=_NextPart_000_1150_01C4B911.F8A43470" This is a multi-part message in MIME format. ------=_NextPart_000_1150_01C4B911.F8A43470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpzZWUgcmVwbHkgaW4gbGluZS4gDQp0aGFuayB5b3UuDQp3ZWltaW5nDQog IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IFJvYmVydCBIYWFzIA0KICBU bzogV2FuZyxXZWltaW5nIA0KICBDYzogS2hvc3JhdmksIEhvcm11emQgTSA7IHJhbS5nb3BhbEBu b2tpYS5jb20gOyBhdnJpQGFjbS5vcmcgOyBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcgOyBKYW1h bCBIYWRpIFNhbGltIDsgTGlnYW5nIERvbmcgDQogIFNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDIz LCAyMDA0IDI6NTMgQU0NCiAgU3ViamVjdDogUmU6IFtGb3JjZXMtcHJvdG9jb2xdIFJFOiBkcmFm dC1pZXRmLWZvcmNlcy1wcm90b2NvbC0wMS0wLnR4dA0KDQoNCiAgV2VpbWluZywNCiAgSSBoYXZl IGEgZmV3IHN1Z2dlc3Rpb25zIGZvciB5b3VyIHNlY3Rpb25zLiBTZWUgaW5saW5lLiBQbGVhc2Ug cmV2aWV3IHRoZW0gYW5kIGluZGljYXRlIHRvIEF2cmkgaWYgc2hlIHNob3VsZCBpbmNvcnBvcmF0 ZSB0aGVzZSBpbnRvIHRoZSBmaW5hbCBkcmFmdC4gSXQgd291bGQgYmUgZ29vZCBpZiBBdnJpIGNv dWxkIGRvIHRoZSBlbmdsaXNoLWNoZWNrIG9uIHRoZXNlIHNlY3Rpb25zIHRvIGFzIEkgYW0gbm90 IGEgbmF0aXZlIGVuZ2xpc2ggc3BlYWtlciBuZWl0aGVyDQogIFJlZ2FyZHMsDQogIC1Sb2JlcnQN Cg0KIDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DQo8IS0tIGVkaXRlZCB3 aXRoIDxPWHlnZW4vPlhNTCBlZGl0b3IgNC4xLCBieSBXZWltaW5nIFdhbmcgJiBMaWdhbmcgRG9u ZyANCiAgICAgKioqIFJlZGlyZWN0TXNnIFYxLjAsIDIwMDQtMDYtMTMsIGNoYW5nZXMgc2luY2Ug bGFzdCB2ZXJzaW9uOg0KICAgICAtIE5vbmUsIGFzIHRoZSBvcmlnaW5hbCB2ZXJzaW9uLg0KICAg ICAqKiogUmVkaXJlY3RNc2dWMS4xLCAyMDA0LTA2LTE4Lg0KLS0+DQoNCjxzZWN0aW9uIGFuY2hv cj0iUmVkaXJlY3RNc2ciIHRpdGxlPSJQYWNrZXQgUmVkaXJlY3QgTWVzc2FnZSI+DQoNCjx0PlBh Y2tldCByZWRpcmVjdCBtZXNzYWdlIGlzIHVzZWQgdG8gdHJhbnNmZXIgZGF0YSBwYWNrZXRzIA0K ICAgIGJldHdlZW4gQ0UgYW5kIEZFLiBVc3VhbGx5IHRoZXNlIGRhdGEgcGFja2V0cyBhcmUgSVAg cGFja2V0cywgDQogICAgdGhvdWdoIHRoZXkgbWF5IHNvbWV0aW1lcyBhc3NvY2lhdGVkIHdpdGgg c29tZSBtZXRhZGF0YSANCiAgICBnZW5lcmF0ZWQgYnkgb3RoZXIgTEZCcyBpbiB0aGUgbW9kZWws IG9yIHRoZXkgbWF5IA0KICAgIG9jY2FzaW9uYWxseSBiZSBvdGhlciBwcm90b2NvbCBwYWNrZXRz LCB3aGljaCB1c3VhbGx5IGhhcHBlbiANCiAgICB3aGVuIENFIGFuZCBGRSBhcmUgam9pbnRseSBp bXBsZW1lbnRpbmcgc29tZSBoaWdoLXRvdWNoIA0KICAgIG9wZXJhdGlvbnMuIFBhY2tldHMgcmVk aXJlY3RlZCBmcm9tIEZFIHRvIENFIGFyZSB0aGUgZGF0YSANCiAgICBwYWNrZXRzIHRoYXQgY29t ZSBmcm9tIGZvcndhcmRpbmcgcGxhbmUsIGFuZCB1c3VhbGx5IGFyZSB0aGUgDQogICAgZGF0YSBw YWNrZXRzIHRoYXQgbmVlZCBoaWdoLXRvdWNoIG9wZXJhdGlvbnMgaW4gQ0UuDQogICAuLi4gb3Ig cGFja2V0cyBmb3Igd2hpY2ggdGhlIElQIGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgdGhlIE5FLiBb Tm90ZSB0aGF0IEkgZGlzdGluZ3Vpc2ggaGlnaC10b3VjaCBvcGVyYXRpb25zIGZyb20gZW5kcG9p bnQgcHJvdG9jb2wgcHJvY2Vzc2luZ10NCiAgW1ddZG9uZS4NCg0KIFBhY2tldHMgDQogICAgcmVk aXJlY3RlZCBmcm9tIENFIHRvIEZFIGFyZSB0aGUgZGF0YSBwYWNrZXRzIHRoYXQgYXJlIA0KICAg IGdlbmVyYXRlZCBieSBDRSBhbmQgYXJlIGRlY2lkZWQgYnkgQ0UgdG8gcHV0IGludG8gZm9yd2Fy ZGluZyANCiAgICBwbGFuZSBpbiBGRS48L3Q+DQoNCiAgDQogIGRvbid0IHdyaXRlICJnZW5lcmF0 ZWQgYnkgdGhlIENFIi4gU3VjaCBwYWNrZXRzIGNvdWxkIHZlcnkgd2VsbCBiZSBwYWNrZXRzIHRo YXQgaW5pdGlhbGx5IHdlcmUgcmVkaXJlY3RlZCBmcm9tIGFuIEZFLiBJbnN0ZWFkLCBqdXN0IHNh eSAiY29tZSBmcm9tIHRoZSBDRSIuDQogIFtXXWRvbmUuDQoNCjx0PkJ5IHByb3Blcmx5IGNvbmZp Z3VyaW5nIHJlbGF0ZWQgTEZCcyBpbiBGRSwgYSBwYWNrZXQgY2FuIGFsc28gDQogICAgYmUgbWly cm9yZWQgdG8gQ0UgaW5zdGVhZCBvZiBwdXJlbHkgcmVkaXJlY3RlZCB0byBDRSwgaS5lLiwgDQog ICAgdGhlIHBhY2tldCBpcyBkdXBsaWNhdGVkIGFuZCBvbmUgaXMgcmVkaXJlY3RlZCB0byBDRSBh bmQgdGhlIA0KICAgIG90aGVyIGNvbnRpbnVlcyBpdHMgd2F5IGluIHRoZSBMRkIgdG9wb2xvZ3ku IDwvdD4NCg0KICANCiAgU2lkZSBub3RlOiB3ZSB3aWxsIGhhdmUgdG8gZGVmaW5lIGhvdyB0aGUg cGFja2V0IGhlYWRlciBvbmx5IGNhbiBiZSBwYXNzZWQgdG8gdGhlIENFLCBhbmQgbGVhdmUgdGhl IHBheWxvYWQgaW4gdGhlIEZFLCB1bnRpbCB0aGUgQ0UgZGVjaWRlcyB3aGF0IHRvIGRvIHdpdGgg dGhlIHBhY2tldC4NCiAgW1ddTXkgdGhvdWdodCBpcyB3aGljaCBwYXJ0IG9mIGEgcGFja2V0IHdp bGwgYmUgcmVkaXJlY3RlZCB0byB3aWxsIGJlIGRlY2lkZWQgYnkgb3RoZXIgTEZCcyB0aGFuIHRo ZSBzcGVjaWZpYyByZWRpcmVjdCBMRkIuIEluIHRoaXMgd2F5LCB3ZSBsZWF2ZSBtdWNoIGZsZXhp YmlsaXR5Lg0KDQogIFNlY29uZCBzaWRlIG5vdGU6IHdlIG5lZWQgdG8gc3BlY2lmeSB3aHkgd2Ug Y29uc2lkZXIgdGhhdCBwYWNrZXRfcmVkaXJlY3QgZGVzZXJ2ZXMgaXRzIG93biBtZXNzYWdlIHR5 cGUsIGFuZCBub3Qgc2ltcGx5IGJlIHRyZWF0ZWQgYXMgYW4gZXZlbnQgZmlyZWQgYnkgdGhlIFJl ZGlyZWN0IExGQiB0aGF0IGNvbnRhaW5zLCBhcyBwYXJ0IG9mIHRoZSBldmVudCBkYXRhLCB0aGUg cGFja2V0IGl0c2VsZi4gTXkgdGhpbmtpbmcgaXMgdGhhdCB1c2luZyBhIHNwZWNpZmljIG1lc3Nh Z2UgdHlwZSBpcyBpbXBvcnRhbnQgdG8gbGV0IHRoZSBDRSBkaXN0aW5ndWlzaCBwcm9tcHRseSBp ZiB0aGUgbWVzc2FnZSBpcyBhbiBGRS1pbnRlcm5hbCBldmVudCBvciBhbiBleHRlcm5hbCBwYWNr ZXQgdGhhdCB3YXMganVzdCBmb3J3YXJkZWQuIFNvbWV0aGluZyBsaWtlIHRoaXMgc2hvdWxkIGJl IHdyaXR0ZW4gaW4gdGhlIGludHJvIG9mIHRoaXMgc2VjdGlvbi4gV2VpbWluZyA/DQogIFtXXSBJ IHRoaW5rIHRoZSBtb3N0IGltcG9ydGFudCB0byBoYXZlIGEgc3BlY2lmaWMgcmVkaXJlY3QgbWVz c2FnZSBpcyBmb3IgRG9TIHByZXZlbnRpb24uIEkndiBhZGQgc29tZSB0aGluZy4NCjx2c3BhY2Ug YmxhbmtMaW5lcz0iMSIgLz4NCjxsaXN0IHN0eWxlPSJoYW5naW5nIiBoYW5nSW5kZW50PSIxNyI+ DQo8dCBoYW5nVGV4dCA9ICJFZGl0b3JpYWwgTm90ZTogIj4gDQpUaGVyZSBhcmUgYWxzbyBkaXNj dXNzaW9ucyBvbiBob3cgTEZCcyBpbiBGRSBtb2RlbCB0aGF0IGFyZSANCiAgICByZWxhdGVkIHRv IHBhY2tldCByZWRpcmVjdCBvcGVyYXRpb25zIHNob3VsZCBiZSBkZWZpbmVkLiBBbHRob3VnaCAN CiAgICBpdCBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIGZvcmNlcyBwcm90b2NvbCwgaG93IHRvIGRl ZmluZSB0aGUgTEZCcyANCiAgICBhZmZlY3QgdGhlIFBhY2tldCBSZWRpcmVjdCBNZXNzYWdlIGRl c2NyaWJlZCBoZXJlLiBCZWNhdXNlIGN1cnJlbnRseQ0KICAgIGl0IGlzIHN0aWxsIGluIHByb2dy ZXNzIGluIEZFIG1vZGVsIG9uIGhvdyB0byBkZWZpbmUgc3VjaCBMRkJzLCANCiAgICB3ZSB0cnkg dG8gcG9zdCBzb21lIHRob3VnaHRzIG9uIHRoaXMgaGVyZSBmb3IgZGlzY3Vzc2lvbi4gVGhleSAN CiAgICB3aWxsIGJlIHJlbW92ZWQgbGF0ZXIgYWxvbmcgd2l0aCB0aGUgcHJvZ3Jlc3Mgb2YgdGhl IEZFIG1vZGVsIHdvcmsuDQo8L3Q+DQo8dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8+DQo8dCBoYW5n VGV4dCA9IiAgICAgVGhvdWdodCAxOiAiPg0KVG8gZGVmaW5lIExGQnMgY2FsbGVkICdSZWRpcmVj dFNpbmsnIGFuZCAnUmVkaXJlY3RUYXAnIGZvcg0KcGFja2V0IHJlZGlyZWN0LjwvdD4NCjx0PkFu IExGQiBpbiBGRSBjYWxsZWQgJ1JlZGlyZWN0U2luaycgaXMgcmVzcG9uc2libGUgdG8gY29sbGVj dCANCiAgICBkYXRhIHBhY2tldHMgdGhhdCBuZWVkIHRvIGJlIHJlZGlyZWN0ZWQgdG8gQ0UuIEZy b20gdGhlIA0KICAgIHBlcnNwZWN0aXZlIG9mIHRoZSBGRSBMRkIgdG9wb2xvZ3ksIHRoZSAnUmVk aXJlY3RTaW5rJyBMRkIgDQogICAgaXMgYW4gTEZCIHdpdGggb25seSBvbmUgaW5wdXQgcG9ydCBh bmQgd2l0aG91dCBhbnkgb3V0cHV0IA0KICAgIHBvcnQsIGFuZCB0aGUgaW5wdXQgcG9ydCBjYW4g dGhlbiBiZSBjb25uZWN0ZWQgdG8gYW55IG90aGVyIA0KICAgIExGQiBpbiBGRSBtb2RlbCBieSBt ZWFucyBvZiBhIGRhdGFwYXRoIGluIHRoZSBmb3J3YXJkaW5nIA0KICAgIHBsYW5lLiBGcm9tIHRo ZSBwZXJzcGVjdGl2ZSBvZiB0aGUgRm9yQ0VTIHByb3RvY29sIGxheWVyLCANCiAgICB0aGUgJ1Jl ZGlyZWN0U2luaycgTEZCIHdpbGwgZ2VuZXJhdGUgdGhlIFBhY2tldCBSZWRpcmVjdCANCiAgICBN ZXNzYWdlcyB3aGVuIGl0IHJlY2VpdmVzIGRhdGEgcGFja2V0cyBmcm9tIGZvcndhcmRpbmcgcGxh bmUuDQo8L3Q+DQo8dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8+DQo8dD5BbiBMRkIgaW4gRkUgY2Fs bGVkICdSZWRpcmVjdFRhcCcgaXMgcmVzcG9uc2libGUgdG8gcmVjZWl2ZSANCiAgICBkYXRhIHBh Y2tldHMgdGhhdCBhcmUgcmVkaXJlY3RlZCBmcm9tIENFLiBGcm9tIHRoZSBwZXJzcGVjdGl2ZSAN CiAgICBvZiB0aGUgRkUgTEZCIHRvcG9sb2d5LCB0aGUgJ1JlZGlyZWN0VGFwJyBMRkIgaXMgYW4g TEZCIHdpdGggDQogICAgb25seSBvbmUgb3V0cHV0IHBvcnQgYW5kIHdpdGhvdXQgYW55IGlucHV0 IHBvcnQsIGFuZCB0aGUgDQogICAgb3V0cHV0IHBvcnQgY2FuIHRoZW4gYmUgY29ubmVjdGVkIHRv IGFueSBvdGhlciBMRkIgaW4gRkUgDQogICAgbW9kZWwgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBp biB0aGUgZm9yd2FyZGluZyBwbGFuZS4gRnJvbSANCiAgICB0aGUgcGVyc3BlY3RpdmUgb2YgRm9y Q0VTIHByb3RvY29sIGxheWVyLCB0aGUgJ1JlZGlyZWN0VGFwJyANCiAgICBMRkIgY2FuIHJlY2Vp dmUgdGhlIFBhY2tldCBSZWRpcmVjdCBNZXNzYWdlcyBmcm9tIENFLCBhbmQgDQogICAgdW4tZW5j YXBzdWxhdGUgdGhlIGRhdGEgcGFja2V0cyBmcm9tIHRoZSBtZXNzYWdlIGFuZCBwdXQgDQogICAg dGhlbSB0byBkYXRhcGF0aHMgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuIEFjdHVhbGx5IHRoZSAN CiAgICAnUmVjaXJlY3RUYXAnIExGQiBhY3RzIG1vcmUgbGlrZSBhIHRyYW5zY29kZXIgdGhhdCB0 cmFuc2ZlcnMgDQogICAgdGhlIEZvckNFUyBwcm90b2NvbCBtZXNzYWdlcyB0byBub3JtYWwgZGF0 YSBwYWNrZXRzIGluIElQIA0KICAgIGZvcndhcmRpbmcgcGxhbmUuIEFzIGEgcmVzdWx0LCBpZiB3 ZSBuZWVkIHRvIGhhdmUgcmVkaXJlY3RlZCANCiAgICBwYWNrZXRzIGNvbm5lY3RlZCB0byBzb21l IExGQiAoc2F5IGEgU2NoZWR1bGVyKSBpbiBGRSBtb2RlbCwgDQogICAgd2Ugb25seSBuZWVkIHRv IGNvbm5lY3QgdGhlICdSZWRpcmVjdFRhcCBMRkIgdG8gdGhlIFNjaGVkdWxlciANCiAgICBMRkIg ZGlyZWN0bHkgdmlhIGEgZGF0YXBhdGggYXMgZm9sbG93czoNCjx2c3BhY2UgYmxhbmtMaW5lcz0i MSIgLz4NCjxmaWd1cmUgYW5jaG9yPSJMRkJfUmVkaXJlY3QiPjxhcnR3b3JrPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgICstLS0tLS0tLS0tLSsN CiAgICAgICAgICAgICAgICAgICAgICAgICAgfCBSZWRpcmVjdFRhcCBMRkIgfC0tLS0tLT58ICAg ICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLSsg ICAgICAgfCAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgU2NoZWR1bGVyIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEZyb20gb3RoZXIgTEZCICAgLS0tLT58ICAgIExGQiAgICB8DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LSsNCjwvYXJ0d29yaz48L2ZpZ3VyZT4NCjwvdD4NCjx2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLz4N Cjx0PkJ5IHVzZSBvZiBzZXZlcmFsICdSZWRpcmVjdFNpbmsnIExGQnMgYW5kIHNldmVyYWwgJ1Jl ZGlyZWN0VGFwJyANCiAgICBMRkJzIHRoYXQgY29ubmVjdCB0byBzZXZlcmFsIGRpZmZlcmVudCBk YXRhcGF0aHMgaW4gRkUgDQogICAgZm9yd2FyZGluZyBwbGFuZSwgbXVsdGlwbGUgcGFja2V0IHJl ZGlyZWN0IHBhdGhzIGJldHdlZW4gDQogICAgQ0UgYW5kIEZFIGNhbiBiZSBjb25zdHJ1Y3RlZC4g PC90Pg0KPHZzcGFjZSBibGFua0xpbmVzPSIxIiAvPg0KPHQgaGFuZ1RleHQgPSIgICAgIFRob3Vn aHQgMjogIj4NCiAgICBUaGVyZSBtaWdodCBiZSBhbm90aGVyIHdheSBhIHBhY2tldCBjb3VsZCBi ZSByZWRpcmVjdGVkOg0KICAgIGRpcmVjdGx5IGJ5IGEgZm9yd2FyZGluZyBwYXRoLCBlLmcuLCBi eSBGUEdBL0FTSUMvTlAgbWljcm9jb2RlLiBJbiANCiAgICBzdWNoIGEgY2FzZSB3ZSBkbyBub3Qg bmVlZCB0byBwdXQgaW4gYSBsb3Qgb2Ygc21hcnRuZXNzLiBQcm9iYWJseSANCiAgICBhIGxpbmsg bGF5ZXIgb3IgZXZlbiBuZXR3b3JrIGxldmVsIGhlYWRlciBpcyBlbm91Z2guIFRoZSByZWNlaXZl ciANCiAgICBkZW11eGVzIGl0IG9ubHkgYmFzZWQgb24gc29tZSBwcm90b2NvbCB0eXBlIGluIHRo ZSBsaW5rIGxheWVyIG9yIA0KICAgIG5ldHdvcmsgdHJhbnNwb3J0IGxheWVyLiBUaGUgcHJvcyBm b3IgdGhpcyBhcHByYW9jaCBpcyBpdCBtYXkgDQogICAgcHJvdmlkZSBhIGZhc3QgYW5kIGNvc3Qt ZWZmZWN0aXZlIHBhdGggZm9yIHBhY2tldCByZWRpcmVjdC4gVGhlIA0KICAgIGNvbnMgZm9yIHRo aXMgaXMgaXQgbWF5IG1vcmUgb3IgbGVzcyBjb25mdXNlcyB0aGUgRnAgcmVmZXJlbmNlIA0KICAg IHBvaW50IGRlZmluaXRpb24gaW4gRm9yQ0VTIGZyYW1ld29yay4gDQo8L3Q+DQo8L2xpc3Q+DQo8 dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8+DQo8dD5XZSBkZXNjcmliZSB0aGUgUGFja2V0IFJlZGly ZWN0IE1lc3NhZ2UgZGF0YSBmb3JtYXQgaW4gZGV0YWlscyANCiAgICBhcyBmb2xsb3dzOjwvdD4N CjxsaXN0IHN0eWxlPSJoYW5naW5nIiBoYW5nSW5kZW50PSIxIj4NCjx0IGhhbmdUZXh0PSAiTWVz c2FnZSBEaXJlY3Rpb246ICAiPjx2c3BhY2UgLz4NCkNFIHRvIEZFIG9yIEZFIHRvIENFDQo8L3Q+ DQoNCg0KPHQgaGFuZ1RleHQ9ICJNZXNzYWdlIEhlYWRlcjogICI+PHZzcGFjZSAvPg0KVGhlIE1l c3NhZ2UgVHlwZSBpbiB0aGUgaGVhZGVyIGlzIHNldCB0byANCiAgICBNZXNzYWdlVHlwZT0gJ1Bh Y2tldFJlZGlyZWN0Jy4gVGhlIEFDSyBmbGFncyBpbiB0aGUgaGVhZGVyIA0KICAgIFNIT1VMRCBi ZSBzZXQgJ05vQUNLJywgbWVhbmluZyBubyByZXNwb25zZSBpcyBleHBlY3RlZCBieSB0aGlzIA0K ICAgIG1lc3NhZ2UuIElmIHRoZSBBQ0sgZmxhZyBpcyBzZXQgb3RoZXIgdmFsdWVzLCB0aGUgDQog ICAgbWVhbmluZ3Mgd2lsbCBiZSBpZ25vcmVkLg0KPC90Pg0KDQoNCjx0IGhhbmdUZXh0PSAiTWVz c2FnZSBCb2R5OiAiPjx2c3BhY2UgLz4NCkNvbnNpc3RzIG9mIG9uZSBvciBtb3JlIFRMVnMsIHdp dGggZXZlcnkgVExWIGhhdmluZyB0aGUgDQogICAgZm9sbG93aW5nIGRhdGEgZm9ybWF0Og0KPC90 Pg0KDQogIA0KPGZpZ3VyZSBhbmNob3I9InRsdl9SZWRpcmVjdF9EYXRhIj4NCjxhcnR3b3JrPg0K ICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDENCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgVHlwZSA9IExGQnNlbGVj dCAgICAgICB8ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgTEZCIENsYXNzIElEICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgIExGQiBJbnN0YW5jZSBJRCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdGlvaW4gVExWICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfiAg ICAgICAgICAgICAgICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIH4NCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJh dGlvaW4gVExWICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgDQo8L2FydHdvcms+PC9maWd1cmU+DQoNCjx0IGhhbmdUZXh0PSAiTEZCIGNs YXNzIElEOiAiPjx2c3BhY2UgLz4NClRoZXJlIGFyZSBvbmx5IHR3byBwb3NzaWJsZSBMRkIgY2xh c3NlcyBoZXJlLCB0aGUgDQogICAgJ1JlZGlyZWN0U2luaycgTEZCIG9yIHRoZSAnUmVkaXJlY3RU YXAnIExGQi4gSWYgdGhlIG1lc3NhZ2UgaXMgDQogICAgZnJvbSBGRSB0byBDRSwgdGhlIExGQiBj bGFzcyBzaG91bGQgYmUgJ1JlZGlyZWN0U2luaycuIElmIHRoZSANCiAgICBtZXNzYWdlIGlzIGZy b20gQ0UgdG8gRkUsIHRoZSBMRkIgY2xhc3Mgc2hvdWxkIGJlICdSZWRpcmVjdFRhcCcuDQo8L3Q+ DQoNCiAgDQogIFdoeSByZXN0cmljdCB0aGlzID8gSWYgYW55IG90aGVyIExGQiB3YW50cyB0byBn ZW5lcmF0ZSBhIHBhY2tldCByZWRpcmVjdCB0byB0aGUgQ0UsIGxldCBoaW0gZG8gaXQgIQ0KICBb V11NeSB0aG91Z2h0IGlzIGRpZmZlcmVudC4gSWYgc29tZSBMRkJzIHRoYXQgaGF2ZSBkYXRhIHJl ZGlyZWN0ZWQgdG8gQ0UsIHRoZXkganVzdCB1c2UgYSByZWRpcmVjdCBMRkIgYXMgaXRzIG91dHB1 dC4gSW4gdGhpcyB3YXksIHdlIGp1c3Qgc2F2ZQ0KICB0aGUgd29yayB0byBjb25maWd1cmUgdGhl IExGQiBmb3IgcmVkaXJlY3QgZnVuY3Rpb25zLkZvciBpbnN0YW5jZSwgaWYgd2UgbmVlZCB0byBo YXZlIHNvbWUgY2xhc3NpZmllciB0byByZWRpcmVjdCBzb21ldGhpbmcsIHdlIGp1c3QgbmVlZCB0 byBoYXZlIG9uZSBvdXRwdXQNCiAgb2YgdGhlIGNsYXNzaWZpZXIgY29ubmVjdGVkIHRvIHJlZGly Y3QgTEZCLCByYXRoZXIgdGhhbiB0byBkZWZpbmUgYSBzcGVjaWZpYyBhdHRyaWJ1dGVzIGluIHRo ZSBjbGFzc2lmaWVyIGZvciByZWRpcmVjdC4gSSBldmVuIGNhbiBub3Qgc2VlIGhvdyBzdWNoIGF0 dHJpYnV0ZSBjYW4gYmUgZGVmaW5lZC4gDQoNCjx0IGhhbmdUZXh0PSAiSW5zdGFuY2UgSUQ6ICI+ PHZzcGFjZSAvPg0KSW5zdGFuY2UgSUQgZm9yIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgb3IgJ1Jl ZGlyZWN0VGFwJyBMRkIuDQo8L3Q+DQoNCg0KPHQgaGFuZ1RleHQ9ICJPcGVyYXRpb24gVExWOiAi Pjx2c3BhY2UgLz4NClRoaXMgaXMgYSBUTFYgZGVzY3JpYmluZyBvbmUgcGFja2V0IG9mIGRhdGEg dG8gYmUgZGlyZWN0ZWQgDQogICAgdmlhIHRoZSBzcGVjaWZpZWQgTEZCIGFib3ZlLiBUaGUgb3Jk ZXIgb2YgdGhlIGRhdGEgbnVtYmVyIGlzIA0KICAgIGFsc28gdGhlIG9yZGVyIHRoZSBkYXRhIHBh Y2tldCBhcnJpdmVzIHRoZSByZWRpcmVjdG9yIExGQiwgdGhhdCANCiAgICBpcywgdGhlIFJlZGly ZWN0ZWQgRGF0YSAjMSBzaG91bGQgYXJyaXZlIGVhcmxpZXIgdGhhbiB0aGUgDQogICAgUmVkaXJl Y3RlZCBEYXRhICMyIGluIHRoaXMgcmVkaXJlY3RvciBMRkIuIFRoZSBUTFYgZm9ybWF0IGlzIA0K ICAgIGFzIGZvbGxvd3M6DQo8L3Q+DQogIA0KICBJZiB3aGF0IHlvdSBtZWFuIGlzIHNlcXVlbmNp bmcgdGhlIHJlZGlyZWN0ZWQgcGFja2V0IHRoZW4gSSB0aGluayBpdCBpcyBkYW5nZXJvdXMuIEFz c3VtZSB5b3UgdXNlIFVEUCB0byB0cmFuc3BvcnQgdGhlIHJlZGlyZWN0ZWQgcGFja2V0cyBmcm9t IHRoZSBDRSB0byB0aGUgRkUuIElmIG9uZSBpcyBsb3N0LCB0aGVuIHdoYXQgd2lsbCB0aGUgRkUg ZG8gd2l0aCB0aGUgbmV4dCBvbmVzID8NCiAgW1ddIHNlcXVlbmluZyBmb3IgcmVkaXJlY3QgZGF0 YSBpcyBpbXBvcnRhbnQuIFdoYXQgSSBtZW50aW9uZWQgaGVyZSBpcyBvbmx5IHRoZSBzZXF1ZW5j ZSBpbnNpZGUgb25lIG1lc3NhZ2Uob25lIFVEUCApLCBJIHNlZSBzZXF1ZW5jZSBudW1iZXIgaW4g bWVzc2FnZSBoZWFkZXIgaXMgaW4gY2hhcmdlIG9mIHNlcXVlbmNlIGJldHdlZW4gVURQIHBhY2tl dHMuIEkgc3VwcG9zZSBhIGxvc3Mgb2YgVURQIHdpbGwgbGVhZCB0byByZXRyYW5zbWlzc2lvbiBj b250cm9sbGVkIGJ5IFBMLiBJZiB3ZSB1c2UgVENQLCB0aGUgVE1MIGlzIGluIGNoYXJnZSBvZiB0 aGlzLg0KDQoNCjxmaWd1cmUgYW5jaG9yPSJ0bHZfUmVkaXJlY3RlZF9EYXRhIj48YXJ0d29yaz4N CiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgICAgfCAgICBUeXBlID0gT3BlcmF0aW9ucyAoUEFZTE9BRCl8ICAg ICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgIFBhdGgob3IgU2VxdWVuY2UgTnVtYmVyPykgICAgICAgICAgICAg IHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgICAgfiAgICAgICAgICAgICAgICAgICAgICAgIFJlZGlyZWN0 ZWQgRGF0YSAgICAgICAgICAgICAgICAgICAgICAgIH4NCiAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCjwvYXJ0d29y az48L2ZpZ3VyZT4NCjx0IGhhbmdUZXh0PSAiUGF0aChvciBTZXF1ZW5jZSBOdW1iZXI/KTogIj48 dnNwYWNlIC8+DQpbVW5kZXIgZGlzY3Vzc2lvbiBhbmQgVEJEXQ0KPC90Pg0KPHQgaGFuZ1RleHQ9 ICJUeXBlOiAiPjx2c3BhY2UgLz4NCltUQkRdDQo8L3Q+DQoNCjx0IGhhbmdUZXh0PSAiUmVkaXJl Y3RlZCBEYXRhOiAiPjx2c3BhY2UgLz4NClRoaXMgZmllbGQgd2lsbCBtYWtlIGEgZGV0YWlsZWQg ZGVzY3JpcHRpb24gb2YgdGhlIGRhdGEgdG8gDQogICAgYmUgcmVkaXJlY3RlZCBhcyB3ZWxsIGFz IHRoZSBkYXRhIGl0c2VsZi4gVGhlIGVuY29kaW5nIG9mIHRoZSANCiAgICBkZXNjcmlwdGlvbiBp cyBiYXNlZCBvbiB0aGUgRm9yQ0VTIEZFIG1vZGVsIGlmIHRoZSByZWRpcmVjdG9yIA0KICAgIExG QiBpcyBkZWZpbmVkIGJ5IEZFIG1vZGVsLCBvciBiYXNlZCBvbiB2ZW5kb3Igc3BlY2lmaWNhdGlv bnMgDQogICAgaWYgdGhlIHJlZGlyZWN0b3IgTEZCIGlzIGRlZmluZWQgYnkgdmVuZG9ycy4gVGhl IGRlc2NyaXB0aW9uIA0KICAgIHdpbGwgdXN1YWxseSBpbmNsdWRlIHRoZSBuYW1lIChvciB0aGUg bmFtZSBJRCkgb2YgdGhlIHJlZGlyZWN0ZWQgDQogICAgcGFja2V0IGRhdGEgKHN1Y2ggYXMgJ0lQ djQgUGFja2V0JywgJ0lQdjYgUGFja2V0JyksIGFuZCB0aGUgDQogICAgcGFja2V0IGRhdGEgaXRz ZWxmLiBJdCBtYXkgYWxzbyBpbmNsdWRlIHNvbWUgbWV0YWRhdGEgKG1ldGFkYXRhIA0KICAgIG5h bWUgKG9yIG5hbWUgSUQpIGFuZCBpdHMgdmFsdWUpYXNzb2NpYXRlZCB3aXRoIHRoZSByZWRpcmVj dGVkIA0KICAgIGRhdGEgcGFja2V0Lg0KPC90Pg0KPC9saXN0Pg0KPC9zZWN0aW9uPg0KDQo8IS0t ICRMb2c6IFJlZGlyZWN0TXNnLnhtbCx2ICQNCjwhLS0gUmV3cml0dGVuIGJ5IFdlaW1pbmcgV2Fu ZyAyMDA0LzEwLzIyDQo8IS0tIEluY29ycGFyYXRlIExGQnNlbGVjdCBhbmQgT3BlcmF0aW9uIFRM ViANCjwhLS0NCjwhLS0gUmV2aXNpb24gMS43ICAyMDA0LzA3LzE5IDA5OjM3OjA1ICBhdnJpDQo8 IS0tIFZlcnNpb24gMiBjaGVja2luDQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuNiAgMjAwNC8wNi8y MyAwNTowNTozNCAgYXZyaQ0KPCEtLSBmaW5hbCBlZGl0IGZvciAwMA0KPCEtLQ0KPCEtLSBSZXZp c2lvbiAxLjUgIDIwMDQvMDYvMjIgMDc6MDI6MzcgIGF2cmkNCjwhLS0gcmVtb3ZlDQo8IS0tDQo8 IS0tIFJldmlzaW9uIDEuNCAgMjAwNC8wNi8yMiAwNzowMTowMCAgYXZyaQ0KPCEtLSBUZWFtIEVk aXQgZnJvbSAwMC03DQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuMiAgMjAwNC0wNi0yMSAyMTo0MDo0 MSswOCAgYWRtaW5pc3RyYXRvcg0KPCEtLSBJbmNvcnBhcmF0ZSBzb21lIGNvbW1lbnRzIGZyb20g SmFtYWwgKEp1bmUgMjEsIDIwMDQgMTA6NTAgQU0pLiAtV2VpbWluZw0KPCEtLQ0KPCEtLSBSZXZp c2lvbiAxLjEgIDIwMDQtMDYtMjEgMjE6MDk6NDErMDggIGFkbWluaXN0cmF0b3INCjwhLS0gUmV2 aXNpb24gaGFuZGVkIGZyb20gQXZyaS4gLSBXZWltaW5nDQo8IS0tDQo8IS0tIFJldmlzaW9uIDEu MyAgMjAwNC8wNi8xOSAxMzoxMToxMiAgYXZyaQ0KPCEtLSBMaW5lZmVlZHMNCjwhLS0NCjwhLS0g UmV2aXNpb24gMS4yICAyMDA0LzA2LzE5IDEzOjA1OjAwICBhdnJpDQo8IS0tIGFuY2hvcnMNCjwh LS0NCjwhLS0gUmV2aXNpb24gMS4xICAyMDA0LzA2LzE3IDAzOjQ1OjU1ICBhdnJpDQo8IS0tIElu aXRpYWwgcmV2aXNpb24NCjwhLS0gDQogICAgIGVkaXRlZCB3aXRoIDxPWHlnZW4vPlhNTCBlZGl0 b3IgNC4xLCBieSBXZWltaW5nIFdhbmcgJiBMaWdhbmcgRG9uZyANCiAgICAgKioqIFJlZGlyZWN0 TXNnIFYxLjAsIDIwMDQtMDYtMTMsIGNoYW5nZXMgc2luY2UgbGFzdCB2ZXJzaW9uOg0KICAgICAt IE5vbmUsIGFzIHRoZSBvcmlnaW5hbCB2ZXJzaW9uLg0KLS0+DQogIA0KPD94bWwgdmVyc2lvbj0i MS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjwhLS0gZWRpdGVkIHdpdGggPE9YeWdlbi8+WE1MIGVk aXRvciA0LjEsIGJ5IFdlaW1pbmcgV2FuZyAmIExpZ2FuZyBEb25nIA0KICAgICAqKiogUXVlcnlN c2cgVjEuMCwgMjAwNC0wNi0xMywgY2hhbmdlcyBzaW5jZSBsYXN0IHZlcnNpb246DQogICAgIC0g Tm9uZSwgYXMgdGhlIG9yaWdpbmFsIHZlcnNpb24uDQogICAgICoqKiBRdWVyeU1zZ1YxLjEsIDIw MDQtMDYtMTgNCiAgICAgLSBjaGFuZ2UgRW5jb2RpbmdUeXBlIHRvIFR5cGUNCiAgICAgKioqIFF1 ZXJ5TXNnVjEuMiwgMjAwNC0xMC0yMA0KICAgICAtIGZvciBpZXRmLXByb3RvY29sLTAxDQotLT4N Cg0KPHNlY3Rpb24gYW5jaG9yPSJRdWVyeU1zZyIgdGl0bGU9IlF1ZXJ5IGFuZCBSZXNwb25zZSBN ZXNzYWdlcyI+DQogIA0KICBCZSBtb3JlIHNwZWNpZmljOiAiUXVlcnkgYW5kIFF1ZXJ5IFJlc3Bv bnNlIE1lc3NhZ2VzIg0KICBbT0tdDQoNCjx0PlRoZSBGb3JDRVMgcXVlcnkgYW5kIHJlc3BvbnNl IG1lc3NhZ2VzIGFyZSB1c2VkIGZvciBvbmUgRm9yQ0VTIA0KICAgIGVsZW1lbnQgKENFIG9yIEZF KSB0byBxdWVyeSBvdGhlciBGb3JDRVMgZWxlbWVudChzKSBmb3IgdmFyaW91cyANCiAgICBraW5k cyBvZiBpbmZvcm1hdGlvbi4gQ3VycmVudCB2ZXJzaW9uIG9mIEZvckNFUyBwcm90b2NvbCBsaW1p dHMgDQogICAgdGhlIHVzZSBvZiB0aGUgbWVzc2FnZXMgb25seSBmb3IgQ0UgdG8gcXVlcnkgaW5m b3JtYXRpb24gb2YgRkUuIA0KPC90Pg0KPHNlY3Rpb24gYW5jaG9yPSJRdWVyeSIgdGl0bGU9IlF1 ZXJ5IE1lc3NhZ2UiPg0KDQo8dD5BcyB1c3VhbCwgYSBxdWVyeSBtZXNzYWdlIGlzIGNvbXBvc2Vk IG9mIGEgY29tbW9uIGhlYWRlciBhbmQgDQogICAgYSBtZXNzYWdlIGJvZHkgdGhhdCBjb25zaXN0 cyBvZiBvbmUgb3IgbW9yZSBUTFYgZGF0YSBmb3JtYXQuIA0KICAgIERldGFpbGVkIGRlc2NyaXB0 aW9uIG9mIHRoZSBtZXNzYWdlIGlzIGFzIGJlbG93LjwvdD4NCjxsaXN0IHN0eWxlPSJoYW5naW5n IiBoYW5nSW5kZW50PSI0Ij4gPHZzcGFjZSAvPg0KPHZzcGFjZSBibGFua0xpbmVzPSIxIiAvPg0K PHQgaGFuZ1RleHQ9ICJNZXNzYWdlIHRyYW5zZmVyIGRpcmVjdGlvbjoiPiA8dnNwYWNlIC8+DQpD dXJyZW50IHZlcnNpb24gbGltaXRzIHRoZSBxdWVyeSBtZXNzYWdlIHRyYW5zZmVyIGRpcmVjdGlv biANCiAgICBvbmx5IGZyb20gQ0UgdG8gRkUuPC90Pg0KDQo8dCBoYW5nVGV4dD0gIk1lc3NhZ2Ug SGVhZGVyOiI+IDx2c3BhY2UgLz4NClRoZSBNZXNzYWdlIFR5cGUgaW4gdGhlIGhlYWRlciBpcyBz ZXQgdG8gTWVzc2FnZVR5cGU9ICdRdWVyeScuIA0KICAgIFRoZSBBQ0sgZmxhZyBpbiB0aGUgaGVh ZGVyIFNIT1VMRCBiZSBzZXQgJ0FDS0FsbCcsIG1lYW5pbmcgYSANCiAgICBmdWxsIHJlc3BvbnNl IGZvciBhIHF1ZXJ5IG1lc3NhZ2UgaXMgYWx3YXlzIGV4cGVjdGVkLiBJZiB0aGUgDQogICAgQUNL IGZsYWcgaXMgc2V0IG90aGVyIHZhbHVlcywgdGhlIG1lYW5pbmcgb2YgdGhlIA0KICAgIGZsYWcg d2lsbCB0aGVuIGJlIGlnbm9yZWQsIGFuZCBhIGZ1bGwgcmVzcG9uc2Ugd2lsbCBzdGlsbCBiZSAN CiAgICByZXR1cm5lZCBieSBtZXNzYWdlIHJlY2VpdmVyLjwvdD4NCg0KDQo8dCBoYW5nVGV4dCA9 ICJNZXNzYWdlIGJvZHk6ICI+PHZzcGFjZSAvPg0KVGhlIHF1ZXJ5IG1lc3NhZ2UgYm9keSBjb25z aXN0cyBvZiAoYXQgbGVhc3QpIG9uZSBvciBtb3JlIHRoYW4gDQogICAgb25lIFRMVnMgdGhhdCBk ZXNjcmliZSBlbnRyaWVzIHRvIGJlIHF1ZXJpZWQuIFRoZSBUTFYgaXMgY2FsbGVkIA0KICAgIExG QnNlbGVjdCBUTFYgYW5kIHRoZSBkYXRhIGZvcm1hdCBpcyBhcyBiZWxvdzoNCjwvdD4NCjxmaWd1 cmUgYW5jaG9yPSJtc2dfUXVlcnkiPg0KPGFydHdvcms+DQogDQogICAgICAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgICAgfCAgICAgICAgVHlwZSA9IExGQnNlbGVjdCAgICAgICB8ICAgICAgICAg ICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgTEZCIENsYXNzIElEICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIExGQiBJbnN0YW5jZSBJ RCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgIE9wZXJhdGlvaW4gVExWICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC4NCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfiAgICAgICAgICAgICAgICAgICAg ICAgICAgIC4uLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4NCiAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdGlvaW4gVExWICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgDQogIFR5 cG8gaW4gYWxsIGZpZ3VyZXM6IGNvcnJlY3QgIk9wZXJhdGlvaW4gVExWIg0KICBbV110aGFua3Mu DQogIEdlbmVyYWwgY29tbWVudDogaW4gbWFueSBjYXNlcyB0aGUgc2FtZSB0eXBlIGluIFRMViBp cyB1c2VkIGluIGRpZmZlcmVudCBQTCBtZXNzYWdlcyAoUXVlcnkgdnMgUmVzcG9uc2UsIGV0Yykg YW5kIHRoZW4gdGhlIFYgaXMgZGlmZmVyZW50LiBUaGlzIFdJTEwgYmUgYSBiaWcgc291cmNlIG9m IGltcGxlbWVudGF0aW9uIGJ1Z3MuIEkgdGhpbmsgd2Ugc2hvdWxkIGRlZmluZWQgb3BlcmF0aW9u IFRMVnMgZGlmZmVyZW50bHk6IEdFVCBhbmQgR0VULVJFU1AsIFNFVCBhbmQgU0VULVJFU1AsIFJF UE9SVCBhbmQgUkVQT1JULVJFU1AuDQogIFdoYXQgZG8geW91IHRoaW5rID8NCiAgW1ddSSBhZ3Jl ZSB3ZWxsLiBJIHRob3VnaHQgb2YgdGhpcywganVzdCB0aGlua2luZyB0aGlzIE9wZXJhdGlvbiBU TFYgaXMgcmVhbGx5IGEgdG9waWMgZm9yIG11Y2ggbW9yZSBkaXNjdXNzaW9uLCB0aGVyZWZvcmUg SSBsZWF2ZSBpdCB0aGVyZS4gQW55d2F5LCBsZXQgbWUgdHJ5IHRvIGNoYW5nZSBpdC4gDQoNCiAg ICAgDQo8L2FydHdvcms+DQo8L2ZpZ3VyZT4NCjx2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLz4NCjxs aXN0IHN0eWxlPSAiaGFuZ2luZyIgaGFuZ0luZGVudD0iMTciID4NCjx0IGhhbmdUZXh0ID0gIkVk aXRvcmlhbCBOb3RlOiAiPg0KPC90Pg0KPGxpc3Qgc3R5bGU9Im51bWJlcnMiIGhhbmdJbmRlbnQ9 IjMiPg0KPHQ+VW5kZXIgZGlzY3Vzc2lvbiBpcyB3aGV0aGVyIHRoZXJlIGlzIGEgbmVlZCBmb3Ig ZXhwbGljaXQgbXVsdGlwbGUgTEZCIGluc2F0YW5jZQ0KICAgIGFkZHJlc3NpbmcgaGVyZS4gT25l IHdheSB0byByZWFsaXplIGl0IGlzIHRvIGRlZmluZSBhIHNwZWNpZmljIEluc3RhbmNlIHNlbGVj dA0KICAgIFRMViB0byBzdWJzdGl0dXRlIGFib3ZlICdMRkIgSW5zdGFuY2UgSUQnIGZpZWxkLiBU aGUgVExWIG1heSBoYXZlIGZvbGxvd2luZyBmb3JtYXQ6PC90Pg0KPGZpZ3VyZT48YXJ0d29yaz4N CiAgICAgICAgSU5Tc2VsZWN0VExWIDo9IFR5cGUgTGVuZ3RoIFZhbHVlDQogICAgICAgIFR5cGUg Oj0gSU5Tc2VsZWN0DQogICAgICAgIFZhbHVlIDo9IEluc3RhbmNlSUQgKFJhbmdlTWFyayB8IElu c3RhbmNlIElEKSsNCg0KPC9hcnR3b3JrPjwvZmlndXJlPg0KPHQ+QW4gYXBwbGljYWJsZSBSYW5n ZU1hcmsgaXMgJzB4ZmZmZmZmZmYnLCB0aGUgdmFsdWUgb2Ygd2hpY2ggaXMgdGhlIHNhbWUgYXMg DQogICAgSW5zdGFuY2UgYnJvYWRjYXN0IElELiBCZWNhdXNlIHRoZXJlIHdpbGwgYmUgbm8gYnJv YWRjYXN0IGFkZHJlc3MgYXBwbGllZA0KICAgIGluIHRoaXMgcGxhY2UsIHRoZXJlIHdpbGwgYmUg bm8gd29ycnkgb2YgYW1iaWd1aXR5IGhlcmUuPC90Pg0KPC9saXN0PiAgIA0KPC9saXN0Pg0KPHZz cGFjZSBibGFua0xpbmVzPSIxIiAvPg0KPHQgaGFuZ1RleHQ9ICJPcGVyYXRpb24gVExWIj48dnNw YWNlIC8+DQpUaGUgT3BlcmF0aW9uIFRMViBmb3IgdGhlICdRdWVyeScgbWVzc2FnZSBpcyBmb3Jt YXR0ZWQgYXM6DQo8L3Q+DQo8ZmlndXJlIGFuY2hvcj0idGx2X1F1ZXJ5Ij4NCjxhcnR3b3JrPiAg ICANCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICBUeXBlID0gT3BlcmF0aW9ucyAoR0VUKSAgICB8 ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgIFBhdGgob3IgQXR0cmlidXRlIElEPykgICAgICAgICAgICAg ICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICBR dWVyeSBEYXRhICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiANCiAgDQogIEFnYWluLCBpbiBhbGwgeW91ciBzZWN0aW9ucywgY291bGQgeW91 IGNoYW5nZSAiVHlwZSA9IE9wZXJhdGlvbnMgKEdFVCkiIHRvICJUeXBlID0gR0VUIiBhbmQgc28g b24gPw0KICBbV11hbHNvIGFncmVlIHdlbGwuIGhvcGUgSmFtYWwgd2lsbCBub3Qgb2JqZWN0IHRv IGl0LiBJIHRyeSB0byBjaGFuZ2UgaXQgZmlyc3QuDQoNCjwvYXJ0d29yaz48L2ZpZ3VyZT4NCjx0 IGhhbmdUZXh0PSAiUGF0aChvciBBdHRyaWJ1dGUgSUQ/KTogIj48dnNwYWNlIC8+DQpbVW5kZXIg ZGlzY3Vzc2lvbiBhbmQgVEJEXQ0KPC90Pg0KDQo8dnNwYWNlIGJsYW5rTGluZXMgPSAiMSIgLz4N CjxsaXN0IHN0eWxlPSJoYW5naW5nIiBoYW5nSW5kZW50PSIxNyI+DQo8dCBoYW5nVGV4dCA9ICJF ZGl0b3JpYWwgTm90ZToiPiANClRoZXJlIGlzIGEgZGViYXRlIG9uIHdoZXRoZXIgd2Ugc2hvdWxk IHVzZSBhICdQYXRoJyBvciBzaW1wbHkgYW4gJ0F0dHJpYnV0ZSBJRCcgDQogICAgb3IgYSAnVGFi bGUgSUQnIGhlcmUgYXQgdGhlIHByb3RvY29sIGxheWVyLiBBIFBhdGggaXMgdXNlZCBmb3IgZGF0 YSANCiAgICBpbmRleGluZyBmb3IgYSB0YWJsZSwgd2hpbGUgYW4gJ0F0dHJpYnV0ZSBJRCcgb3Ig YSAnVGFibGUgSUQnIG9ubHkgc3BlY2lmeSANCiAgICB3aGljaCBhdHRyaWJ1dGUgb3IgdGFibGUg dG8gdXNlLCBsZWF2aW5nIHRhYmxlIGluZGV4IHRvIGJlIGluY2x1ZGVkIGluIGZvbGxvd2VkIA0K ICAgIGRhdGEuDQo8L3Q+DQo8L2xpc3Q+DQo8dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8+DQo8dCBo YW5nVGV4dD0gIlF1ZXJ5IERhdGE6ICI+PHZzcGFjZSAvPg0KICAgIFtVbmRlciBkaXNjdXNzaW9u IGFuZCBUQkRdDQo8L3Q+DQo8L2xpc3Q+DQo8dD5UbyBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUgYWJv dmUgUERVIGZvcm1hdCwgd2UgY2FuIHNob3cgYSB0cmVlIHN0cnVjdHVyZSBmb3IgdGhlIA0KICAg IGZvcm1hdCBhcyBiZWxvdzoNCjxmaWd1cmU+DQptYWluIGhkciAodHlwZSA9IFF1ZXJ5KQ0KICAg ICB8DQogICAgIHwNCiAgICAgKy0tLSBUID0gTEZCc2VsZWN0DQogICAgIHwgICAgICAgIHwNCiAg ICAgfCAgICAgICAgKy0tIExGQkNMQVNTSUQgPSB0YXJnZXQgTEZCIGNsYXNzDQogICAgIHwgICAg ICAgIHwNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gTEZCSW5zdGFuY2UgPSB0 YXJnZXQgTEZCIGluc3RhbmNlIA0KICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAgIHwNCiAg ICAgfCAgICAgICAgKy0tIFQgPSBvcGVyYXRpb24geyBHRVQgfQ0KICAgICB8ICAgICAgICB8ICAg fA0KICAgICB8ICAgICAgICB8ICAgKy0tICAvLyBvbmUgb3IgbW9yZSBwYXRoIHRhcmdldHMgDQog ICAgIHwgICAgICAgIHwgICAgICAgIC8vIHVuZGVyIGRpc2N1c3Npb24NCiAgICAgfCAgICAgICAg Ky0tIFQgPSBvcGVyYXRpb24geyBHRVQgfQ0KICAgICB8ICAgICAgICB8ICAgfA0KICAgICB8ICAg ICAgICB8ICAgKy0tICAvLyBvbmUgb3IgbW9yZSBwYXRoIHRhcmdldHMgDQogICAgIHwgICAgICAg IHwgDQoNCjwvZmlndXJlPg0KPC9zZWN0aW9uPg0KDQo8c2VjdGlvbiBhbmNob3I9IlF1ZXJ5UmVz cG9uc2UiIHRpdGxlPSJRdWVyeSBSZXNwb25zZSBNZXNzYWdlIj4NCjx0PldoZW4gcmVjZWl2aW5n IGEgcXVlcnkgbWVzc2FnZSwgdGhlIHJlY2VpdmVyIHNob3VsZCBwcm9jZXNzIHRoZSANCiAgICBt ZXNzYWdlIGFuZCBjb21lIHVwIHdpdGggYSBxdWVyeSByZXN1bHQuIFRoZSByZWNlaXZlciBzZW5k cyB0aGUgDQogICAgcXVlcnkgcmVzdWx0IGJhY2sgdG8gdGhlIG1lc3NhZ2Ugc2VuZGVyIGJ5IHVz ZSBvZiB0aGUgUXVlcnkgDQogICAgUmVzcG9uc2UgTWVzc2FnZS4gVGhlIHF1ZXJ5IHJlc3VsdCBj YW4gYmUgdGhlIGluZm9ybWF0aW9uIA0KICAgIGJlaW5nIHF1ZXJpZWQgaWYgdGhlIHF1ZXJ5IG9w ZXJhdGlvbiBpcyBzdWNjZXNzZnVsLCBvciBjYW4gYWxzbyANCiAgICBiZSBlcnJvciBjb2RlcyBp ZiB0aGUgcXVlcnkgb3BlcmF0aW9uIGZhaWxzLCBpbmRpY2F0aW5nIHRoZSANCiAgICByZWFzb25z IGZvciB0aGUgZmFpbHVyZS48L3Q+DQoNCjx0PkEgcXVlcnkgcmVzcG9uc2UgbWVzc2FnZSBpcyBh bHNvIGNvbXBvc2VkIG9mIGEgY29tbW9uIGhlYWRlciBhbmQgDQogICAgYSBtZXNzYWdlIGJvZHkg Y29uc2lzdHMgb2Ygb25lIG9yIG1vcmUgVExWcyBkZXNjcmliaW5nIHRoZSBxdWVyeSANCiAgICBy ZXN1bHQuIERldGFpbGVkIGRlc2NyaXB0aW9uIG9mIHRoZSBtZXNzYWdlIGlzIGFzIGJlbG93Ljwv dD4NCjx2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLz4NCjxsaXN0IHN0eWxlPSAiaGFuZ2luZyIgaGFu Z0luZGVudD0iNCI+DQo8dCBoYW5nVGV4dD0gIk1lc3NhZ2UgdHJhbnNmZXIgZGlyZWN0aW9uOiAi Pjx2c3BhY2UgLz4NCkN1cnJlbnQgdmVyc2lvbiBsaW1pdHMgdGhlIHF1ZXJ5IHJlc3BvbnNlIG1l c3NhZ2UgdHJhbnNmZXIgZGlyZWN0aW9uIA0KICAgIG9ubHkgZnJvbSBGRSB0byBDRS4NCjwvdD4N CiAgICANCjx0IGhhbmdUZXh0PSAiTWVzc2FnZSBIZWFkZXI6ICAiPjx2c3BhY2UgLz4NClRoZSBN ZXNzYWdlIFR5cGUgaW4gdGhlIGhlYWRlciBpcyBzZXQgdG8gTWVzc2FnZVR5cGU9ICdRdWVyeVJl c3BvbnNlJy4gDQogICAgVGhlIEFDSyBmbGFnIGluIHRoZSBoZWFkZXIgU0hPVUxEIGJlIHNldCAn Tm9BQ0snLCBtZWFuaW5nIG5vIGZ1cnRoZXIgDQogICAgcmVzcG9uc2UgZm9yIGEgcXVlcnkgcmVz cG9uc2UgbWVzc2FnZSBpcyBleHBlY3RlZC4gSWYgdGhlIEFDSyBmbGFnIGlzIA0KICAgIHNldCBv dGhlciB2YWx1ZXMsIHRoZSBtZWFuaW5nIG9mIHRoZSBmbGFnIHdpbGwgdGhlbiBiZSANCiAgICBp Z25vcmVkLiBUaGUgU2VxdWVuY2UgTnVtYmVyIGluIHRoZSBoZWFkZXIgU0hPVUxEIGtlZXAgdGhl IHNhbWUgYXMgDQogICAgdGhhdCBvZiB0aGUgcXVlcnkgbWVzc2FnZSB0byBiZSByZXNwb25kZWQs IHNvIHRoYXQgdGhlIHF1ZXJ5IG1lc3NhZ2UgDQogICAgc2VuZGVyIGNhbiBrZWVwIHRyYWNrIG9m IHRoZSByZXNwb25zZXMuIA0KPC90Pg0KICAgIA0KPHQgaGFuZ1RleHQ9ICJNZXNzYWdlIGJvZHk6 ICI+PHZzcGFjZSAvPg0KVGhlIG1lc3NhZ2UgYm9keSBmb3IgYSBxdWVyeSByZXNwb25zZSBtZXNz YWdlIGNvbnNpc3RzIG9mIChhdCBsZWFzdCkgDQogICAgb25lIG9yIG1vcmUgdGhhbiBvbmUgVExW cyB0aGF0IGRlc2NyaWJlIHF1ZXJ5IHJlc3VsdHMgZm9yIGluZGl2aWR1YWwgDQogICAgcXVlcmll ZCBlbnRyaWVzLiBUaGUgVExWIGlzIGFsc28gY2FsbGVkIExGQnNlbGVjdCBUTFYsIGFuZCBoYXMg ZXhhY3RseSANCiAgICB0aGUgc2FtZSBkYXRhIGZvcm1hdCBhcyBxdWVyeSBtZXNzYWdlLCBleGNl cHQgdGhlIE9wZXJhdGlvbiBUTFYgaW5zaWRlDQogICAgdGhlIFRMViBjb21wcmlzZXMgdGhlICdR dWVyeSBSZXNwb25zZSBEYXRhJywgaW5zdGVhZCBvZiB0aGUgJ1F1ZXJ5IERhdGEnLA0KICAgIGFz IGJlbG93Og0KPC90Pg0KDQo8ZmlndXJlIGFuY2hvcj0ibXNnX1F1ZXJ5X1Jlc3BvbnNlIj4NCjxh cnR3b3JrPg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgIFR5cGUgPSBPcGVyYXRpb25zIChHRVQp ICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgUGF0aChvciBBdHRyaWJ1dGUgSUQ/KSAgICAgICAg ICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg IFF1ZXJ5IFJlc3BvbnNlIERhdGEgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4N CiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCjwvYXJ0d29yaz4NCjwvZmlndXJlPg0KICANCiAgWW91IHNob3VsZCBz cGVjaWZ5IGhlcmUgdGhhdCB0aGUgb3JkZXIgb2YgdGhlIFRMViBpbiB0aGUgUXVlcnktUmVwb25z ZSBtYXRjaGVzIHRoZSBUTFZzIGluIHRoZSBRdWVyeS4gU28gdGhlcmUgaXMgYWx3YXlzIHRoZSBz YW1lIG51bWJlciBvZiBUTFZzIGluIHRoZSByZXNwb25zZSBhcyBpbiB0aGUgcXVlcnkuDQogIE9L Lg0KICBTaWRlIG5vdGU6IHdlIGhhdmUgbm90IHlldCByZXNvbHZlZCB0aGUgdXNlIG9mIGEgdHJh bnNhY3Rpb24gb3Igc2VxdWVuY2UgbnVtYmVyIHRoYXQgd2lsbCBiZSB1c2VkIGZvciBlYWNoIFBM IG1lc3NhZ2UuDQoNCg0KIA0KPHQgaGFuZ1RleHQ9ICJRdWVyeSBSZXNwb25zZSBEYXRhOiAiPjx2 c3BhY2UgLz4NCltVbmRlciBkaXNjdXNzaW9uIGFuZCBUQkRdDQo8L3Q+DQo8L2xpc3Q+DQogICAg DQo8L3NlY3Rpb24+DQo8L3NlY3Rpb24+DQoNCjwhLS0gJExvZzogUXVlcnlNc2cueG1sLHYgJA0K PCEtLSBSZXdyaXR0ZW4gYnkgV2VpbWluZyBXYW5nIDIwMDQvMTAvMjINCjwhLS0gSW5jb3JwYXJh dGUgTEZCc2VsZWN0IGFuZCBPcGVyYXRpb24gVExWIA0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAxLjEw ICAyMDA0LzEwLzIwIDE0OjQ5OjM2ICBhdnJpDQo8IS0tIENoYW5nZXMgZm9yIGRyYWZ0LWlldGYt Zm9yY2VzLXByb3RvY29sLTAwDQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuOSAgMjAwNC8wNy8xOSAw OTozNzoyMiAgYXZyaQ0KPCEtLSBWZXJzaW9uIDIgY2hlY2tpbg0KPCEtLQ0KPCEtLSBSZXZpc2lv biAxLjggIDIwMDQvMDYvMjMgMDU6MDU6NDcgIGF2cmkNCjwhLS0gZmluYWwgZWRpdHMgZm9yIDAw DQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuNyAgMjAwNC8wNi8yMiAwNjo1NDoxNyAgYXZyaQ0KPCEt LSBSZW1vdmUNCjwhLS0NCjwhLS0gUmV2aXNpb24gMS42ICAyMDA0LzA2LzIyIDA2OjUyOjMzICBh dnJpDQo8IS0tIEluY29ycG9yYXRlIFdXIGNoYW5nZXMNCjwhLS0gSW5jbHVkZSB0ZWFtIGVkaXRz IG9uIDAwLTcNCjwhLS0NCjwhLS0gUmV2aXNpb24gMS4yICAyMDA0LTA2LTIxIDIxOjQwOjI1KzA4 ICBhZG1pbmlzdHJhdG9yDQo8IS0tIEluY29ycGFyYXRlIHNvbWUgY29tbWVudHMgZnJvbSBKYW1h bCAoSnVuZSAyMSwgMjAwNCAxMDo1MCBBTSkuIC1XZWltaW5nDQo8IS0tDQo8IS0tIFJldmlzaW9u IDEuMSAgMjAwNC0wNi0yMSAyMDozNjo0MCswOCAgYWRtaW5pc3RyYXRvcg0KPCEtLSByZXZpc2lv biBoYW5kZWQgZnJvbSBBdnJpDQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuNSAgMjAwNC8wNi8xOSAx MzoxMjozMyAgYXZyaQ0KPCEtLSBmb3JtYXR0aW5nDQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuNCAg MjAwNC8wNi8xOSAxMzowMzowMyAgYXZyaQ0KPCEtLSBmaXggY3Jvc3MgcmVmZXJlbmNlDQo8IS0t DQo8IS0tIFJldmlzaW9uIDEuMyAgMjAwNC8wNi8xOSAxMjoyMToxMSAgYXZyaQ0KPCEtLSAtIGNo YW5nZSBFbmNvZGluZ1R5cGUgdG8gVHlwZSAoZnJvbSBXVykNCjwhLS0gLSBmaXggZm9ybWF0aW5n DQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuMiAgMjAwNC8wNi8xNyAwMzo0Mzo0NyAgYXZyaQ0KPCEt LSBSZXBsYWNlIHdpdGggbmV3IFdXIGZpbGVzDQo8IS0tDQogICAgZWRpdGVkIHdpdGggPE9YeWdl bi8+WE1MIGVkaXRvciA0LjEsIGJ5IFdlaW1pbmcgV2FuZyAmTGlnYW5nIERvbmcgDQogICAgICoq KiBRdWVyeU1zZyBWMS4wLCAyMDA0LTA2LTEzLCBjaGFuZ2VzIHNpbmNlIGxhc3QgdmVyc2lvbjoN CiAgICAgLSBOb25lLCBhcyB0aGUgb3JpZ2luYWwgdmVyc2lvbi4NCi0tPg0KICANCjw/eG1sIHZl cnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DQo8IS0tIGVkaXRlZCB3aXRoIDxPWHlnZW4v PlhNTCBlZGl0b3IgNC4xLCBieSBXZWltaW5nIFdhbmcgJkxpZ2FuZyBEb25nIA0KICAgICAqKiog RXZlbnRNc2cgVjEuMCwgMjAwNC0wNi0xMywgY2hhbmdlcyBzaW5jZSBsYXN0IHZlcnNpb246DQog ICAgIC0gTm9uZSwgYXMgdGhlIG9yaWdpbmFsIHZlcnNpb24uDQogICAgICoqKiBFdmVudE1zZ1Yx LjEsIDIwMDQtMDYtMTg6DQogICAgIC0gY2hhbmdlIEVuY29kaW5nVHlwZSB0byBUeXBlLg0KLS0+ DQoNCjxzZWN0aW9uIGFuY2hvcj0iRXZlbnRNc2ciIHRpdGxlPSJFdmVudCBOb3RpZmljYXRpb24g YW5kIFJlc3BvbnNlIE1lc3NhZ2VzIj4NCg0KPHQ+VGhlIEV2ZW50IE5vdGlmaWNhdGlvbiBNZXNz YWdlIGlzIHVzZWQgZm9yIG9uZSBGb3JDRVMgZWxlbWVudCANCiAgICB0byBhc3luY2hyb25vdXNs eSBub3RpZnkgb25lIG9yIG1vcmUgb3RoZXIgRm9yQ0VTIGVsZW1lbnRzIA0KICAgIGluIHRoZSBz YW1lIEZvckNFUyBORSBvbiBqdXN0IGhhcHBlbmVkIGV2ZW50cyBpbiBpdC4gVGhlIA0KICAgIEV2 ZW50IE5vdGlmaWNhdGlvbiBSZXNwb25zZSBNZXNzYWdlIGlzIHVzZWQgZm9yIHRoZSByZWNlaXZl ciANCiAgICBvZiB0aGUgRXZlbnQgTm90aWZpY2F0aW9uIE1lc3NhZ2UgdG8gYWNrbm93bGVkZ2Ug dGhlIHJlY2VwdGlvbiANCiAgICBvZiB0aGUgZXZlbnQgbm90aWZpY2F0aW9uLjwvdD4NCg0KPHQ+ RXZlbnRzIGluIGN1cnJlbnQgRm9yQ0VTIHByb3RvY29sIGNhbiBiZSBjYXRlZ29yaXplZCBpbnRv IGZvbGxvd2luZyB0eXBlczo8L3Q+DQo8dD48bGlzdCBzdHlsZT0ic3ltYm9scyI+DQo8dD5FdmVu dHMgaGFwcGVuZWQgaW4gQ0U8L3Q+DQo8dD5FdmVudHMgaGFwcGVuZWQgaW4gRkU8L3Q+DQogIA0K ICBXaHkgZG9lcyB0aGlzIG1hdHRlciBmb3IgdGhlIHByb3RvY29sID8NCiAgW1ddIHllcywgaXQg bWF0dGVycy4gYWN0dWFsbHkgSSBzdGlsbCBoYXZlIG5vdCBkZWZpbmVkIHRoZSBtZXNzYWdlIGZv cm1hdCBmb3IgQ0UgZXZlbnRzLiBJJ20gc3VyZSB0aGUgZGVmaW5pdGlvbiBzaG91bGQgYmUgZGlm ZmVyZW50IGZvciB0aGUgTEZCcy4NCiAgSWYgdGhlIENFLUxGQiB0aG91Z2h0IGNhbiBwcm9jZWVk IG1vcmUsIGl0IHdpbGwgaGVscCB0aGUgZGVmaW5pdGlvbiBoZXJlLg0KDQo8L2xpc3Q+PC90Pg0K DQo8dD5FdmVudHMgY2FuIGFsc28gYmUgY2F0ZWdvcml6ZWQgaW50byB0d28gY2xhc3NlcyBhY2Nv cmRpbmcgdG8gDQogICAgd2hldGhlciB0aGV5IG5lZWQgc3Vic2NyaXB0aW9uIG9yIG5vdC4gQW4g ZXZlbnQgaW4gb25lIEZvckNFUyANCiAgICBlbGVtZW50IHRoYXQgbmVlZHMgdG8gYmUgc3Vic2Ny aWJlZCB3aWxsIHNlbmQgbm90aWZpY2F0aW9ucyB0byANCiAgICBvdGhlciBGb3JDRVMgZWxlbWVu dHMgb25seSB3aGVuIHRoZSBvdGhlciBlbGVtZW50cyBoYXZlIHN1YnNjcmliZWQgDQogICAgdG8g dGhlIGVsZW1lbnQgZm9yIHRoZSBldmVudCBub3RpZmljYXRpb24uIEhvdyB0byANCiAgICBzdWJz Y3JpYmUvdW5zdWJzY3JpYmUgZm9yIGFuIGV2ZW50IGlzIGRlc2NyaWJlZCBpbiB0aGUgQ29uZmln dXJlIA0KICAgIE1lc3NhZ2UgaW4gU2VjdGlvbiA2LjMuIEFuIGV2ZW50IHRoYXQgbmVlZHMgbm90 IHRvIGJlIHN1YnNjcmliZWQgDQogICAgd2lsbCBhbHdheXMgc2VuZCBub3RpZmljYXRpb25zIHRv IG90aGVyIEZvckNFUyBlbGVtZW50cyB3aGVuIHRoZSANCiAgICBldmVudCBoYXBwZW5zLiBBbiBl dmVudCBkZWZpbml0aW9uIG1hZGUgYnkgRm9yQ0VTIHByb3RvY29sLCBGb3JDRVMgDQogICAgRkUg bW9kZWwsIG9yIGJ5IHZlbmRvcnMgd2lsbCBzdGF0ZSBpZiB0aGUgZXZlbnQgbmVlZHMgc3Vic2Ny aXB0aW9uIG9yIG5vdC48L3Q+DQo8dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8+DQo8bGlzdCBzdHls ZT0iaGFuZ2luZyIgaGFuZ0luZGVudD0iMTciID4NCjx0IGhhbmdUZXh0PSJFZGl0b3JpYWwgTm90 ZTogIiA+DQpUaGVyZSBpcyBhbiBhcmd1bWVudCB0aGF0IGl0IGlzIHByZWZlcmFibGUgdG8gaGF2 ZSANCmFsbCBldmVudHMgc3Vic2NyaWJhYmxlLg0KPC90Pg0KPC9saXN0Pg0KDQoNCjxzZWN0aW9u IHRpdGxlPSJFdmVudCBOb3RpZmljYXRpb24gTWVzc2FnZSI+DQoNCjx0PkFzIHVzdWFsLCBhbiBF dmVudCBOb3RpZmljYXRpb24gTWVzc2FnZSBpcyBjb21wb3NlZCBvZiBhIGNvbW1vbiANCiAgICBo ZWFkZXIgYW5kIGEgbWVzc2FnZSBib2R5IHRoYXQgY29uc2lzdHMgb2Ygb25lIG9yIG1vcmUgVExW IGRhdGEgDQogICAgZm9ybWF0LiBEZXRhaWxlZCBkZXNjcmlwdGlvbiBvZiB0aGUgbWVzc2FnZSBp cyBhcyBiZWxvdy48L3Q+DQo8bGlzdCBzdHlsZT0iaGFuZ2luZyIgaGFuZ0luZGVudD0iMSI+DQo8 dCBoYW5nVGV4dD0gIk1lc3NhZ2UgVHJhbnNmZXIgRGlyZWN0aW9uOiAgIj48dnNwYWNlIC8+DQpG RSB0byBDRSwgb3IgQ0UgdG8gRkUNCjwvdD4NCg0KDQo8dCBoYW5nVGV4dD0gIk1lc3NhZ2UgSGVh ZGVyOiAgIj48dnNwYWNlIC8+DQpUaGUgTWVzc2FnZSBUeXBlIGluIHRoZSBtZXNzYWdlIGhlYWRl ciBpcyBzZXQgdG8gPHZzcGFjZSAvPg0KICAgIE1lc3NhZ2VUeXBlID0gJ0V2ZW50Tm90aWZpY2F0 aW9uJy4gVGhlIEFDSyBmbGFnIGluIHRoZSBoZWFkZXIgDQogICAgY2FuIGJlIHNldCBhczogQUNL IGZsYWcgPSdOb0FDSyd8J1N1Y2Nlc3NBY2snfCdVbnN1Y2Nlc3NBQ0snfCdBQ0tBbGwnLiANCiAg ICBOb3RlIHRoYXQgdGhlICdTdWNjZXNzJyBoZXJlIG9ubHkgbWVhbnMgdGhlIHJlY2VpdmVyIG9m IHRoZSBtZXNzYWdlIA0KICAgIGhhcyBzdWNjZXNzZnVsbHkgcmVjZWl2ZWQgdGhlIG1lc3NhZ2Uu DQo8L3Q+DQoNCg0KPHQgaGFuZ1RleHQ9ICJNZXNzYWdlIEJvZHk6ICI+PHZzcGFjZSAvPg0KVGhl IG1lc3NhZ2UgYm9keSBmb3IgYW4gZXZlbnQgbm90aWZpY2F0aW9uIG1lc3NhZ2UgY29uc2lzdHMg DQogICAgb2YgKGF0IGxlYXN0KSBvbmUgb3IgbW9yZSB0aGFuIG9uZSBUTFZzIHRoYXQgZGVzY3Jp YmUgdGhlIA0KICAgIG5vdGlmaWVkIGV2ZW50cy4gVGhlIFRMViBpcyBkZWZpbmVkIGFzIGZvbGxv d3M6DQo8dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8+DQo8L3Q+DQoNCjxmaWd1cmUgYW5jaG9yPSJ0 bHZfRXZlbnRfTm90aWZpY2F0aW9uIj4NCjxhcnR3b3JrPg0KICAgICAgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICAgIHwgICAgICAgIFR5cGUgPSBMRkJzZWxlY3QgICAgICAgfCAgICAgICAgICAg ICAgIExlbmd0aCAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgIExGQiBDbGFzcyBJRCAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBMRkIgSW5zdGFuY2UgSUQg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICBPcGVyYXRpb2luIFRMViAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAuDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIH4gICAgICAgICAgICAgICAgICAgICAg ICAgICAuLi4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+DQogICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBPcGVyYXRpb2luIFRMViAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQogICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogDQo8L2FydHdv cms+PC9maWd1cmU+DQoNCjx0IGhhbmdUZXh0PSAiT3BlcmF0aW9uIFRMVjogIj48dnNwYWNlIC8+ DQpUaGlzIGlzIGEgVExWIHRoYXQgZGVzY3JpYmVzIHRoZSBldmVudCB0byBiZSBub3RpZmllZCwg YXMgZm9sbG93czoNCjwvdD4NCg0KPGZpZ3VyZSBhbmNob3I9InRsdl9FdmVudCI+PGFydHdvcms+ DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogICAgIHwgICAgVHlwZSA9IE9wZXJhdGlvbnMgKFJFUE9SVCkgfCAg ICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICBQYXRoKG9yIEV2ZW50IElEPykgICAgICAgICAgICAgICAgICAg ICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgRXZl bnQgRGF0YSAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgIC4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQogICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQo8L2FydHdvcms+PC9maWd1cmU+DQo8dCBoYW5nVGV4dD0gIlBhdGgob3IgRXZlbnQg SUQpOiAiPjx2c3BhY2UgLz4NCltVbmRlciBkaXNjdXNzaW9uIGFuZCBUQkRdDQo8L3Q+DQoNCjx0 IGhhbmdUZXh0PSAiRXZlbnQgRGF0YTogIj48dnNwYWNlIC8+DQogICAgW1VuZGVyIGRpc2N1c3Np b24gYW5kIFRCRF0NCjwvdD4NCjwvbGlzdD4NCjx0PlRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSBh Ym92ZSBQRFUgZm9ybWF0LCB3ZSBjYW4gc2hvdyBhIHRyZWUgc3RydWN0dXJlIGZvciB0aGUgDQog ICAgZm9ybWF0IGFzIGJlbG93Og0KPGZpZ3VyZT4NCm1haW4gaGRyICh0eXBlID0gRXZlbnQgTm90 aWZpY2F0aW9uKQ0KICAgICB8DQogICAgIHwNCiAgICAgKy0tLSBUID0gTEZCc2VsZWN0DQogICAg IHwgICAgICAgIHwNCiAgICAgfCAgICAgICAgKy0tIExGQkNMQVNTSUQgPSB0YXJnZXQgTEZCIGNs YXNzDQogICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0g TEZCSW5zdGFuY2UgPSB0YXJnZXQgTEZCIGluc3RhbmNlIA0KICAgICB8ICAgICAgICB8DQogICAg IHwgICAgICAgIHwNCiAgICAgfCAgICAgICAgKy0tIFQgPSBvcGVyYXRpb24geyBSRVBPUlQgfQ0K ICAgICB8ICAgICAgICB8ICAgfA0KICAgICB8ICAgICAgICB8ICAgKy0tICAvLyBvbmUgb3IgbW9y ZSBwYXRoIHRhcmdldHMgDQogICAgIHwgICAgICAgIHwgICAgICAgIC8vIHVuZGVyIGRpc2N1c3Np b24NCiAgICAgfCAgICAgICAgKy0tIFQgPSBvcGVyYXRpb24geyBSRVBPUlQgfQ0KICAgICB8ICAg ICAgICB8ICAgfA0KICAgICB8ICAgICAgICB8ICAgKy0tICAvLyBvbmUgb3IgbW9yZSBwYXRoIHRh cmdldHMgDQogICAgIHwgICAgICAgIHwgDQoNCjwvZmlndXJlPg0KPC9saXN0Pg0KPC9zZWN0aW9u Pg0KDQo8c2VjdGlvbiB0aXRsZT0iRXZlbnQgTm90aWZpY2F0aW9uIFJlc3BvbnNlIE1lc3NhZ2Ui Pg0KDQo8dD5BZnRlciBzZW5kaW5nIG91dCBhbiBFdmVudCBOb3RpZmljYXRpb24gTWVzc2FnZSwg dGhlIHNlbmRlciBtYXkgDQogICAgYmUgaW50ZXJlc3RlZCBpbiBlbnN1cmluZyB0aGF0IHRoZSBt ZXNzYWdlIGhhcyBiZWVuIHJlY2VpdmVkIA0KICAgIGJ5IHJlY2VpdmVycywgZXNwZWNpYWxseSB3 aGVuIHRoZSBzZW5kZXIgdGhpbmtzIHRoZSBldmVudCANCiAgICBub3RpZmljYXRpb24gaXMgdml0 YWwgZm9yIHN5c3RlbSBtYW5hZ2VtZW50LiBBbiBFdmVudCANCiAgICBOb3RpZmljYXRpb24gUmVz cG9uc2UgTWVzc2FnZSBpcyB1c2VkIGZvciB0aGlzIHB1cnBvc2UuIFRoZSANCiAgICBBQ0sgZmxh ZyBpbiB0aGUgRXZlbnQgTm90aWZpY2F0aW9uIE1lc3NhZ2UgaGVhZGVyIGFyZSB1c2VkIHRvIA0K ICAgIHNpZ25hbCBpZiBzdWNoIGFja25vd2xlZGdlIGlzIHJlcXVlc3RlZCBvciBub3QgYnkgdGhl IHNlbmRlci48L3Q+IA0KDQo8dD5EZXRhaWxlZCBkZXNjcmlwdGlvbiBvZiB0aGUgbWVzc2FnZSBp cyBhcyBiZWxvdzo8L3Q+DQo8bGlzdCBzdHlsZT0iaGFuZ2luZyIgaGFuZ0luZGVudD0iMSI+DQo8 dCBoYW5nVGV4dD0gIk1lc3NhZ2UgVHJhbnNmZXIgRGlyZWN0aW9uOiAgIj48dnNwYWNlIC8+DQo+ RnJvbSBGRSB0byBDRSBvciBmcm9tIENFIHRvIEZFLCBqdXN0IGludmVyc2UgdG8gdGhlIA0KICAg IGRpcmVjdGlvbiBvZiB0aGUgRXZlbnQgTm90aWZpY2F0aW9uIE1lc3NhZ2UgdGhhdCBpdCByZXNw b25zZXMuDQo8L3Q+DQoNCg0KPHQgaGFuZ1RleHQ9ICJNZXNzYWdlIEhlYWRlcjogICI+PHZzcGFj ZSAvPg0KVGhlIE1lc3NhZ2UgVHlwZSBpbiB0aGUgaGVhZGVyIGlzIHNldCANCiAgICBNZXNzYWdl VHlwZT0gJ0V2ZW50Tm90aWZpY2F0aW9uUmVzcG9uc2UnLiBUaGUgQUNLIGZsYWcgaW4gdGhlIA0K ICAgIGhlYWRlciBTSE9VTEQgYmUgc2V0ICdOb0FDSycsIG1lYW5pbmcgbm8gZnVydGhlciByZXNw b25zZSBmb3IgDQogICAgdGhlIG1lc3NhZ2UgaXMgZXhwZWN0ZWQuIElmIHRoZSBBQ0sgZmxhZyBp cyBzZXQgb3RoZXIgdmFsdWVzLCANCiAgICB0aGUgbWVhbmluZyBvZiB0aGUgZmxhZyB3aWxsIHRo ZW4gYmUgaWdub3JlZC4gDQogICAgVGhlIFNlcXVlbmNlIE51bWJlciBpbiB0aGUgaGVhZGVyIFNI T1VMRCBrZWVwIHRoZSBzYW1lIGFzIHRoYXQgDQogICAgb2YgdGhlIG1lc3NhZ2UgdG8gYmUgcmVz cG9uZGVkLCBzbyB0aGF0IHRoZSBldmVudCBub3RpZmljYXRpbiANCiAgICBtZXNzYWdlIHNlbmRl ciBjYW4ga2VlcCB0cmFjayBvZiB0aGUgcmVzcG9uc2VzLg0KPC90Pg0KDQo8dCBoYW5nVGV4dD0g Ik1lc3NhZ2UgQm9keTogIj48dnNwYWNlIC8+DQpUaGUgbWVzc2FnZSBib2R5IGZvciBhbiBldmVu dCBub3RpZmljYXRpb24gbWVzc2FnZSBjb25zaXN0cyANCiAgDQogIGNvcnJlY3QgYWJvdmU6IGV2 ZW50IG5vdGlmaWNhdGlvbiAicmVzcG9uc2UiIG1lc3NhZ2UNCg0KICAgIG9mIChhdCBsZWFzdCkg b25lIG9yIG1vcmUgdGhhbiBvbmUgVExWcyB0aGF0IGRlc2NyaWJlIHRoZSANCiAgICBub3RpZmll ZCBldmVudHMuIFRoZSBUTFYgaXMgYWxzbyBjYWxsZWQgTEZCc2VsZWN0IFRMViwgYW5kIGhhcyBl eGFjdGx5IA0KICAgIHRoZSBzYW1lIGRhdGEgZm9ybWF0IGFzIEV2ZW50IE5vdGlmaWNhdGlvbiBN ZXNzYWdlLCBleGNlcHQgdGhlIE9wZXJhdGlvbiANCiAgICBUTFYgaW5zaWRlIHRoZSBUTFYgY29t cHJpc2VzIHRoZSBldmVudCByZXNwb25zZSBkYXRhLCBpbnN0ZWFkIG9mIHRoZSANCiAgICAnRXZl bnQgRGF0YScsIGFzIGJlbG93Og0KICANCiAgQWdhaW4sIHlvdSBzaG91bGQgbWVudGlvbiB0aGF0 IHRoZSBlYWNoICJPcGVyYXRpb24gVExWIiBpbiB0aGUgcmVzcG9uc2UgY29ycmVzcG9uZHMgb25l LXRvLW9uZSB0byBhIFRMViBpbiB0aGUgbm90aWZpY2F0aW9uLg0KDQo8dnNwYWNlIGJsYW5rTGlu ZXM9IjEiIC8+DQoNCjxmaWd1cmUgYW5jaG9yPSJ0bHZfUmVwc29uc2VfUmVzdWx0Ij4NCjxwcmVh bWJsZT4NClRoaXMgY29udGFpbnMgYSBUTFYgdGhhdCBkZXNjcmliZSB0aGUgcmVzcG9uc2UgcmVz dWx0IA0KICAgIGFzIGJlbG93Og0KPC9wcmVhbWJsZT4NCjxhcnR3b3JrPg0KICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgICB8ICAgIFR5cGUgPSBPcGVyYXRpb25zIChSRVBPUlQpIHwgICAgICAgICAgICAgICBM ZW5ndGggICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgUGF0aChvciBFdmVudCBJRD8pICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICAgICB8ICAgIFJlc3VsdCAgICAgfCAgIFJlYXNvbiAgICAgIHwgICAgICAgICBDb2Rl ICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQo8L2FydHdvcms+PC9maWd1cmU+ DQo8dCBoYW5nVGV4dD0gIlBhdGgob3IgRXZlbnQgSUQ/KTogIj48dnNwYWNlIC8+DQpbVW5kZXIg ZGlzY3Vzc2lvbiBhbmQgVEJEXQ0KPC90Pg0KPHQgaGFuZ1RleHQ9ICJSZXN1bHQ6ICI+PHZzcGFj ZSAvPg0KVGhpcyBkZXNjcmliZXMgdGhlIHJlY2VwdGlvbiByZXN1bHQgb2YgdGhlIGV2ZW50IG5v dGlmaWNhdGlvbiANCiAgICBtZXNzYWdlIGFzIGJlbG93Og0KPC90Pg0KPGZpZ3VyZT48YXJ0d29y az4NCglSZXN1bHQgVmFsdWUgICAgICAgICAgICAgTWVhbmluZw0KCSdTdWNjZXNzJyAgICAgICBU aGUgZXZlbnQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHJlY2VpdmVkLg0KCSdVbnN1Y2Nlc3MnICAg ICBUaGUgZXZlbnQgaGFzIG5vdCBiZWVuIHN1Y2Nlc3NmdWxseSByZWNlaXZlZC4NCjwvYXJ0d29y az48L2ZpZ3VyZT4NCg0KPHQgaGFuZ1RleHQ9ICJSZWFzb24sIENvZGU6ICI+PHZzcGFjZSAvPg0K VGhpcyBkZXNjcmliZXMgdGhlIHJlYXNvbiBhbmQgcG9zc2libGUgZXJyb3IgY29kZSB3aGVuIA0K ICAgIHRoZSBtZXNzYWdlIGlzIG5vdCBzdWNjZXNzZnVsbHkgcmVjZWl2ZWQuIE5vdGUgdGhhdCBv bmx5IHRoZSANCiAgICBmYWlsdXJlIGF0IHRoZSBwcm90b2NvbCBsYXllciByYXRoZXIgdGhhbiB0 aGUgdHJhbnNwb3J0IGxheWVyIA0KICAgIGNhbiBiZSBhbGxvY2F0ZWQgaGVyZSwNCiAgdHlwbzog bm90ICJhbGxvY2F0ZWQiIGJ1dCAiaGFuZGxlZCIuDQoNCiB0aGF0IGlzLCBpZiBldmVuIHRoZSBo ZWFkZXIgcGFydCBvZiB0aGUgDQogICAgbWVzc2FnZSB0byBiZSByZXNwb25kZWQgY2FuIG5vdCBi ZSBjb3JyZWN0bHkgcmVjZWl2ZWQsIHRoZSANCiAgICByZXNwb25zZSB0byB0aGUgbWVzc2FnZSB3 aWxsIG5vdCBiZSBhYmxlIHRvIGJlIGdlbmVyYXRlZCBieSANCiAgICB0aGUgcmVjZWl2ZXIuDQo8 L3Q+DQo8dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8+DQo8bGlzdCBzdHlsZT0iaGFuZ2luZyIgaGFu Z0luZGVudD0iMTciPg0KPHQgaGFuZ1RleHQ9IkVkaXRvcmlhbCBOb3RlOiAiPiANClRoZXJlIGlz IGEgZGViYXRlIG9uIHdoZXRoZXIgdGhlIEV2ZW50IE5vdGlmaWNhdGlvbiANCiAgICBSZXNwb25z ZSBNZXNzYWdlIGlzIG5lY2Vzc2FyeSBvciBub3QuIFRoZSBwcm8gZm9yIGl0IGlzIHNvbWUgZXZl bnQgDQogICAgbm90aWZpY2F0aW9uIHNlbmRlcnMgbWF5IGJlIGludGVyZXN0ZWQgaW4ga25vd2lu ZyBpZiByZWNlaXZlcnMgDQogICAgaGF2ZSBoYWQgc3VjY2Vzcy91bnN1Y2Nlc3MgcmVjZXB0aW9u cyBvZiB0aGUgZXZlbnRzIG9yIG5vdC4gQW4gDQogICAgYWx0ZXJuYXRpdmUgdG8gZ2VuZXJhdGUg c3VjaCByZXNwb25zZSBpcyBmb3IgdGhlIHByb3RvY29sIHRvIA0KICAgIGRlZmluZSBhIHVuaXZl cnNhbCBBQ0sgbWVzc2FnZSBzbyB0aGF0IGl0IGNhbiBhY3QgYXMgcmVzcG9uc2VzIA0KICAgIGZv ciBhbnkgdHlwZXMgb2YgbWVzc2FnZXMgYXMgd2VsbCBhcyB0aGUgZXZlbnQgbm90aWZpY2F0aW9u IA0KICAgIG1lc3NhZ2VzLCB3aGVuIHRoZSBtZXNzYWdlIHNlbmRlcnMgYXJlIGludGVyZXN0ZWQg aW4ga25vd2luZyANCiAgICB3aGV0aGVyIHRoZSBtZXNzYWdlcyBoYXZlIGJlZW4gc3VjY2Vzc2Z1 bGx5IHJlY2VpdmVkIG9yIG5vdCANCiAgICAoZGlmZmVyZW50IGZyb20gdGhlIHJlc3BvbnNlcyBm b3IgdGhlIG1lc3NhZ2UgcHJvY2Vzc2luZyByZXN1bHRzKS4NCjwvdD4gDQo8L2xpc3Q+DQo8L2xp c3Q+DQo8L3NlY3Rpb24+DQo8L3NlY3Rpb24+DQoNCjwhLS0gJExvZzogRXZlbnRNc2cueG1sLHYg JA0KPCEtLSBSZXdyaXR0ZW4gYnkgV2VpbWluZyBXYW5nIDIwMDQvMTAvMjINCjwhLS0gSW5jb3Jw YXJhdGUgTEZCc2VsZWN0IGFuZCBPcGVyYXRpb24gVExWIA0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAx LjcgIDIwMDQvMDcvMTkgMDk6Mzg6MTYgIGF2cmkNCjwhLS0gVmVyc2lvbiAyIGNoZWNraW4NCjwh LS0NCjwhLS0gUmV2aXNpb24gMS42ICAyMDA0LzA2LzIzIDA1OjA1OjIwICBhdnJpDQo8IS0tIGZp bmFsIGVkaXQgZm9yIDAwDQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuNSAgMjAwNC8wNi8yMiAwNjo1 OToyMyAgYXZyaQ0KPCEtLSByZW1vdmUNCjwhLS0NCjwhLS0gUmV2aXNpb24gMS40ICAyMDA0LzA2 LzIyIDA2OjU4OjI1ICBhdnJpDQo8IS0tIFRlYW0gZWRpdHMgZnJvbSAwMC03DQo8IS0tDQo8IS0t IFJldmlzaW9uIDEuMiAgMjAwNC0wNi0yMSAyMTo0MDo1OCswOCAgYWRtaW5pc3RyYXRvcg0KPCEt LSBJbmNvcnBhcmF0ZSBzb21lIGNvbW1lbnRzIGZyb20gSmFtYWwgKEp1bmUgMjEsIDIwMDQgMTA6 NTAgQU0pLiAtV2VpbWluZw0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAxLjEgIDIwMDQtMDYtMjEgMjE6 MDc6NTQrMDggIGFkbWluaXN0cmF0b3INCjwhLS0gUmV2aXNpb24gaGFuZGVkIGZyb20gQXZyaSAg LSBXZWltaW5nDQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuMyAgMjAwNC8wNi8xOSAxMzoxMzozMCAg YXZyaQ0KPCEtLSBGb3JtYXR0aW5nDQo8IS0tDQo8IS0tIFJldmlzaW9uIDEuMiAgMjAwNC8wNi8x OSAxMjoyOTo1MiAgYXZyaQ0KPCEtLSAtIGNoYW5nZSBFbmNvZGluZ1R5cGUgdG8gVHlwZS4gKGZy b20gV1cpDQo8IS0tIEZpY2UgZm9ybWF0dGluZw0KPCEtLQ0KPCEtLSBSZXZpc2lvbiAxLjEgIDIw MDQvMDYvMTcgMDM6NDU6MDIgIGF2cmkNCjwhLS0gSW5pdGlhbCByZXZpc2lvbg0KPCEtLQ0KICAg ICBlZGl0ZWQgd2l0aCA8T1h5Z2VuLz5YTUwgZWRpdG9yIDQuMSwgYnkgV2VpbWluZyBXYW5nICZM aWdhbmcgRG9uZw0KICAgICAqKiogRXZlbnRNc2cgVjEuMCwgMjAwNC0wNi0xMywgY2hhbmdlcyBz aW5jZSBsYXN0IHZlcnNpb246DQogICAgIC0gTm9uZSwgYXMgdGhlIG9yaWdpbmFsIHZlcnNpb24u DQotLT4NCiAgDQoNCg0KLS0gDQpSb2JlcnQgSGFhcw0KSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJv cmF0b3J5DQpT5HVtZXJzdHJhc3NlIDQNCkNILTg4MDMgUvxzY2hsaWtvbi9Td2l0emVybGFuZA0K cGhvbmUgKzQxLTEtNzI0LTg2OTggIGZheCArNDEtMS03MjQtODU3OCAgaHR0cDovL3d3dy56dXJp Y2guaWJtLmNvbS9+cmhhDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICBGb3JjZXMtcHJvdG9j b2wgbWFpbGluZyBsaXN0DQogIEZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZw0KICBodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXMtcHJvdG9jb2wNCg0K ------=_NextPart_000_1150_01C4B911.F8A43470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD10ZXh0L2h0bWw7Y2hhcnNldD1JU08tODg1OS0xPg0KPE1FVEEgY29u dGVudD0iTVNIVE1MIDYuMDAuMjYwMC4wIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxF Pg0KPC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAwIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+SGkgUm9iZXJ0LDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj5zZWUgcmVwbHkgaW4gbGluZS4gPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm YWNlPUFyaWFsIHNpemU9Mj50aGFuayB5b3UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9Mj53ZWltaW5nPC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHlsZT0i UEFERElORy1SSUdIVDogMHB4OyBQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsg Qk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxE SVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g PC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiAxMHB0 IGFyaWFsOyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT1yaGFA enVyaWNoLmlibS5jb20gaHJlZj0ibWFpbHRvOnJoYUB6dXJpY2guaWJtLmNvbSI+Um9iZXJ0IEhh YXM8L0E+IA0KICA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCBhcmlhbCI+PEI+VG86 PC9CPiA8QSB0aXRsZT13bXdhbmdAbWFpbC5oemljLmVkdS5jbiANCiAgaHJlZj0ibWFpbHRvOndt d2FuZ0BtYWlsLmh6aWMuZWR1LmNuIj5XYW5nLFdlaW1pbmc8L0E+IDwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiAxMHB0IGFyaWFsIj48Qj5DYzo8L0I+IDxBIHRpdGxlPWhvcm11emQubS5raG9z cmF2aUBpbnRlbC5jb20gDQogIGhyZWY9Im1haWx0bzpob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwu Y29tIj5LaG9zcmF2aSwgSG9ybXV6ZCBNPC9BPiA7IDxBIA0KICB0aXRsZT1yYW0uZ29wYWxAbm9r aWEuY29tIA0KICBocmVmPSJtYWlsdG86cmFtLmdvcGFsQG5va2lhLmNvbSI+cmFtLmdvcGFsQG5v a2lhLmNvbTwvQT4gOyA8QSANCiAgdGl0bGU9YXZyaUBhY20ub3JnIGhyZWY9Im1haWx0bzphdnJp QGFjbS5vcmciPmF2cmlAYWNtLm9yZzwvQT4gOyA8QSANCiAgdGl0bGU9Zm9yY2VzLXByb3RvY29s QGlldGYub3JnIA0KICBocmVmPSJtYWlsdG86Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIj5mb3Jj ZXMtcHJvdG9jb2xAaWV0Zi5vcmc8L0E+IDsgPEEgDQogIHRpdGxlPWhhZGlAem55eC5jb20gaHJl Zj0ibWFpbHRvOmhhZGlAem55eC5jb20iPkphbWFsIEhhZGkgU2FsaW08L0E+IDsgPEEgDQogIHRp dGxlPWRvbmdsZ0BtYWlsLmh6aWMuZWR1LmNuIGhyZWY9Im1haWx0bzpkb25nbGdAbWFpbC5oemlj LmVkdS5jbiI+TGlnYW5nIA0KICBEb25nPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDog MTBwdCBhcmlhbCI+PEI+U2VudDo8L0I+IFNhdHVyZGF5LCBPY3RvYmVyIDIzLCAyMDA0IDI6NTMg DQogIEFNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwiPjxCPlN1YmplY3Q6 PC9CPiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gUkU6IA0KICBkcmFmdC1pZXRmLWZvcmNlcy1wcm90 b2NvbC0wMS0wLnR4dDwvRElWPg0KICA8RElWPjxCUj48L0RJVj5XZWltaW5nLDxCUj5JIGhhdmUg YSBmZXcgc3VnZ2VzdGlvbnMgZm9yIHlvdXIgc2VjdGlvbnMuIFNlZSANCiAgaW5saW5lLiBQbGVh c2UgcmV2aWV3IHRoZW0gYW5kIGluZGljYXRlIHRvIEF2cmkgaWYgc2hlIHNob3VsZCBpbmNvcnBv cmF0ZSANCiAgdGhlc2UgaW50byB0aGUgZmluYWwgZHJhZnQuIEl0IHdvdWxkIGJlIGdvb2QgaWYg QXZyaSBjb3VsZCBkbyB0aGUgDQogIGVuZ2xpc2gtY2hlY2sgb24gdGhlc2Ugc2VjdGlvbnMgdG8g YXMgSSBhbSBub3QgYSBuYXRpdmUgZW5nbGlzaCBzcGVha2VyIA0KICBuZWl0aGVyPEJSPlJlZ2Fy ZHMsPEJSPi1Sb2JlcnQ8QlI+DQogIDxCTE9DS1FVT1RFIGNpdGU9bWlkMTA4NzAxYzRiODRhJDgw MjhiYTYwJDg0NWMyMWQyQE5lY29tLmh6aWMuZWR1LmNuIA0KICB0eXBlPSJjaXRlIj48UFJFIHdy YXA9IiI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+IDwvRk9OVD4mbHQ7P3htbCB2ZXJzaW9uPSIx LjAiIGVuY29kaW5nPSJVVEYtOCI/Jmd0Ow0KJmx0OyEtLSBlZGl0ZWQgd2l0aCAmbHQ7T1h5Z2Vu LyZndDtYTUwgZWRpdG9yIDQuMSwgYnkgV2VpbWluZyBXYW5nICZhbXA7IExpZ2FuZyBEb25nIA0K ICAgICAqKiogUmVkaXJlY3RNc2cgVjEuMCwgMjAwNC0wNi0xMywgY2hhbmdlcyBzaW5jZSBsYXN0 IHZlcnNpb246DQogICAgIC0gTm9uZSwgYXMgdGhlIG9yaWdpbmFsIHZlcnNpb24uDQogICAgICoq KiBSZWRpcmVjdE1zZ1YxLjEsIDIwMDQtMDYtMTguDQotLSZndDsNCg0KJmx0O3NlY3Rpb24gYW5j aG9yPSJSZWRpcmVjdE1zZyIgdGl0bGU9IlBhY2tldCBSZWRpcmVjdCBNZXNzYWdlIiZndDsNCg0K Jmx0O3QmZ3Q7UGFja2V0IHJlZGlyZWN0IG1lc3NhZ2UgaXMgdXNlZCB0byB0cmFuc2ZlciBkYXRh IHBhY2tldHMgDQogICAgYmV0d2VlbiBDRSBhbmQgRkUuIFVzdWFsbHkgdGhlc2UgZGF0YSBwYWNr ZXRzIGFyZSBJUCBwYWNrZXRzLCANCiAgICB0aG91Z2ggdGhleSBtYXkgc29tZXRpbWVzIGFzc29j aWF0ZWQgd2l0aCBzb21lIG1ldGFkYXRhIA0KICAgIGdlbmVyYXRlZCBieSBvdGhlciBMRkJzIGlu IHRoZSBtb2RlbCwgb3IgdGhleSBtYXkgDQogICAgb2NjYXNpb25hbGx5IGJlIG90aGVyIHByb3Rv Y29sIHBhY2tldHMsIHdoaWNoIHVzdWFsbHkgaGFwcGVuIA0KICAgIHdoZW4gQ0UgYW5kIEZFIGFy ZSBqb2ludGx5IGltcGxlbWVudGluZyBzb21lIGhpZ2gtdG91Y2ggDQogICAgb3BlcmF0aW9ucy4g UGFja2V0cyByZWRpcmVjdGVkIGZyb20gRkUgdG8gQ0UgYXJlIHRoZSBkYXRhIA0KICAgIHBhY2tl dHMgdGhhdCBjb21lIGZyb20gZm9yd2FyZGluZyBwbGFuZSwgYW5kIHVzdWFsbHkgYXJlIHRoZSAN CiAgICBkYXRhIHBhY2tldHMgdGhhdCBuZWVkIGhpZ2gtdG91Y2ggb3BlcmF0aW9ucyBpbiBDRS48 L1BSRT48L0JMT0NLUVVPVEU+DQogIDxESVY+Jm5ic3A7Li4uIG9yIHBhY2tldHMgZm9yIHdoaWNo IHRoZSBJUCBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIHRoZSBORS4gDQogIFtOb3RlIHRoYXQgSSBk aXN0aW5ndWlzaCBoaWdoLXRvdWNoIG9wZXJhdGlvbnMgZnJvbSBlbmRwb2ludCBwcm90b2NvbCAN CiAgcHJvY2Vzc2luZ108L0RJVj4NCiAgPERJVj5bV11kb25lLjxCUj48L0RJVj4NCiAgPEJMT0NL UVVPVEUgY2l0ZT1taWQxMDg3MDFjNGI4NGEkODAyOGJhNjAkODQ1YzIxZDJATmVjb20uaHppYy5l ZHUuY24gDQogIHR5cGU9ImNpdGUiPjxQUkUgd3JhcD0iIj4gUGFja2V0cyANCiAgICByZWRpcmVj dGVkIGZyb20gQ0UgdG8gRkUgYXJlIHRoZSBkYXRhIHBhY2tldHMgdGhhdCBhcmUgDQogICAgZ2Vu ZXJhdGVkIGJ5IENFIGFuZCBhcmUgZGVjaWRlZCBieSBDRSB0byBwdXQgaW50byBmb3J3YXJkaW5n IA0KICAgIHBsYW5lIGluIEZFLiZsdDsvdCZndDsNCg0KICA8L1BSRT48L0JMT0NLUVVPVEU+DQog IDxESVY+ZG9uJ3Qgd3JpdGUgImdlbmVyYXRlZCBieSB0aGUgQ0UiLiBTdWNoIHBhY2tldHMgY291 bGQgdmVyeSB3ZWxsIGJlIA0KICBwYWNrZXRzIHRoYXQgaW5pdGlhbGx5IHdlcmUgcmVkaXJlY3Rl ZCBmcm9tIGFuIEZFLiBJbnN0ZWFkLCBqdXN0IHNheSAiY29tZSANCiAgZnJvbSB0aGUgQ0UiLjwv RElWPg0KICA8RElWPltXXWRvbmUuPEJSPjwvRElWPg0KICA8QkxPQ0tRVU9URSBjaXRlPW1pZDEw ODcwMWM0Yjg0YSQ4MDI4YmE2MCQ4NDVjMjFkMkBOZWNvbS5oemljLmVkdS5jbiANCiAgdHlwZT0i Y2l0ZSI+PFBSRSB3cmFwPSIiPiZsdDt0Jmd0O0J5IHByb3Blcmx5IGNvbmZpZ3VyaW5nIHJlbGF0 ZWQgTEZCcyBpbiBGRSwgYSBwYWNrZXQgY2FuIGFsc28gDQogICAgYmUgbWlycm9yZWQgdG8gQ0Ug aW5zdGVhZCBvZiBwdXJlbHkgcmVkaXJlY3RlZCB0byBDRSwgaS5lLiwgDQogICAgdGhlIHBhY2tl dCBpcyBkdXBsaWNhdGVkIGFuZCBvbmUgaXMgcmVkaXJlY3RlZCB0byBDRSBhbmQgdGhlIA0KICAg IG90aGVyIGNvbnRpbnVlcyBpdHMgd2F5IGluIHRoZSBMRkIgdG9wb2xvZ3kuICZsdDsvdCZndDsN Cg0KICA8L1BSRT48L0JMT0NLUVVPVEU+DQogIDxESVY+U2lkZSBub3RlOiB3ZSB3aWxsIGhhdmUg dG8gZGVmaW5lIGhvdyB0aGUgcGFja2V0IGhlYWRlciBvbmx5IGNhbiBiZSANCiAgcGFzc2VkIHRv IHRoZSBDRSwgYW5kIGxlYXZlIHRoZSBwYXlsb2FkIGluIHRoZSBGRSwgdW50aWwgdGhlIENFIGRl Y2lkZXMgd2hhdCANCiAgdG8gZG8gd2l0aCB0aGUgcGFja2V0LjwvRElWPg0KICA8RElWPltXXU15 IHRob3VnaHQgaXMgd2hpY2ggcGFydCBvZiBhIHBhY2tldCB3aWxsIGJlIHJlZGlyZWN0ZWQgdG8g d2lsbCBiZSANCiAgZGVjaWRlZCBieSBvdGhlciBMRkJzIHRoYW4gdGhlIHNwZWNpZmljIHJlZGly ZWN0IExGQi4gSW4gdGhpcyB3YXksIHdlIGxlYXZlIA0KICBtdWNoIGZsZXhpYmlsaXR5LjxCUj48 QlI+U2Vjb25kIHNpZGUgbm90ZTogd2UgbmVlZCB0byBzcGVjaWZ5IHdoeSB3ZSBjb25zaWRlciAN CiAgdGhhdCBwYWNrZXRfcmVkaXJlY3QgZGVzZXJ2ZXMgaXRzIG93biBtZXNzYWdlIHR5cGUsIGFu ZCBub3Qgc2ltcGx5IGJlIHRyZWF0ZWQgDQogIGFzIGFuIGV2ZW50IGZpcmVkIGJ5IHRoZSBSZWRp cmVjdCBMRkIgdGhhdCBjb250YWlucywgYXMgcGFydCBvZiB0aGUgZXZlbnQgDQogIGRhdGEsIHRo ZSBwYWNrZXQgaXRzZWxmLiBNeSB0aGlua2luZyBpcyB0aGF0IHVzaW5nIGEgc3BlY2lmaWMgbWVz c2FnZSB0eXBlIGlzIA0KICBpbXBvcnRhbnQgdG8gbGV0IHRoZSBDRSBkaXN0aW5ndWlzaCBwcm9t cHRseSBpZiB0aGUgbWVzc2FnZSBpcyBhbiBGRS1pbnRlcm5hbCANCiAgZXZlbnQgb3IgYW4gZXh0 ZXJuYWwgcGFja2V0IHRoYXQgd2FzIGp1c3QgZm9yd2FyZGVkLiBTb21ldGhpbmcgbGlrZSB0aGlz IA0KICBzaG91bGQgYmUgd3JpdHRlbiBpbiB0aGUgaW50cm8gb2YgdGhpcyBzZWN0aW9uLiBXZWlt aW5nID88QlI+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPltXXSBJIHRoaW5rIHRoZSBtb3N0 IGltcG9ydGFudCB0byBoYXZlIGEgc3BlY2lmaWMgcmVkaXJlY3QgbWVzc2FnZSBpcyANCiAgZm9y IERvUyBwcmV2ZW50aW9uLiBJJ3YgYWRkIHNvbWUgdGhpbmcuPC9GT05UPjwvRElWPg0KICA8QkxP Q0tRVU9URSBjaXRlPW1pZDEwODcwMWM0Yjg0YSQ4MDI4YmE2MCQ4NDVjMjFkMkBOZWNvbS5oemlj LmVkdS5jbiANCiAgdHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPiZsdDt2c3BhY2UgYmxhbmtMaW5l cz0iMSIgLyZndDsNCiZsdDtsaXN0IHN0eWxlPSJoYW5naW5nIiBoYW5nSW5kZW50PSIxNyImZ3Q7 DQombHQ7dCBoYW5nVGV4dCA9ICJFZGl0b3JpYWwgTm90ZTogIiZndDsgDQpUaGVyZSBhcmUgYWxz byBkaXNjdXNzaW9ucyBvbiBob3cgTEZCcyBpbiBGRSBtb2RlbCB0aGF0IGFyZSANCiAgICByZWxh dGVkIHRvIHBhY2tldCByZWRpcmVjdCBvcGVyYXRpb25zIHNob3VsZCBiZSBkZWZpbmVkLiBBbHRo b3VnaCANCiAgICBpdCBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIGZvcmNlcyBwcm90b2NvbCwgaG93 IHRvIGRlZmluZSB0aGUgTEZCcyANCiAgICBhZmZlY3QgdGhlIFBhY2tldCBSZWRpcmVjdCBNZXNz YWdlIGRlc2NyaWJlZCBoZXJlLiBCZWNhdXNlIGN1cnJlbnRseQ0KICAgIGl0IGlzIHN0aWxsIGlu IHByb2dyZXNzIGluIEZFIG1vZGVsIG9uIGhvdyB0byBkZWZpbmUgc3VjaCBMRkJzLCANCiAgICB3 ZSB0cnkgdG8gcG9zdCBzb21lIHRob3VnaHRzIG9uIHRoaXMgaGVyZSBmb3IgZGlzY3Vzc2lvbi4g VGhleSANCiAgICB3aWxsIGJlIHJlbW92ZWQgbGF0ZXIgYWxvbmcgd2l0aCB0aGUgcHJvZ3Jlc3Mg b2YgdGhlIEZFIG1vZGVsIHdvcmsuDQombHQ7L3QmZ3Q7DQombHQ7dnNwYWNlIGJsYW5rTGluZXM9 IjEiIC8mZ3Q7DQombHQ7dCBoYW5nVGV4dCA9IiAgICAgVGhvdWdodCAxOiAiJmd0Ow0KVG8gZGVm aW5lIExGQnMgY2FsbGVkICdSZWRpcmVjdFNpbmsnIGFuZCAnUmVkaXJlY3RUYXAnIGZvcg0KcGFj a2V0IHJlZGlyZWN0LiZsdDsvdCZndDsNCiZsdDt0Jmd0O0FuIExGQiBpbiBGRSBjYWxsZWQgJ1Jl ZGlyZWN0U2luaycgaXMgcmVzcG9uc2libGUgdG8gY29sbGVjdCANCiAgICBkYXRhIHBhY2tldHMg dGhhdCBuZWVkIHRvIGJlIHJlZGlyZWN0ZWQgdG8gQ0UuIEZyb20gdGhlIA0KICAgIHBlcnNwZWN0 aXZlIG9mIHRoZSBGRSBMRkIgdG9wb2xvZ3ksIHRoZSAnUmVkaXJlY3RTaW5rJyBMRkIgDQogICAg aXMgYW4gTEZCIHdpdGggb25seSBvbmUgaW5wdXQgcG9ydCBhbmQgd2l0aG91dCBhbnkgb3V0cHV0 IA0KICAgIHBvcnQsIGFuZCB0aGUgaW5wdXQgcG9ydCBjYW4gdGhlbiBiZSBjb25uZWN0ZWQgdG8g YW55IG90aGVyIA0KICAgIExGQiBpbiBGRSBtb2RlbCBieSBtZWFucyBvZiBhIGRhdGFwYXRoIGlu IHRoZSBmb3J3YXJkaW5nIA0KICAgIHBsYW5lLiBGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiB0aGUg Rm9yQ0VTIHByb3RvY29sIGxheWVyLCANCiAgICB0aGUgJ1JlZGlyZWN0U2luaycgTEZCIHdpbGwg Z2VuZXJhdGUgdGhlIFBhY2tldCBSZWRpcmVjdCANCiAgICBNZXNzYWdlcyB3aGVuIGl0IHJlY2Vp dmVzIGRhdGEgcGFja2V0cyBmcm9tIGZvcndhcmRpbmcgcGxhbmUuDQombHQ7L3QmZ3Q7DQombHQ7 dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8mZ3Q7DQombHQ7dCZndDtBbiBMRkIgaW4gRkUgY2FsbGVk ICdSZWRpcmVjdFRhcCcgaXMgcmVzcG9uc2libGUgdG8gcmVjZWl2ZSANCiAgICBkYXRhIHBhY2tl dHMgdGhhdCBhcmUgcmVkaXJlY3RlZCBmcm9tIENFLiBGcm9tIHRoZSBwZXJzcGVjdGl2ZSANCiAg ICBvZiB0aGUgRkUgTEZCIHRvcG9sb2d5LCB0aGUgJ1JlZGlyZWN0VGFwJyBMRkIgaXMgYW4gTEZC IHdpdGggDQogICAgb25seSBvbmUgb3V0cHV0IHBvcnQgYW5kIHdpdGhvdXQgYW55IGlucHV0IHBv cnQsIGFuZCB0aGUgDQogICAgb3V0cHV0IHBvcnQgY2FuIHRoZW4gYmUgY29ubmVjdGVkIHRvIGFu eSBvdGhlciBMRkIgaW4gRkUgDQogICAgbW9kZWwgYnkgbWVhbnMgb2YgYSBkYXRhcGF0aCBpbiB0 aGUgZm9yd2FyZGluZyBwbGFuZS4gRnJvbSANCiAgICB0aGUgcGVyc3BlY3RpdmUgb2YgRm9yQ0VT IHByb3RvY29sIGxheWVyLCB0aGUgJ1JlZGlyZWN0VGFwJyANCiAgICBMRkIgY2FuIHJlY2VpdmUg dGhlIFBhY2tldCBSZWRpcmVjdCBNZXNzYWdlcyBmcm9tIENFLCBhbmQgDQogICAgdW4tZW5jYXBz dWxhdGUgdGhlIGRhdGEgcGFja2V0cyBmcm9tIHRoZSBtZXNzYWdlIGFuZCBwdXQgDQogICAgdGhl bSB0byBkYXRhcGF0aHMgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuIEFjdHVhbGx5IHRoZSANCiAg ICAnUmVjaXJlY3RUYXAnIExGQiBhY3RzIG1vcmUgbGlrZSBhIHRyYW5zY29kZXIgdGhhdCB0cmFu c2ZlcnMgDQogICAgdGhlIEZvckNFUyBwcm90b2NvbCBtZXNzYWdlcyB0byBub3JtYWwgZGF0YSBw YWNrZXRzIGluIElQIA0KICAgIGZvcndhcmRpbmcgcGxhbmUuIEFzIGEgcmVzdWx0LCBpZiB3ZSBu ZWVkIHRvIGhhdmUgcmVkaXJlY3RlZCANCiAgICBwYWNrZXRzIGNvbm5lY3RlZCB0byBzb21lIExG QiAoc2F5IGEgU2NoZWR1bGVyKSBpbiBGRSBtb2RlbCwgDQogICAgd2Ugb25seSBuZWVkIHRvIGNv bm5lY3QgdGhlICdSZWRpcmVjdFRhcCBMRkIgdG8gdGhlIFNjaGVkdWxlciANCiAgICBMRkIgZGly ZWN0bHkgdmlhIGEgZGF0YXBhdGggYXMgZm9sbG93czoNCiZsdDt2c3BhY2UgYmxhbmtMaW5lcz0i MSIgLyZndDsNCiZsdDtmaWd1cmUgYW5jaG9yPSJMRkJfUmVkaXJlY3QiJmd0OyZsdDthcnR3b3Jr Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0rICAgICAg ICstLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgfCBSZWRpcmVjdFRhcCBM RkIgfC0tLS0tLSZndDt8ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tLSsgICAgICAgfCAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgU2NoZWR1bGVyIHwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEZyb20gb3RoZXIgTEZCICAgLS0tLSZndDt8ICAgIExGQiAg ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICstLS0tLS0tLS0tLSsNCiZsdDsvYXJ0d29yayZndDsmbHQ7L2ZpZ3VyZSZndDsN CiZsdDsvdCZndDsNCiZsdDt2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLyZndDsNCiZsdDt0Jmd0O0J5 IHVzZSBvZiBzZXZlcmFsICdSZWRpcmVjdFNpbmsnIExGQnMgYW5kIHNldmVyYWwgJ1JlZGlyZWN0 VGFwJyANCiAgICBMRkJzIHRoYXQgY29ubmVjdCB0byBzZXZlcmFsIGRpZmZlcmVudCBkYXRhcGF0 aHMgaW4gRkUgDQogICAgZm9yd2FyZGluZyBwbGFuZSwgbXVsdGlwbGUgcGFja2V0IHJlZGlyZWN0 IHBhdGhzIGJldHdlZW4gDQogICAgQ0UgYW5kIEZFIGNhbiBiZSBjb25zdHJ1Y3RlZC4gJmx0Oy90 Jmd0Ow0KJmx0O3ZzcGFjZSBibGFua0xpbmVzPSIxIiAvJmd0Ow0KJmx0O3QgaGFuZ1RleHQgPSIg ICAgIFRob3VnaHQgMjogIiZndDsNCiAgICBUaGVyZSBtaWdodCBiZSBhbm90aGVyIHdheSBhIHBh Y2tldCBjb3VsZCBiZSByZWRpcmVjdGVkOg0KICAgIGRpcmVjdGx5IGJ5IGEgZm9yd2FyZGluZyBw YXRoLCBlLmcuLCBieSBGUEdBL0FTSUMvTlAgbWljcm9jb2RlLiBJbiANCiAgICBzdWNoIGEgY2Fz ZSB3ZSBkbyBub3QgbmVlZCB0byBwdXQgaW4gYSBsb3Qgb2Ygc21hcnRuZXNzLiBQcm9iYWJseSAN CiAgICBhIGxpbmsgbGF5ZXIgb3IgZXZlbiBuZXR3b3JrIGxldmVsIGhlYWRlciBpcyBlbm91Z2gu IFRoZSByZWNlaXZlciANCiAgICBkZW11eGVzIGl0IG9ubHkgYmFzZWQgb24gc29tZSBwcm90b2Nv bCB0eXBlIGluIHRoZSBsaW5rIGxheWVyIG9yIA0KICAgIG5ldHdvcmsgdHJhbnNwb3J0IGxheWVy LiBUaGUgcHJvcyBmb3IgdGhpcyBhcHByYW9jaCBpcyBpdCBtYXkgDQogICAgcHJvdmlkZSBhIGZh c3QgYW5kIGNvc3QtZWZmZWN0aXZlIHBhdGggZm9yIHBhY2tldCByZWRpcmVjdC4gVGhlIA0KICAg IGNvbnMgZm9yIHRoaXMgaXMgaXQgbWF5IG1vcmUgb3IgbGVzcyBjb25mdXNlcyB0aGUgRnAgcmVm ZXJlbmNlIA0KICAgIHBvaW50IGRlZmluaXRpb24gaW4gRm9yQ0VTIGZyYW1ld29yay4gDQombHQ7 L3QmZ3Q7DQombHQ7L2xpc3QmZ3Q7DQombHQ7dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8mZ3Q7DQom bHQ7dCZndDtXZSBkZXNjcmliZSB0aGUgUGFja2V0IFJlZGlyZWN0IE1lc3NhZ2UgZGF0YSBmb3Jt YXQgaW4gZGV0YWlscyANCiAgICBhcyBmb2xsb3dzOiZsdDsvdCZndDsNCiZsdDtsaXN0IHN0eWxl PSJoYW5naW5nIiBoYW5nSW5kZW50PSIxIiZndDsNCiZsdDt0IGhhbmdUZXh0PSAiTWVzc2FnZSBE aXJlY3Rpb246ICAiJmd0OyZsdDt2c3BhY2UgLyZndDsNCkNFIHRvIEZFIG9yIEZFIHRvIENFDQom bHQ7L3QmZ3Q7DQoNCg0KJmx0O3QgaGFuZ1RleHQ9ICJNZXNzYWdlIEhlYWRlcjogICImZ3Q7Jmx0 O3ZzcGFjZSAvJmd0Ow0KVGhlIE1lc3NhZ2UgVHlwZSBpbiB0aGUgaGVhZGVyIGlzIHNldCB0byAN CiAgICBNZXNzYWdlVHlwZT0gJ1BhY2tldFJlZGlyZWN0Jy4gVGhlIEFDSyBmbGFncyBpbiB0aGUg aGVhZGVyIA0KICAgIFNIT1VMRCBiZSBzZXQgJ05vQUNLJywgbWVhbmluZyBubyByZXNwb25zZSBp cyBleHBlY3RlZCBieSB0aGlzIA0KICAgIG1lc3NhZ2UuIElmIHRoZSBBQ0sgZmxhZyBpcyBzZXQg b3RoZXIgdmFsdWVzLCB0aGUgDQogICAgbWVhbmluZ3Mgd2lsbCBiZSBpZ25vcmVkLg0KJmx0Oy90 Jmd0Ow0KDQoNCiZsdDt0IGhhbmdUZXh0PSAiTWVzc2FnZSBCb2R5OiAiJmd0OyZsdDt2c3BhY2Ug LyZndDsNCkNvbnNpc3RzIG9mIG9uZSBvciBtb3JlIFRMVnMsIHdpdGggZXZlcnkgVExWIGhhdmlu ZyB0aGUgDQogICAgZm9sbG93aW5nIGRhdGEgZm9ybWF0Og0KJmx0Oy90Jmd0Ow0KDQogIDwvUFJF PjwvQkxPQ0tRVU9URT4NCiAgPEJMT0NLUVVPVEUgY2l0ZT1taWQxMDg3MDFjNGI4NGEkODAyOGJh NjAkODQ1YzIxZDJATmVjb20uaHppYy5lZHUuY24gDQogIHR5cGU9ImNpdGUiPjxQUkUgd3JhcD0i Ij4mbHQ7ZmlndXJlIGFuY2hvcj0idGx2X1JlZGlyZWN0X0RhdGEiJmd0Ow0KJmx0O2FydHdvcmsm Z3Q7DQogICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMQ0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICBUeXBlID0gTEZC c2VsZWN0ICAgICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBMRkIgQ2xhc3MgSUQgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgTEZCIEluc3RhbmNlIElEICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgT3BlcmF0aW9pbiBUTFYgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAuICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0KICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAg ICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg T3BlcmF0aW9pbiBUTFYgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAuICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLg0K ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KICANCiZsdDsvYXJ0d29yayZndDsmbHQ7L2ZpZ3VyZSZndDsNCg0KJmx0 O3QgaGFuZ1RleHQ9ICJMRkIgY2xhc3MgSUQ6ICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KVGhlcmUg YXJlIG9ubHkgdHdvIHBvc3NpYmxlIExGQiBjbGFzc2VzIGhlcmUsIHRoZSANCiAgICAnUmVkaXJl Y3RTaW5rJyBMRkIgb3IgdGhlICdSZWRpcmVjdFRhcCcgTEZCLiBJZiB0aGUgbWVzc2FnZSBpcyAN CiAgICBmcm9tIEZFIHRvIENFLCB0aGUgTEZCIGNsYXNzIHNob3VsZCBiZSAnUmVkaXJlY3RTaW5r Jy4gSWYgdGhlIA0KICAgIG1lc3NhZ2UgaXMgZnJvbSBDRSB0byBGRSwgdGhlIExGQiBjbGFzcyBz aG91bGQgYmUgJ1JlZGlyZWN0VGFwJy4NCiZsdDsvdCZndDsNCg0KICA8L1BSRT48L0JMT0NLUVVP VEU+DQogIDxESVY+V2h5IHJlc3RyaWN0IHRoaXMgPyBJZiBhbnkgb3RoZXIgTEZCIHdhbnRzIHRv IGdlbmVyYXRlIGEgcGFja2V0IHJlZGlyZWN0IA0KICB0byB0aGUgQ0UsIGxldCBoaW0gZG8gaXQg ITwvRElWPg0KICA8RElWPltXXU15IHRob3VnaHQgaXMgZGlmZmVyZW50LiBJZiBzb21lIExGQnMg dGhhdCBoYXZlIGRhdGEgcmVkaXJlY3RlZCB0byBDRSwgDQogIHRoZXkganVzdCB1c2UgYSByZWRp cmVjdCBMRkIgYXMgaXRzIG91dHB1dC4gSW4gdGhpcyB3YXksIHdlIGp1c3Qgc2F2ZTwvRElWPg0K ICA8RElWPnRoZSB3b3JrIHRvIGNvbmZpZ3VyZSB0aGUgTEZCIGZvciByZWRpcmVjdCBmdW5jdGlv bnMuRm9yIGluc3RhbmNlLCBpZiB3ZSANCiAgbmVlZCB0byBoYXZlIHNvbWUgY2xhc3NpZmllciB0 byByZWRpcmVjdCBzb21ldGhpbmcsIHdlIGp1c3QgbmVlZCB0byBoYXZlIG9uZSANCiAgb3V0cHV0 PC9ESVY+DQogIDxESVY+b2YgdGhlIGNsYXNzaWZpZXIgY29ubmVjdGVkIHRvIHJlZGlyY3QgTEZC LCByYXRoZXIgdGhhbiB0byBkZWZpbmUgYSANCiAgc3BlY2lmaWMgYXR0cmlidXRlcyBpbiB0aGUg Y2xhc3NpZmllciBmb3IgcmVkaXJlY3QuIEkgZXZlbiBjYW4gbm90IHNlZSBob3cgDQogIHN1Y2gg YXR0cmlidXRlIGNhbiBiZSBkZWZpbmVkLiA8QlI+PC9ESVY+DQogIDxCTE9DS1FVT1RFIGNpdGU9 bWlkMTA4NzAxYzRiODRhJDgwMjhiYTYwJDg0NWMyMWQyQE5lY29tLmh6aWMuZWR1LmNuIA0KICB0 eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+Jmx0O3QgaGFuZ1RleHQ9ICJJbnN0YW5jZSBJRDogIiZn dDsmbHQ7dnNwYWNlIC8mZ3Q7DQpJbnN0YW5jZSBJRCBmb3IgdGhlICdSZWRpcmVjdFNpbmsnIExG QiBvciAnUmVkaXJlY3RUYXAnIExGQi4NCiZsdDsvdCZndDsNCg0KDQombHQ7dCBoYW5nVGV4dD0g Ik9wZXJhdGlvbiBUTFY6ICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KVGhpcyBpcyBhIFRMViBkZXNj cmliaW5nIG9uZSBwYWNrZXQgb2YgZGF0YSB0byBiZSBkaXJlY3RlZCANCiAgICB2aWEgdGhlIHNw ZWNpZmllZCBMRkIgYWJvdmUuIFRoZSBvcmRlciBvZiB0aGUgZGF0YSBudW1iZXIgaXMgDQogICAg YWxzbyB0aGUgb3JkZXIgdGhlIGRhdGEgcGFja2V0IGFycml2ZXMgdGhlIHJlZGlyZWN0b3IgTEZC LCB0aGF0IA0KICAgIGlzLCB0aGUgUmVkaXJlY3RlZCBEYXRhICMxIHNob3VsZCBhcnJpdmUgZWFy bGllciB0aGFuIHRoZSANCiAgICBSZWRpcmVjdGVkIERhdGEgIzIgaW4gdGhpcyByZWRpcmVjdG9y IExGQi4gVGhlIFRMViBmb3JtYXQgaXMgDQogICAgYXMgZm9sbG93czoNCiZsdDsvdCZndDsNCiAg PC9QUkU+PC9CTE9DS1FVT1RFPg0KICA8RElWPklmIHdoYXQgeW91IG1lYW4gaXMgc2VxdWVuY2lu ZyB0aGUgcmVkaXJlY3RlZCBwYWNrZXQgdGhlbiBJIHRoaW5rIGl0IGlzIA0KICBkYW5nZXJvdXMu IEFzc3VtZSB5b3UgdXNlIFVEUCB0byB0cmFuc3BvcnQgdGhlIHJlZGlyZWN0ZWQgcGFja2V0cyBm cm9tIHRoZSBDRSANCiAgdG8gdGhlIEZFLiBJZiBvbmUgaXMgbG9zdCwgdGhlbiB3aGF0IHdpbGwg dGhlIEZFIGRvIHdpdGggdGhlIG5leHQgb25lcyA/PC9ESVY+DQogIDxESVY+W1ddIHNlcXVlbmlu ZyBmb3IgcmVkaXJlY3QgZGF0YSBpcyBpbXBvcnRhbnQuIFdoYXQgSSBtZW50aW9uZWQgaGVyZSBp cyANCiAgb25seSB0aGUgc2VxdWVuY2UgaW5zaWRlIG9uZSBtZXNzYWdlKG9uZSBVRFAgKSwgSSBz ZWUgc2VxdWVuY2UgbnVtYmVyIGluIA0KICBtZXNzYWdlIGhlYWRlciBpcyBpbiBjaGFyZ2Ugb2Yg c2VxdWVuY2UgYmV0d2VlbiBVRFAgcGFja2V0cy4gSSBzdXBwb3NlIGEgbG9zcyANCiAgb2YgVURQ IHdpbGwgbGVhZCB0byByZXRyYW5zbWlzc2lvbiBjb250cm9sbGVkIGJ5IFBMLiBJZiB3ZSB1c2Ug VENQLCB0aGUgVE1MIGlzIA0KICBpbiBjaGFyZ2Ugb2YgdGhpcy48QlI+PC9ESVY+DQogIDxCTE9D S1FVT1RFIGNpdGU9bWlkMTA4NzAxYzRiODRhJDgwMjhiYTYwJDg0NWMyMWQyQE5lY29tLmh6aWMu ZWR1LmNuIA0KICB0eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+DQombHQ7ZmlndXJlIGFuY2hvcj0i dGx2X1JlZGlyZWN0ZWRfRGF0YSImZ3Q7Jmx0O2FydHdvcmsmZ3Q7DQogICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICAgIHwgICAgVHlwZSA9IE9wZXJhdGlvbnMgKFBBWUxPQUQpfCAgICAgICAgICAgICAgIExlbmd0 aCAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICBQYXRoKG9yIFNlcXVlbmNlIE51bWJlcj8pICAgICAgICAgICAgICB8DQogICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICAgIH4gICAgICAgICAgICAgICAgICAgICAgICBSZWRpcmVjdGVkIERhdGEgICAgICAgICAg ICAgICAgICAgICAgICB+DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQombHQ7L2FydHdvcmsmZ3Q7Jmx0Oy9maWd1 cmUmZ3Q7DQombHQ7dCBoYW5nVGV4dD0gIlBhdGgob3IgU2VxdWVuY2UgTnVtYmVyPyk6ICImZ3Q7 Jmx0O3ZzcGFjZSAvJmd0Ow0KW1VuZGVyIGRpc2N1c3Npb24gYW5kIFRCRF0NCiZsdDsvdCZndDsN CiZsdDt0IGhhbmdUZXh0PSAiVHlwZTogIiZndDsmbHQ7dnNwYWNlIC8mZ3Q7DQpbVEJEXQ0KJmx0 Oy90Jmd0Ow0KDQombHQ7dCBoYW5nVGV4dD0gIlJlZGlyZWN0ZWQgRGF0YTogIiZndDsmbHQ7dnNw YWNlIC8mZ3Q7DQpUaGlzIGZpZWxkIHdpbGwgbWFrZSBhIGRldGFpbGVkIGRlc2NyaXB0aW9uIG9m IHRoZSBkYXRhIHRvIA0KICAgIGJlIHJlZGlyZWN0ZWQgYXMgd2VsbCBhcyB0aGUgZGF0YSBpdHNl bGYuIFRoZSBlbmNvZGluZyBvZiB0aGUgDQogICAgZGVzY3JpcHRpb24gaXMgYmFzZWQgb24gdGhl IEZvckNFUyBGRSBtb2RlbCBpZiB0aGUgcmVkaXJlY3RvciANCiAgICBMRkIgaXMgZGVmaW5lZCBi eSBGRSBtb2RlbCwgb3IgYmFzZWQgb24gdmVuZG9yIHNwZWNpZmljYXRpb25zIA0KICAgIGlmIHRo ZSByZWRpcmVjdG9yIExGQiBpcyBkZWZpbmVkIGJ5IHZlbmRvcnMuIFRoZSBkZXNjcmlwdGlvbiAN CiAgICB3aWxsIHVzdWFsbHkgaW5jbHVkZSB0aGUgbmFtZSAob3IgdGhlIG5hbWUgSUQpIG9mIHRo ZSByZWRpcmVjdGVkIA0KICAgIHBhY2tldCBkYXRhIChzdWNoIGFzICdJUHY0IFBhY2tldCcsICdJ UHY2IFBhY2tldCcpLCBhbmQgdGhlIA0KICAgIHBhY2tldCBkYXRhIGl0c2VsZi4gSXQgbWF5IGFs c28gaW5jbHVkZSBzb21lIG1ldGFkYXRhIChtZXRhZGF0YSANCiAgICBuYW1lIChvciBuYW1lIElE KSBhbmQgaXRzIHZhbHVlKWFzc29jaWF0ZWQgd2l0aCB0aGUgcmVkaXJlY3RlZCANCiAgICBkYXRh IHBhY2tldC4NCiZsdDsvdCZndDsNCiZsdDsvbGlzdCZndDsNCiZsdDsvc2VjdGlvbiZndDsNCg0K Jmx0OyEtLSAkTG9nOiBSZWRpcmVjdE1zZy54bWwsdiAkDQombHQ7IS0tIFJld3JpdHRlbiBieSBX ZWltaW5nIFdhbmcgMjAwNC8xMC8yMg0KJmx0OyEtLSBJbmNvcnBhcmF0ZSBMRkJzZWxlY3QgYW5k IE9wZXJhdGlvbiBUTFYgDQombHQ7IS0tDQombHQ7IS0tIFJldmlzaW9uIDEuNyAgMjAwNC8wNy8x OSAwOTozNzowNSAgYXZyaQ0KJmx0OyEtLSBWZXJzaW9uIDIgY2hlY2tpbg0KJmx0OyEtLQ0KJmx0 OyEtLSBSZXZpc2lvbiAxLjYgIDIwMDQvMDYvMjMgMDU6MDU6MzQgIGF2cmkNCiZsdDshLS0gZmlu YWwgZWRpdCBmb3IgMDANCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS41ICAyMDA0LzA2LzIy IDA3OjAyOjM3ICBhdnJpDQombHQ7IS0tIHJlbW92ZQ0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZpc2lv biAxLjQgIDIwMDQvMDYvMjIgMDc6MDE6MDAgIGF2cmkNCiZsdDshLS0gVGVhbSBFZGl0IGZyb20g MDAtNw0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZpc2lvbiAxLjIgIDIwMDQtMDYtMjEgMjE6NDA6NDEr MDggIGFkbWluaXN0cmF0b3INCiZsdDshLS0gSW5jb3JwYXJhdGUgc29tZSBjb21tZW50cyBmcm9t IEphbWFsIChKdW5lIDIxLCAyMDA0IDEwOjUwIEFNKS4gLVdlaW1pbmcNCiZsdDshLS0NCiZsdDsh LS0gUmV2aXNpb24gMS4xICAyMDA0LTA2LTIxIDIxOjA5OjQxKzA4ICBhZG1pbmlzdHJhdG9yDQom bHQ7IS0tIFJldmlzaW9uIGhhbmRlZCBmcm9tIEF2cmkuIC0gV2VpbWluZw0KJmx0OyEtLQ0KJmx0 OyEtLSBSZXZpc2lvbiAxLjMgIDIwMDQvMDYvMTkgMTM6MTE6MTIgIGF2cmkNCiZsdDshLS0gTGlu ZWZlZWRzDQombHQ7IS0tDQombHQ7IS0tIFJldmlzaW9uIDEuMiAgMjAwNC8wNi8xOSAxMzowNTow MCAgYXZyaQ0KJmx0OyEtLSBhbmNob3JzDQombHQ7IS0tDQombHQ7IS0tIFJldmlzaW9uIDEuMSAg MjAwNC8wNi8xNyAwMzo0NTo1NSAgYXZyaQ0KJmx0OyEtLSBJbml0aWFsIHJldmlzaW9uDQombHQ7 IS0tIA0KICAgICBlZGl0ZWQgd2l0aCAmbHQ7T1h5Z2VuLyZndDtYTUwgZWRpdG9yIDQuMSwgYnkg V2VpbWluZyBXYW5nICZhbXA7IExpZ2FuZyBEb25nIA0KICAgICAqKiogUmVkaXJlY3RNc2cgVjEu MCwgMjAwNC0wNi0xMywgY2hhbmdlcyBzaW5jZSBsYXN0IHZlcnNpb246DQogICAgIC0gTm9uZSwg YXMgdGhlIG9yaWdpbmFsIHZlcnNpb24uDQotLSZndDsNCiAgPC9QUkU+PFBSRSB3cmFwPSIiPiZs dDs/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8mZ3Q7DQombHQ7IS0tIGVkaXRl ZCB3aXRoICZsdDtPWHlnZW4vJmd0O1hNTCBlZGl0b3IgNC4xLCBieSBXZWltaW5nIFdhbmcgJmFt cDsgTGlnYW5nIERvbmcgDQogICAgICoqKiBRdWVyeU1zZyBWMS4wLCAyMDA0LTA2LTEzLCBjaGFu Z2VzIHNpbmNlIGxhc3QgdmVyc2lvbjoNCiAgICAgLSBOb25lLCBhcyB0aGUgb3JpZ2luYWwgdmVy c2lvbi4NCiAgICAgKioqIFF1ZXJ5TXNnVjEuMSwgMjAwNC0wNi0xOA0KICAgICAtIGNoYW5nZSBF bmNvZGluZ1R5cGUgdG8gVHlwZQ0KICAgICAqKiogUXVlcnlNc2dWMS4yLCAyMDA0LTEwLTIwDQog ICAgIC0gZm9yIGlldGYtcHJvdG9jb2wtMDENCi0tJmd0Ow0KDQombHQ7c2VjdGlvbiBhbmNob3I9 IlF1ZXJ5TXNnIiB0aXRsZT0iUXVlcnkgYW5kIFJlc3BvbnNlIE1lc3NhZ2VzIiZndDsNCiAgPC9Q UkU+PC9CTE9DS1FVT1RFPg0KICA8RElWPkJlIG1vcmUgc3BlY2lmaWM6ICJRdWVyeSBhbmQgUXVl cnkgUmVzcG9uc2UgTWVzc2FnZXMiPC9ESVY+DQogIDxESVY+W09LXTxCUj48L0RJVj4NCiAgPEJM T0NLUVVPVEUgY2l0ZT1taWQxMDg3MDFjNGI4NGEkODAyOGJhNjAkODQ1YzIxZDJATmVjb20uaHpp Yy5lZHUuY24gDQogIHR5cGU9ImNpdGUiPjxQUkUgd3JhcD0iIj4mbHQ7dCZndDtUaGUgRm9yQ0VT IHF1ZXJ5IGFuZCByZXNwb25zZSBtZXNzYWdlcyBhcmUgdXNlZCBmb3Igb25lIEZvckNFUyANCiAg ICBlbGVtZW50IChDRSBvciBGRSkgdG8gcXVlcnkgb3RoZXIgRm9yQ0VTIGVsZW1lbnQocykgZm9y IHZhcmlvdXMgDQogICAga2luZHMgb2YgaW5mb3JtYXRpb24uIEN1cnJlbnQgdmVyc2lvbiBvZiBG b3JDRVMgcHJvdG9jb2wgbGltaXRzIA0KICAgIHRoZSB1c2Ugb2YgdGhlIG1lc3NhZ2VzIG9ubHkg Zm9yIENFIHRvIHF1ZXJ5IGluZm9ybWF0aW9uIG9mIEZFLiANCiZsdDsvdCZndDsNCiZsdDtzZWN0 aW9uIGFuY2hvcj0iUXVlcnkiIHRpdGxlPSJRdWVyeSBNZXNzYWdlIiZndDsNCg0KJmx0O3QmZ3Q7 QXMgdXN1YWwsIGEgcXVlcnkgbWVzc2FnZSBpcyBjb21wb3NlZCBvZiBhIGNvbW1vbiBoZWFkZXIg YW5kIA0KICAgIGEgbWVzc2FnZSBib2R5IHRoYXQgY29uc2lzdHMgb2Ygb25lIG9yIG1vcmUgVExW IGRhdGEgZm9ybWF0LiANCiAgICBEZXRhaWxlZCBkZXNjcmlwdGlvbiBvZiB0aGUgbWVzc2FnZSBp cyBhcyBiZWxvdy4mbHQ7L3QmZ3Q7DQombHQ7bGlzdCBzdHlsZT0iaGFuZ2luZyIgaGFuZ0luZGVu dD0iNCImZ3Q7ICZsdDt2c3BhY2UgLyZndDsNCiZsdDt2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLyZn dDsNCiZsdDt0IGhhbmdUZXh0PSAiTWVzc2FnZSB0cmFuc2ZlciBkaXJlY3Rpb246IiZndDsgJmx0 O3ZzcGFjZSAvJmd0Ow0KQ3VycmVudCB2ZXJzaW9uIGxpbWl0cyB0aGUgcXVlcnkgbWVzc2FnZSB0 cmFuc2ZlciBkaXJlY3Rpb24gDQogICAgb25seSBmcm9tIENFIHRvIEZFLiZsdDsvdCZndDsNCg0K Jmx0O3QgaGFuZ1RleHQ9ICJNZXNzYWdlIEhlYWRlcjoiJmd0OyAmbHQ7dnNwYWNlIC8mZ3Q7DQpU aGUgTWVzc2FnZSBUeXBlIGluIHRoZSBoZWFkZXIgaXMgc2V0IHRvIE1lc3NhZ2VUeXBlPSAnUXVl cnknLiANCiAgICBUaGUgQUNLIGZsYWcgaW4gdGhlIGhlYWRlciBTSE9VTEQgYmUgc2V0ICdBQ0tB bGwnLCBtZWFuaW5nIGEgDQogICAgZnVsbCByZXNwb25zZSBmb3IgYSBxdWVyeSBtZXNzYWdlIGlz IGFsd2F5cyBleHBlY3RlZC4gSWYgdGhlIA0KICAgIEFDSyBmbGFnIGlzIHNldCBvdGhlciB2YWx1 ZXMsIHRoZSBtZWFuaW5nIG9mIHRoZSANCiAgICBmbGFnIHdpbGwgdGhlbiBiZSBpZ25vcmVkLCBh bmQgYSBmdWxsIHJlc3BvbnNlIHdpbGwgc3RpbGwgYmUgDQogICAgcmV0dXJuZWQgYnkgbWVzc2Fn ZSByZWNlaXZlci4mbHQ7L3QmZ3Q7DQoNCg0KJmx0O3QgaGFuZ1RleHQgPSAiTWVzc2FnZSBib2R5 OiAiJmd0OyZsdDt2c3BhY2UgLyZndDsNClRoZSBxdWVyeSBtZXNzYWdlIGJvZHkgY29uc2lzdHMg b2YgKGF0IGxlYXN0KSBvbmUgb3IgbW9yZSB0aGFuIA0KICAgIG9uZSBUTFZzIHRoYXQgZGVzY3Jp YmUgZW50cmllcyB0byBiZSBxdWVyaWVkLiBUaGUgVExWIGlzIGNhbGxlZCANCiAgICBMRkJzZWxl Y3QgVExWIGFuZCB0aGUgZGF0YSBmb3JtYXQgaXMgYXMgYmVsb3c6DQombHQ7L3QmZ3Q7DQombHQ7 ZmlndXJlIGFuY2hvcj0ibXNnX1F1ZXJ5IiZndDsNCiZsdDthcnR3b3JrJmd0Ow0KIA0KICAgICAg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgIFR5cGUgPSBMRkJzZWxlY3QgICAg ICAgfCAgICAgICAgICAgICAgIExlbmd0aCAgICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgIExGQiBDbGFzcyBJRCAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBM RkIgSW5zdGFuY2UgSUQgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBPcGVyYXRpb2luIFRMViAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgIC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAuDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgIH4gICAgICAg ICAgICAgICAgICAgICAgICAgICAuLi4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+ DQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQogICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBPcGVyYXRpb2lu IFRMViAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgIC4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQogICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogIDwvUFJFPjwvQkxPQ0tRVU9URT4NCiAgPERJVj5UeXBvIGluIGFsbCBmaWd1cmVzOiBj b3JyZWN0ICJPcGVyYXRpb2luIFRMViI8QlI+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPltX XXRoYW5rcy48L0ZPTlQ+PEJSPkdlbmVyYWwgY29tbWVudDogaW4gbWFueSBjYXNlcyB0aGUgc2Ft ZSB0eXBlIGluIA0KICBUTFYgaXMgdXNlZCBpbiBkaWZmZXJlbnQgUEwgbWVzc2FnZXMgKFF1ZXJ5 IHZzIFJlc3BvbnNlLCBldGMpIGFuZCB0aGVuIHRoZSBWIA0KICBpcyBkaWZmZXJlbnQuIFRoaXMg V0lMTCBiZSBhIGJpZyBzb3VyY2Ugb2YgaW1wbGVtZW50YXRpb24gYnVncy4gSSB0aGluayB3ZSAN CiAgc2hvdWxkIGRlZmluZWQgb3BlcmF0aW9uIFRMVnMgZGlmZmVyZW50bHk6IEdFVCBhbmQgR0VU LVJFU1AsIFNFVCBhbmQgU0VULVJFU1AsIA0KICBSRVBPUlQgYW5kIFJFUE9SVC1SRVNQLjxCUj5X aGF0IGRvIHlvdSB0aGluayA/PC9ESVY+DQogIDxESVY+W1ddSSBhZ3JlZSB3ZWxsLiBJIHRob3Vn aHQgb2YgdGhpcywganVzdCB0aGlua2luZyB0aGlzIE9wZXJhdGlvbiBUTFYgaXMgDQogIHJlYWxs eSBhIHRvcGljIGZvciBtdWNoIG1vcmUgZGlzY3Vzc2lvbiwgdGhlcmVmb3JlIEkgbGVhdmUgaXQg dGhlcmUuIEFueXdheSwgDQogIGxldCBtZSB0cnkgdG8gY2hhbmdlIGl0LiA8QlI+PC9ESVY+DQog IDxCTE9DS1FVT1RFIGNpdGU9bWlkMTA4NzAxYzRiODRhJDgwMjhiYTYwJDg0NWMyMWQyQE5lY29t Lmh6aWMuZWR1LmNuIA0KICB0eXBlPSJjaXRlIj48UFJFIHdyYXA9IiI+ICAgICANCiZsdDsvYXJ0 d29yayZndDsNCiZsdDsvZmlndXJlJmd0Ow0KJmx0O3ZzcGFjZSBibGFua0xpbmVzPSIxIiAvJmd0 Ow0KJmx0O2xpc3Qgc3R5bGU9ICJoYW5naW5nIiBoYW5nSW5kZW50PSIxNyIgJmd0Ow0KJmx0O3Qg aGFuZ1RleHQgPSAiRWRpdG9yaWFsIE5vdGU6ICImZ3Q7DQombHQ7L3QmZ3Q7DQombHQ7bGlzdCBz dHlsZT0ibnVtYmVycyIgaGFuZ0luZGVudD0iMyImZ3Q7DQombHQ7dCZndDtVbmRlciBkaXNjdXNz aW9uIGlzIHdoZXRoZXIgdGhlcmUgaXMgYSBuZWVkIGZvciBleHBsaWNpdCBtdWx0aXBsZSBMRkIg aW5zYXRhbmNlDQogICAgYWRkcmVzc2luZyBoZXJlLiBPbmUgd2F5IHRvIHJlYWxpemUgaXQgaXMg dG8gZGVmaW5lIGEgc3BlY2lmaWMgSW5zdGFuY2Ugc2VsZWN0DQogICAgVExWIHRvIHN1YnN0aXR1 dGUgYWJvdmUgJ0xGQiBJbnN0YW5jZSBJRCcgZmllbGQuIFRoZSBUTFYgbWF5IGhhdmUgZm9sbG93 aW5nIGZvcm1hdDombHQ7L3QmZ3Q7DQombHQ7ZmlndXJlJmd0OyZsdDthcnR3b3JrJmd0Ow0KICAg ICAgICBJTlNzZWxlY3RUTFYgOj0gVHlwZSBMZW5ndGggVmFsdWUNCiAgICAgICAgVHlwZSA6PSBJ TlNzZWxlY3QNCiAgICAgICAgVmFsdWUgOj0gSW5zdGFuY2VJRCAoUmFuZ2VNYXJrIHwgSW5zdGFu Y2UgSUQpKw0KDQombHQ7L2FydHdvcmsmZ3Q7Jmx0Oy9maWd1cmUmZ3Q7DQombHQ7dCZndDtBbiBh cHBsaWNhYmxlIFJhbmdlTWFyayBpcyAnMHhmZmZmZmZmZicsIHRoZSB2YWx1ZSBvZiB3aGljaCBp cyB0aGUgc2FtZSBhcyANCiAgICBJbnN0YW5jZSBicm9hZGNhc3QgSUQuIEJlY2F1c2UgdGhlcmUg d2lsbCBiZSBubyBicm9hZGNhc3QgYWRkcmVzcyBhcHBsaWVkDQogICAgaW4gdGhpcyBwbGFjZSwg dGhlcmUgd2lsbCBiZSBubyB3b3JyeSBvZiBhbWJpZ3VpdHkgaGVyZS4mbHQ7L3QmZ3Q7DQombHQ7 L2xpc3QmZ3Q7ICAgDQombHQ7L2xpc3QmZ3Q7DQombHQ7dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8m Z3Q7DQombHQ7dCBoYW5nVGV4dD0gIk9wZXJhdGlvbiBUTFYiJmd0OyZsdDt2c3BhY2UgLyZndDsN ClRoZSBPcGVyYXRpb24gVExWIGZvciB0aGUgJ1F1ZXJ5JyBtZXNzYWdlIGlzIGZvcm1hdHRlZCBh czoNCiZsdDsvdCZndDsNCiZsdDtmaWd1cmUgYW5jaG9yPSJ0bHZfUXVlcnkiJmd0Ow0KJmx0O2Fy dHdvcmsmZ3Q7ICAgIA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgIFR5cGUgPSBPcGVyYXRpb25z IChHRVQpICAgIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgUGF0aChvciBBdHRyaWJ1dGUgSUQ/KSAg ICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFF1ZXJ5IERhdGEgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAuICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KIA0KICA8L1BSRT48L0JMT0NLUVVPVEU+DQogIDxESVY+QWdh aW4sIGluIGFsbCB5b3VyIHNlY3Rpb25zLCBjb3VsZCB5b3UgY2hhbmdlICJUeXBlID0gT3BlcmF0 aW9ucyAoR0VUKSIgDQogIHRvICJUeXBlID0gR0VUIiBhbmQgc28gb24gPzwvRElWPg0KICA8RElW PltXXWFsc28gYWdyZWUgd2VsbC4gaG9wZSBKYW1hbCB3aWxsIG5vdCBvYmplY3QgdG8gaXQuIEkg dHJ5IHRvIGNoYW5nZSBpdCANCiAgZmlyc3QuPEJSPjwvRElWPg0KICA8QkxPQ0tRVU9URSBjaXRl PW1pZDEwODcwMWM0Yjg0YSQ4MDI4YmE2MCQ4NDVjMjFkMkBOZWNvbS5oemljLmVkdS5jbiANCiAg dHlwZT0iY2l0ZSI+PFBSRSB3cmFwPSIiPiZsdDsvYXJ0d29yayZndDsmbHQ7L2ZpZ3VyZSZndDsN CiZsdDt0IGhhbmdUZXh0PSAiUGF0aChvciBBdHRyaWJ1dGUgSUQ/KTogIiZndDsmbHQ7dnNwYWNl IC8mZ3Q7DQpbVW5kZXIgZGlzY3Vzc2lvbiBhbmQgVEJEXQ0KJmx0Oy90Jmd0Ow0KDQombHQ7dnNw YWNlIGJsYW5rTGluZXMgPSAiMSIgLyZndDsNCiZsdDtsaXN0IHN0eWxlPSJoYW5naW5nIiBoYW5n SW5kZW50PSIxNyImZ3Q7DQombHQ7dCBoYW5nVGV4dCA9ICJFZGl0b3JpYWwgTm90ZToiJmd0OyAN ClRoZXJlIGlzIGEgZGViYXRlIG9uIHdoZXRoZXIgd2Ugc2hvdWxkIHVzZSBhICdQYXRoJyBvciBz aW1wbHkgYW4gJ0F0dHJpYnV0ZSBJRCcgDQogICAgb3IgYSAnVGFibGUgSUQnIGhlcmUgYXQgdGhl IHByb3RvY29sIGxheWVyLiBBIFBhdGggaXMgdXNlZCBmb3IgZGF0YSANCiAgICBpbmRleGluZyBm b3IgYSB0YWJsZSwgd2hpbGUgYW4gJ0F0dHJpYnV0ZSBJRCcgb3IgYSAnVGFibGUgSUQnIG9ubHkg c3BlY2lmeSANCiAgICB3aGljaCBhdHRyaWJ1dGUgb3IgdGFibGUgdG8gdXNlLCBsZWF2aW5nIHRh YmxlIGluZGV4IHRvIGJlIGluY2x1ZGVkIGluIGZvbGxvd2VkIA0KICAgIGRhdGEuDQombHQ7L3Qm Z3Q7DQombHQ7L2xpc3QmZ3Q7DQombHQ7dnNwYWNlIGJsYW5rTGluZXM9IjEiIC8mZ3Q7DQombHQ7 dCBoYW5nVGV4dD0gIlF1ZXJ5IERhdGE6ICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KICAgIFtVbmRl ciBkaXNjdXNzaW9uIGFuZCBUQkRdDQombHQ7L3QmZ3Q7DQombHQ7L2xpc3QmZ3Q7DQombHQ7dCZn dDtUbyBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUgYWJvdmUgUERVIGZvcm1hdCwgd2UgY2FuIHNob3cg YSB0cmVlIHN0cnVjdHVyZSBmb3IgdGhlIA0KICAgIGZvcm1hdCBhcyBiZWxvdzoNCiZsdDtmaWd1 cmUmZ3Q7DQptYWluIGhkciAodHlwZSA9IFF1ZXJ5KQ0KICAgICB8DQogICAgIHwNCiAgICAgKy0t LSBUID0gTEZCc2VsZWN0DQogICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAgICAgKy0tIExGQkNM QVNTSUQgPSB0YXJnZXQgTEZCIGNsYXNzDQogICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAgICAg fA0KICAgICB8ICAgICAgICArLS0gTEZCSW5zdGFuY2UgPSB0YXJnZXQgTEZCIGluc3RhbmNlIA0K ICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAgIHwNCiAgICAgfCAgICAgICAgKy0tIFQgPSBv cGVyYXRpb24geyBHRVQgfQ0KICAgICB8ICAgICAgICB8ICAgfA0KICAgICB8ICAgICAgICB8ICAg Ky0tICAvLyBvbmUgb3IgbW9yZSBwYXRoIHRhcmdldHMgDQogICAgIHwgICAgICAgIHwgICAgICAg IC8vIHVuZGVyIGRpc2N1c3Npb24NCiAgICAgfCAgICAgICAgKy0tIFQgPSBvcGVyYXRpb24geyBH RVQgfQ0KICAgICB8ICAgICAgICB8ICAgfA0KICAgICB8ICAgICAgICB8ICAgKy0tICAvLyBvbmUg b3IgbW9yZSBwYXRoIHRhcmdldHMgDQogICAgIHwgICAgICAgIHwgDQoNCiZsdDsvZmlndXJlJmd0 Ow0KJmx0Oy9zZWN0aW9uJmd0Ow0KDQombHQ7c2VjdGlvbiBhbmNob3I9IlF1ZXJ5UmVzcG9uc2Ui IHRpdGxlPSJRdWVyeSBSZXNwb25zZSBNZXNzYWdlIiZndDsNCiZsdDt0Jmd0O1doZW4gcmVjZWl2 aW5nIGEgcXVlcnkgbWVzc2FnZSwgdGhlIHJlY2VpdmVyIHNob3VsZCBwcm9jZXNzIHRoZSANCiAg ICBtZXNzYWdlIGFuZCBjb21lIHVwIHdpdGggYSBxdWVyeSByZXN1bHQuIFRoZSByZWNlaXZlciBz ZW5kcyB0aGUgDQogICAgcXVlcnkgcmVzdWx0IGJhY2sgdG8gdGhlIG1lc3NhZ2Ugc2VuZGVyIGJ5 IHVzZSBvZiB0aGUgUXVlcnkgDQogICAgUmVzcG9uc2UgTWVzc2FnZS4gVGhlIHF1ZXJ5IHJlc3Vs dCBjYW4gYmUgdGhlIGluZm9ybWF0aW9uIA0KICAgIGJlaW5nIHF1ZXJpZWQgaWYgdGhlIHF1ZXJ5 IG9wZXJhdGlvbiBpcyBzdWNjZXNzZnVsLCBvciBjYW4gYWxzbyANCiAgICBiZSBlcnJvciBjb2Rl cyBpZiB0aGUgcXVlcnkgb3BlcmF0aW9uIGZhaWxzLCBpbmRpY2F0aW5nIHRoZSANCiAgICByZWFz b25zIGZvciB0aGUgZmFpbHVyZS4mbHQ7L3QmZ3Q7DQoNCiZsdDt0Jmd0O0EgcXVlcnkgcmVzcG9u c2UgbWVzc2FnZSBpcyBhbHNvIGNvbXBvc2VkIG9mIGEgY29tbW9uIGhlYWRlciBhbmQgDQogICAg YSBtZXNzYWdlIGJvZHkgY29uc2lzdHMgb2Ygb25lIG9yIG1vcmUgVExWcyBkZXNjcmliaW5nIHRo ZSBxdWVyeSANCiAgICByZXN1bHQuIERldGFpbGVkIGRlc2NyaXB0aW9uIG9mIHRoZSBtZXNzYWdl IGlzIGFzIGJlbG93LiZsdDsvdCZndDsNCiZsdDt2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLyZndDsN CiZsdDtsaXN0IHN0eWxlPSAiaGFuZ2luZyIgaGFuZ0luZGVudD0iNCImZ3Q7DQombHQ7dCBoYW5n VGV4dD0gIk1lc3NhZ2UgdHJhbnNmZXIgZGlyZWN0aW9uOiAiJmd0OyZsdDt2c3BhY2UgLyZndDsN CkN1cnJlbnQgdmVyc2lvbiBsaW1pdHMgdGhlIHF1ZXJ5IHJlc3BvbnNlIG1lc3NhZ2UgdHJhbnNm ZXIgZGlyZWN0aW9uIA0KICAgIG9ubHkgZnJvbSBGRSB0byBDRS4NCiZsdDsvdCZndDsNCiAgICAN CiZsdDt0IGhhbmdUZXh0PSAiTWVzc2FnZSBIZWFkZXI6ICAiJmd0OyZsdDt2c3BhY2UgLyZndDsN ClRoZSBNZXNzYWdlIFR5cGUgaW4gdGhlIGhlYWRlciBpcyBzZXQgdG8gTWVzc2FnZVR5cGU9ICdR dWVyeVJlc3BvbnNlJy4gDQogICAgVGhlIEFDSyBmbGFnIGluIHRoZSBoZWFkZXIgU0hPVUxEIGJl IHNldCAnTm9BQ0snLCBtZWFuaW5nIG5vIGZ1cnRoZXIgDQogICAgcmVzcG9uc2UgZm9yIGEgcXVl cnkgcmVzcG9uc2UgbWVzc2FnZSBpcyBleHBlY3RlZC4gSWYgdGhlIEFDSyBmbGFnIGlzIA0KICAg IHNldCBvdGhlciB2YWx1ZXMsIHRoZSBtZWFuaW5nIG9mIHRoZSBmbGFnIHdpbGwgdGhlbiBiZSAN CiAgICBpZ25vcmVkLiBUaGUgU2VxdWVuY2UgTnVtYmVyIGluIHRoZSBoZWFkZXIgU0hPVUxEIGtl ZXAgdGhlIHNhbWUgYXMgDQogICAgdGhhdCBvZiB0aGUgcXVlcnkgbWVzc2FnZSB0byBiZSByZXNw b25kZWQsIHNvIHRoYXQgdGhlIHF1ZXJ5IG1lc3NhZ2UgDQogICAgc2VuZGVyIGNhbiBrZWVwIHRy YWNrIG9mIHRoZSByZXNwb25zZXMuIA0KJmx0Oy90Jmd0Ow0KICAgIA0KJmx0O3QgaGFuZ1RleHQ9 ICJNZXNzYWdlIGJvZHk6ICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KVGhlIG1lc3NhZ2UgYm9keSBm b3IgYSBxdWVyeSByZXNwb25zZSBtZXNzYWdlIGNvbnNpc3RzIG9mIChhdCBsZWFzdCkgDQogICAg b25lIG9yIG1vcmUgdGhhbiBvbmUgVExWcyB0aGF0IGRlc2NyaWJlIHF1ZXJ5IHJlc3VsdHMgZm9y IGluZGl2aWR1YWwgDQogICAgcXVlcmllZCBlbnRyaWVzLiBUaGUgVExWIGlzIGFsc28gY2FsbGVk IExGQnNlbGVjdCBUTFYsIGFuZCBoYXMgZXhhY3RseSANCiAgICB0aGUgc2FtZSBkYXRhIGZvcm1h dCBhcyBxdWVyeSBtZXNzYWdlLCBleGNlcHQgdGhlIE9wZXJhdGlvbiBUTFYgaW5zaWRlDQogICAg dGhlIFRMViBjb21wcmlzZXMgdGhlICdRdWVyeSBSZXNwb25zZSBEYXRhJywgaW5zdGVhZCBvZiB0 aGUgJ1F1ZXJ5IERhdGEnLA0KICAgIGFzIGJlbG93Og0KJmx0Oy90Jmd0Ow0KDQombHQ7ZmlndXJl IGFuY2hvcj0ibXNnX1F1ZXJ5X1Jlc3BvbnNlIiZndDsNCiZsdDthcnR3b3JrJmd0Ow0KICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgICB8ICAgIFR5cGUgPSBPcGVyYXRpb25zIChHRVQpICAgIHwgICAgICAgICAg ICAgICBMZW5ndGggICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgUGF0aChvciBBdHRyaWJ1dGUgSUQ/KSAgICAgICAgICAgICAgICAgIHwNCiAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIFF1ZXJ5IFJlc3BvbnNl IERhdGEgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiZsdDsvYXJ0d29yayZndDsNCiZsdDsvZmlndXJlJmd0Ow0KICA8L1BSRT48L0JMT0NLUVVPVEU+ WW91IHNob3VsZCBzcGVjaWZ5IGhlcmUgdGhhdCB0aGUgb3JkZXIgb2YgdGhlIFRMViBpbiB0aGUg DQogIFF1ZXJ5LVJlcG9uc2UgbWF0Y2hlcyB0aGUgVExWcyBpbiB0aGUgUXVlcnkuIFNvIHRoZXJl IGlzIGFsd2F5cyB0aGUgc2FtZSANCiAgbnVtYmVyIG9mIFRMVnMgaW4gdGhlIHJlc3BvbnNlIGFz IGluIHRoZSBxdWVyeS48QlI+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0yPk9LLjwvRk9OVD48 QlI+U2lkZSBub3RlOiB3ZSBoYXZlIG5vdCB5ZXQgcmVzb2x2ZWQgdGhlIHVzZSBvZiBhIA0KICB0 cmFuc2FjdGlvbiBvciBzZXF1ZW5jZSBudW1iZXIgdGhhdCB3aWxsIGJlIHVzZWQgZm9yIGVhY2gg UEwgbWVzc2FnZS48QlI+PEJSPg0KICA8QkxPQ0tRVU9URSBjaXRlPW1pZDEwODcwMWM0Yjg0YSQ4 MDI4YmE2MCQ4NDVjMjFkMkBOZWNvbS5oemljLmVkdS5jbiANCiAgdHlwZT0iY2l0ZSI+PFBSRSB3 cmFwPSIiPiANCiZsdDt0IGhhbmdUZXh0PSAiUXVlcnkgUmVzcG9uc2UgRGF0YTogIiZndDsmbHQ7 dnNwYWNlIC8mZ3Q7DQpbVW5kZXIgZGlzY3Vzc2lvbiBhbmQgVEJEXQ0KJmx0Oy90Jmd0Ow0KJmx0 Oy9saXN0Jmd0Ow0KICAgIA0KJmx0Oy9zZWN0aW9uJmd0Ow0KJmx0Oy9zZWN0aW9uJmd0Ow0KDQom bHQ7IS0tICRMb2c6IFF1ZXJ5TXNnLnhtbCx2ICQNCiZsdDshLS0gUmV3cml0dGVuIGJ5IFdlaW1p bmcgV2FuZyAyMDA0LzEwLzIyDQombHQ7IS0tIEluY29ycGFyYXRlIExGQnNlbGVjdCBhbmQgT3Bl cmF0aW9uIFRMViANCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS4xMCAgMjAwNC8xMC8yMCAx NDo0OTozNiAgYXZyaQ0KJmx0OyEtLSBDaGFuZ2VzIGZvciBkcmFmdC1pZXRmLWZvcmNlcy1wcm90 b2NvbC0wMA0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZpc2lvbiAxLjkgIDIwMDQvMDcvMTkgMDk6Mzc6 MjIgIGF2cmkNCiZsdDshLS0gVmVyc2lvbiAyIGNoZWNraW4NCiZsdDshLS0NCiZsdDshLS0gUmV2 aXNpb24gMS44ICAyMDA0LzA2LzIzIDA1OjA1OjQ3ICBhdnJpDQombHQ7IS0tIGZpbmFsIGVkaXRz IGZvciAwMA0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZpc2lvbiAxLjcgIDIwMDQvMDYvMjIgMDY6NTQ6 MTcgIGF2cmkNCiZsdDshLS0gUmVtb3ZlDQombHQ7IS0tDQombHQ7IS0tIFJldmlzaW9uIDEuNiAg MjAwNC8wNi8yMiAwNjo1MjozMyAgYXZyaQ0KJmx0OyEtLSBJbmNvcnBvcmF0ZSBXVyBjaGFuZ2Vz DQombHQ7IS0tIEluY2x1ZGUgdGVhbSBlZGl0cyBvbiAwMC03DQombHQ7IS0tDQombHQ7IS0tIFJl dmlzaW9uIDEuMiAgMjAwNC0wNi0yMSAyMTo0MDoyNSswOCAgYWRtaW5pc3RyYXRvcg0KJmx0OyEt LSBJbmNvcnBhcmF0ZSBzb21lIGNvbW1lbnRzIGZyb20gSmFtYWwgKEp1bmUgMjEsIDIwMDQgMTA6 NTAgQU0pLiAtV2VpbWluZw0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZpc2lvbiAxLjEgIDIwMDQtMDYt MjEgMjA6MzY6NDArMDggIGFkbWluaXN0cmF0b3INCiZsdDshLS0gcmV2aXNpb24gaGFuZGVkIGZy b20gQXZyaQ0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZpc2lvbiAxLjUgIDIwMDQvMDYvMTkgMTM6MTI6 MzMgIGF2cmkNCiZsdDshLS0gZm9ybWF0dGluZw0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZpc2lvbiAx LjQgIDIwMDQvMDYvMTkgMTM6MDM6MDMgIGF2cmkNCiZsdDshLS0gZml4IGNyb3NzIHJlZmVyZW5j ZQ0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZpc2lvbiAxLjMgIDIwMDQvMDYvMTkgMTI6MjE6MTEgIGF2 cmkNCiZsdDshLS0gLSBjaGFuZ2UgRW5jb2RpbmdUeXBlIHRvIFR5cGUgKGZyb20gV1cpDQombHQ7 IS0tIC0gZml4IGZvcm1hdGluZw0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZpc2lvbiAxLjIgIDIwMDQv MDYvMTcgMDM6NDM6NDcgIGF2cmkNCiZsdDshLS0gUmVwbGFjZSB3aXRoIG5ldyBXVyBmaWxlcw0K Jmx0OyEtLQ0KICAgIGVkaXRlZCB3aXRoICZsdDtPWHlnZW4vJmd0O1hNTCBlZGl0b3IgNC4xLCBi eSBXZWltaW5nIFdhbmcgJmFtcDtMaWdhbmcgRG9uZyANCiAgICAgKioqIFF1ZXJ5TXNnIFYxLjAs IDIwMDQtMDYtMTMsIGNoYW5nZXMgc2luY2UgbGFzdCB2ZXJzaW9uOg0KICAgICAtIE5vbmUsIGFz IHRoZSBvcmlnaW5hbCB2ZXJzaW9uLg0KLS0mZ3Q7DQogIDwvUFJFPjxQUkUgd3JhcD0iIj4mbHQ7 P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Jmd0Ow0KJmx0OyEtLSBlZGl0ZWQg d2l0aCAmbHQ7T1h5Z2VuLyZndDtYTUwgZWRpdG9yIDQuMSwgYnkgV2VpbWluZyBXYW5nICZhbXA7 TGlnYW5nIERvbmcgDQogICAgICoqKiBFdmVudE1zZyBWMS4wLCAyMDA0LTA2LTEzLCBjaGFuZ2Vz IHNpbmNlIGxhc3QgdmVyc2lvbjoNCiAgICAgLSBOb25lLCBhcyB0aGUgb3JpZ2luYWwgdmVyc2lv bi4NCiAgICAgKioqIEV2ZW50TXNnVjEuMSwgMjAwNC0wNi0xODoNCiAgICAgLSBjaGFuZ2UgRW5j b2RpbmdUeXBlIHRvIFR5cGUuDQotLSZndDsNCg0KJmx0O3NlY3Rpb24gYW5jaG9yPSJFdmVudE1z ZyIgdGl0bGU9IkV2ZW50IE5vdGlmaWNhdGlvbiBhbmQgUmVzcG9uc2UgTWVzc2FnZXMiJmd0Ow0K DQombHQ7dCZndDtUaGUgRXZlbnQgTm90aWZpY2F0aW9uIE1lc3NhZ2UgaXMgdXNlZCBmb3Igb25l IEZvckNFUyBlbGVtZW50IA0KICAgIHRvIGFzeW5jaHJvbm91c2x5IG5vdGlmeSBvbmUgb3IgbW9y ZSBvdGhlciBGb3JDRVMgZWxlbWVudHMgDQogICAgaW4gdGhlIHNhbWUgRm9yQ0VTIE5FIG9uIGp1 c3QgaGFwcGVuZWQgZXZlbnRzIGluIGl0LiBUaGUgDQogICAgRXZlbnQgTm90aWZpY2F0aW9uIFJl c3BvbnNlIE1lc3NhZ2UgaXMgdXNlZCBmb3IgdGhlIHJlY2VpdmVyIA0KICAgIG9mIHRoZSBFdmVu dCBOb3RpZmljYXRpb24gTWVzc2FnZSB0byBhY2tub3dsZWRnZSB0aGUgcmVjZXB0aW9uIA0KICAg IG9mIHRoZSBldmVudCBub3RpZmljYXRpb24uJmx0Oy90Jmd0Ow0KDQombHQ7dCZndDtFdmVudHMg aW4gY3VycmVudCBGb3JDRVMgcHJvdG9jb2wgY2FuIGJlIGNhdGVnb3JpemVkIGludG8gZm9sbG93 aW5nIHR5cGVzOiZsdDsvdCZndDsNCiZsdDt0Jmd0OyZsdDtsaXN0IHN0eWxlPSJzeW1ib2xzIiZn dDsNCiZsdDt0Jmd0O0V2ZW50cyBoYXBwZW5lZCBpbiBDRSZsdDsvdCZndDsNCiZsdDt0Jmd0O0V2 ZW50cyBoYXBwZW5lZCBpbiBGRSZsdDsvdCZndDsNCiAgPC9QUkU+PC9CTE9DS1FVT1RFPg0KICA8 RElWPldoeSBkb2VzIHRoaXMgbWF0dGVyIGZvciB0aGUgcHJvdG9jb2wgPzwvRElWPg0KICA8RElW PltXXSB5ZXMsIGl0IG1hdHRlcnMuIGFjdHVhbGx5IEkgc3RpbGwgaGF2ZSBub3QgZGVmaW5lZCB0 aGUgbWVzc2FnZSBmb3JtYXQgDQogIGZvciBDRSBldmVudHMuIEknbSBzdXJlIHRoZSBkZWZpbml0 aW9uIHNob3VsZCBiZSBkaWZmZXJlbnQgZm9yIHRoZSBMRkJzLjwvRElWPg0KICA8RElWPklmIHRo ZSBDRS1MRkIgdGhvdWdodCBjYW4gcHJvY2VlZCBtb3JlLCBpdCB3aWxsIGhlbHAgdGhlIGRlZmlu aXRpb24gDQogIGhlcmUuPEJSPjwvRElWPg0KICA8QkxPQ0tRVU9URSBjaXRlPW1pZDEwODcwMWM0 Yjg0YSQ4MDI4YmE2MCQ4NDVjMjFkMkBOZWNvbS5oemljLmVkdS5jbiANCiAgdHlwZT0iY2l0ZSI+ PFBSRSB3cmFwPSIiPiZsdDsvbGlzdCZndDsmbHQ7L3QmZ3Q7DQoNCiZsdDt0Jmd0O0V2ZW50cyBj YW4gYWxzbyBiZSBjYXRlZ29yaXplZCBpbnRvIHR3byBjbGFzc2VzIGFjY29yZGluZyB0byANCiAg ICB3aGV0aGVyIHRoZXkgbmVlZCBzdWJzY3JpcHRpb24gb3Igbm90LiBBbiBldmVudCBpbiBvbmUg Rm9yQ0VTIA0KICAgIGVsZW1lbnQgdGhhdCBuZWVkcyB0byBiZSBzdWJzY3JpYmVkIHdpbGwgc2Vu ZCBub3RpZmljYXRpb25zIHRvIA0KICAgIG90aGVyIEZvckNFUyBlbGVtZW50cyBvbmx5IHdoZW4g dGhlIG90aGVyIGVsZW1lbnRzIGhhdmUgc3Vic2NyaWJlZCANCiAgICB0byB0aGUgZWxlbWVudCBm b3IgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbi4gSG93IHRvIA0KICAgIHN1YnNjcmliZS91bnN1YnNj cmliZSBmb3IgYW4gZXZlbnQgaXMgZGVzY3JpYmVkIGluIHRoZSBDb25maWd1cmUgDQogICAgTWVz c2FnZSBpbiBTZWN0aW9uIDYuMy4gQW4gZXZlbnQgdGhhdCBuZWVkcyBub3QgdG8gYmUgc3Vic2Ny aWJlZCANCiAgICB3aWxsIGFsd2F5cyBzZW5kIG5vdGlmaWNhdGlvbnMgdG8gb3RoZXIgRm9yQ0VT IGVsZW1lbnRzIHdoZW4gdGhlIA0KICAgIGV2ZW50IGhhcHBlbnMuIEFuIGV2ZW50IGRlZmluaXRp b24gbWFkZSBieSBGb3JDRVMgcHJvdG9jb2wsIEZvckNFUyANCiAgICBGRSBtb2RlbCwgb3IgYnkg dmVuZG9ycyB3aWxsIHN0YXRlIGlmIHRoZSBldmVudCBuZWVkcyBzdWJzY3JpcHRpb24gb3Igbm90 LiZsdDsvdCZndDsNCiZsdDt2c3BhY2UgYmxhbmtMaW5lcz0iMSIgLyZndDsNCiZsdDtsaXN0IHN0 eWxlPSJoYW5naW5nIiBoYW5nSW5kZW50PSIxNyIgJmd0Ow0KJmx0O3QgaGFuZ1RleHQ9IkVkaXRv cmlhbCBOb3RlOiAiICZndDsNClRoZXJlIGlzIGFuIGFyZ3VtZW50IHRoYXQgaXQgaXMgcHJlZmVy YWJsZSB0byBoYXZlIA0KYWxsIGV2ZW50cyBzdWJzY3JpYmFibGUuDQombHQ7L3QmZ3Q7DQombHQ7 L2xpc3QmZ3Q7DQoNCg0KJmx0O3NlY3Rpb24gdGl0bGU9IkV2ZW50IE5vdGlmaWNhdGlvbiBNZXNz YWdlIiZndDsNCg0KJmx0O3QmZ3Q7QXMgdXN1YWwsIGFuIEV2ZW50IE5vdGlmaWNhdGlvbiBNZXNz YWdlIGlzIGNvbXBvc2VkIG9mIGEgY29tbW9uIA0KICAgIGhlYWRlciBhbmQgYSBtZXNzYWdlIGJv ZHkgdGhhdCBjb25zaXN0cyBvZiBvbmUgb3IgbW9yZSBUTFYgZGF0YSANCiAgICBmb3JtYXQuIERl dGFpbGVkIGRlc2NyaXB0aW9uIG9mIHRoZSBtZXNzYWdlIGlzIGFzIGJlbG93LiZsdDsvdCZndDsN CiZsdDtsaXN0IHN0eWxlPSJoYW5naW5nIiBoYW5nSW5kZW50PSIxIiZndDsNCiZsdDt0IGhhbmdU ZXh0PSAiTWVzc2FnZSBUcmFuc2ZlciBEaXJlY3Rpb246ICAiJmd0OyZsdDt2c3BhY2UgLyZndDsN CkZFIHRvIENFLCBvciBDRSB0byBGRQ0KJmx0Oy90Jmd0Ow0KDQoNCiZsdDt0IGhhbmdUZXh0PSAi TWVzc2FnZSBIZWFkZXI6ICAiJmd0OyZsdDt2c3BhY2UgLyZndDsNClRoZSBNZXNzYWdlIFR5cGUg aW4gdGhlIG1lc3NhZ2UgaGVhZGVyIGlzIHNldCB0byAmbHQ7dnNwYWNlIC8mZ3Q7DQogICAgTWVz c2FnZVR5cGUgPSAnRXZlbnROb3RpZmljYXRpb24nLiBUaGUgQUNLIGZsYWcgaW4gdGhlIGhlYWRl ciANCiAgICBjYW4gYmUgc2V0IGFzOiBBQ0sgZmxhZyA9J05vQUNLJ3wnU3VjY2Vzc0Fjayd8J1Vu c3VjY2Vzc0FDSyd8J0FDS0FsbCcuIA0KICAgIE5vdGUgdGhhdCB0aGUgJ1N1Y2Nlc3MnIGhlcmUg b25seSBtZWFucyB0aGUgcmVjZWl2ZXIgb2YgdGhlIG1lc3NhZ2UgDQogICAgaGFzIHN1Y2Nlc3Nm dWxseSByZWNlaXZlZCB0aGUgbWVzc2FnZS4NCiZsdDsvdCZndDsNCg0KDQombHQ7dCBoYW5nVGV4 dD0gIk1lc3NhZ2UgQm9keTogIiZndDsmbHQ7dnNwYWNlIC8mZ3Q7DQpUaGUgbWVzc2FnZSBib2R5 IGZvciBhbiBldmVudCBub3RpZmljYXRpb24gbWVzc2FnZSBjb25zaXN0cyANCiAgICBvZiAoYXQg bGVhc3QpIG9uZSBvciBtb3JlIHRoYW4gb25lIFRMVnMgdGhhdCBkZXNjcmliZSB0aGUgDQogICAg bm90aWZpZWQgZXZlbnRzLiBUaGUgVExWIGlzIGRlZmluZWQgYXMgZm9sbG93czoNCiZsdDt2c3Bh Y2UgYmxhbmtMaW5lcz0iMSIgLyZndDsNCiZsdDsvdCZndDsNCg0KJmx0O2ZpZ3VyZSBhbmNob3I9 InRsdl9FdmVudF9Ob3RpZmljYXRpb24iJmd0Ow0KJmx0O2FydHdvcmsmZ3Q7DQogICAgICAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDENCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgVHlwZSA9IExGQnNlbGVjdCAgICAgICB8 ICAgICAgICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgTEZCIENsYXNzIElEICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIExGQiBJ bnN0YW5jZSBJRCAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdGlvaW4gVExWICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfiAgICAgICAgICAg ICAgICAgICAgICAgICAgIC4uLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4NCiAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIE9wZXJhdGlvaW4gVExW ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiANCiZsdDsvYXJ0d29yayZndDsmbHQ7L2ZpZ3VyZSZndDsNCg0KJmx0O3QgaGFuZ1RleHQ9ICJP cGVyYXRpb24gVExWOiAiJmd0OyZsdDt2c3BhY2UgLyZndDsNClRoaXMgaXMgYSBUTFYgdGhhdCBk ZXNjcmliZXMgdGhlIGV2ZW50IHRvIGJlIG5vdGlmaWVkLCBhcyBmb2xsb3dzOg0KJmx0Oy90Jmd0 Ow0KDQombHQ7ZmlndXJlIGFuY2hvcj0idGx2X0V2ZW50IiZndDsmbHQ7YXJ0d29yayZndDsNCiAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgICAgfCAgICBUeXBlID0gT3BlcmF0aW9ucyAoUkVQT1JUKSB8ICAgICAg ICAgICAgICAgTGVuZ3RoICAgICAgICAgIHwNCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgIFBhdGgob3IgRXZlbnQgSUQ/KSAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICBFdmVudCBE YXRhICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgLiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4NCiAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiZsdDsvYXJ0d29yayZndDsmbHQ7L2ZpZ3VyZSZndDsNCiZsdDt0IGhhbmdUZXh0PSAiUGF0 aChvciBFdmVudCBJRCk6ICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KW1VuZGVyIGRpc2N1c3Npb24g YW5kIFRCRF0NCiZsdDsvdCZndDsNCg0KJmx0O3QgaGFuZ1RleHQ9ICJFdmVudCBEYXRhOiAiJmd0 OyZsdDt2c3BhY2UgLyZndDsNCiAgICBbVW5kZXIgZGlzY3Vzc2lvbiBhbmQgVEJEXQ0KJmx0Oy90 Jmd0Ow0KJmx0Oy9saXN0Jmd0Ow0KJmx0O3QmZ3Q7VG8gYmV0dGVyIHVuZGVyc3RhbmQgdGhlIGFi b3ZlIFBEVSBmb3JtYXQsIHdlIGNhbiBzaG93IGEgdHJlZSBzdHJ1Y3R1cmUgZm9yIHRoZSANCiAg ICBmb3JtYXQgYXMgYmVsb3c6DQombHQ7ZmlndXJlJmd0Ow0KbWFpbiBoZHIgKHR5cGUgPSBFdmVu dCBOb3RpZmljYXRpb24pDQogICAgIHwNCiAgICAgfA0KICAgICArLS0tIFQgPSBMRkJzZWxlY3QN CiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gTEZCQ0xBU1NJRCA9IHRhcmdldCBM RkIgY2xhc3MNCiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICB8DQogICAgIHwgICAgICAg ICstLSBMRkJJbnN0YW5jZSA9IHRhcmdldCBMRkIgaW5zdGFuY2UgDQogICAgIHwgICAgICAgIHwN CiAgICAgfCAgICAgICAgfA0KICAgICB8ICAgICAgICArLS0gVCA9IG9wZXJhdGlvbiB7IFJFUE9S VCB9DQogICAgIHwgICAgICAgIHwgICB8DQogICAgIHwgICAgICAgIHwgICArLS0gIC8vIG9uZSBv ciBtb3JlIHBhdGggdGFyZ2V0cyANCiAgICAgfCAgICAgICAgfCAgICAgICAgLy8gdW5kZXIgZGlz Y3Vzc2lvbg0KICAgICB8ICAgICAgICArLS0gVCA9IG9wZXJhdGlvbiB7IFJFUE9SVCB9DQogICAg IHwgICAgICAgIHwgICB8DQogICAgIHwgICAgICAgIHwgICArLS0gIC8vIG9uZSBvciBtb3JlIHBh dGggdGFyZ2V0cyANCiAgICAgfCAgICAgICAgfCANCg0KJmx0Oy9maWd1cmUmZ3Q7DQombHQ7L2xp c3QmZ3Q7DQombHQ7L3NlY3Rpb24mZ3Q7DQoNCiZsdDtzZWN0aW9uIHRpdGxlPSJFdmVudCBOb3Rp ZmljYXRpb24gUmVzcG9uc2UgTWVzc2FnZSImZ3Q7DQoNCiZsdDt0Jmd0O0FmdGVyIHNlbmRpbmcg b3V0IGFuIEV2ZW50IE5vdGlmaWNhdGlvbiBNZXNzYWdlLCB0aGUgc2VuZGVyIG1heSANCiAgICBi ZSBpbnRlcmVzdGVkIGluIGVuc3VyaW5nIHRoYXQgdGhlIG1lc3NhZ2UgaGFzIGJlZW4gcmVjZWl2 ZWQgDQogICAgYnkgcmVjZWl2ZXJzLCBlc3BlY2lhbGx5IHdoZW4gdGhlIHNlbmRlciB0aGlua3Mg dGhlIGV2ZW50IA0KICAgIG5vdGlmaWNhdGlvbiBpcyB2aXRhbCBmb3Igc3lzdGVtIG1hbmFnZW1l bnQuIEFuIEV2ZW50IA0KICAgIE5vdGlmaWNhdGlvbiBSZXNwb25zZSBNZXNzYWdlIGlzIHVzZWQg Zm9yIHRoaXMgcHVycG9zZS4gVGhlIA0KICAgIEFDSyBmbGFnIGluIHRoZSBFdmVudCBOb3RpZmlj YXRpb24gTWVzc2FnZSBoZWFkZXIgYXJlIHVzZWQgdG8gDQogICAgc2lnbmFsIGlmIHN1Y2ggYWNr bm93bGVkZ2UgaXMgcmVxdWVzdGVkIG9yIG5vdCBieSB0aGUgc2VuZGVyLiZsdDsvdCZndDsgDQoN CiZsdDt0Jmd0O0RldGFpbGVkIGRlc2NyaXB0aW9uIG9mIHRoZSBtZXNzYWdlIGlzIGFzIGJlbG93 OiZsdDsvdCZndDsNCiZsdDtsaXN0IHN0eWxlPSJoYW5naW5nIiBoYW5nSW5kZW50PSIxIiZndDsN CiZsdDt0IGhhbmdUZXh0PSAiTWVzc2FnZSBUcmFuc2ZlciBEaXJlY3Rpb246ICAiJmd0OyZsdDt2 c3BhY2UgLyZndDsNCiZndDtGcm9tIEZFIHRvIENFIG9yIGZyb20gQ0UgdG8gRkUsIGp1c3QgaW52 ZXJzZSB0byB0aGUgDQogICAgZGlyZWN0aW9uIG9mIHRoZSBFdmVudCBOb3RpZmljYXRpb24gTWVz c2FnZSB0aGF0IGl0IHJlc3BvbnNlcy4NCiZsdDsvdCZndDsNCg0KDQombHQ7dCBoYW5nVGV4dD0g Ik1lc3NhZ2UgSGVhZGVyOiAgIiZndDsmbHQ7dnNwYWNlIC8mZ3Q7DQpUaGUgTWVzc2FnZSBUeXBl IGluIHRoZSBoZWFkZXIgaXMgc2V0IA0KICAgIE1lc3NhZ2VUeXBlPSAnRXZlbnROb3RpZmljYXRp b25SZXNwb25zZScuIFRoZSBBQ0sgZmxhZyBpbiB0aGUgDQogICAgaGVhZGVyIFNIT1VMRCBiZSBz ZXQgJ05vQUNLJywgbWVhbmluZyBubyBmdXJ0aGVyIHJlc3BvbnNlIGZvciANCiAgICB0aGUgbWVz c2FnZSBpcyBleHBlY3RlZC4gSWYgdGhlIEFDSyBmbGFnIGlzIHNldCBvdGhlciB2YWx1ZXMsIA0K ICAgIHRoZSBtZWFuaW5nIG9mIHRoZSBmbGFnIHdpbGwgdGhlbiBiZSBpZ25vcmVkLiANCiAgICBU aGUgU2VxdWVuY2UgTnVtYmVyIGluIHRoZSBoZWFkZXIgU0hPVUxEIGtlZXAgdGhlIHNhbWUgYXMg dGhhdCANCiAgICBvZiB0aGUgbWVzc2FnZSB0byBiZSByZXNwb25kZWQsIHNvIHRoYXQgdGhlIGV2 ZW50IG5vdGlmaWNhdGluIA0KICAgIG1lc3NhZ2Ugc2VuZGVyIGNhbiBrZWVwIHRyYWNrIG9mIHRo ZSByZXNwb25zZXMuDQombHQ7L3QmZ3Q7DQoNCiZsdDt0IGhhbmdUZXh0PSAiTWVzc2FnZSBCb2R5 OiAiJmd0OyZsdDt2c3BhY2UgLyZndDsNClRoZSBtZXNzYWdlIGJvZHkgZm9yIGFuIGV2ZW50IG5v dGlmaWNhdGlvbiBtZXNzYWdlIGNvbnNpc3RzIA0KICA8L1BSRT48L0JMT0NLUVVPVEU+Y29ycmVj dCBhYm92ZTogZXZlbnQgbm90aWZpY2F0aW9uICJyZXNwb25zZSIgbWVzc2FnZTxCUj4NCiAgPEJM T0NLUVVPVEUgY2l0ZT1taWQxMDg3MDFjNGI4NGEkODAyOGJhNjAkODQ1YzIxZDJATmVjb20uaHpp Yy5lZHUuY24gDQogIHR5cGU9ImNpdGUiPjxQUkUgd3JhcD0iIj4gICAgb2YgKGF0IGxlYXN0KSBv bmUgb3IgbW9yZSB0aGFuIG9uZSBUTFZzIHRoYXQgZGVzY3JpYmUgdGhlIA0KICAgIG5vdGlmaWVk IGV2ZW50cy4gVGhlIFRMViBpcyBhbHNvIGNhbGxlZCBMRkJzZWxlY3QgVExWLCBhbmQgaGFzIGV4 YWN0bHkgDQogICAgdGhlIHNhbWUgZGF0YSBmb3JtYXQgYXMgRXZlbnQgTm90aWZpY2F0aW9uIE1l c3NhZ2UsIGV4Y2VwdCB0aGUgT3BlcmF0aW9uIA0KICAgIFRMViBpbnNpZGUgdGhlIFRMViBjb21w cmlzZXMgdGhlIGV2ZW50IHJlc3BvbnNlIGRhdGEsIGluc3RlYWQgb2YgdGhlIA0KICAgICdFdmVu dCBEYXRhJywgYXMgYmVsb3c6DQogIDwvUFJFPjwvQkxPQ0tRVU9URT5BZ2FpbiwgeW91IHNob3Vs ZCBtZW50aW9uIHRoYXQgdGhlIGVhY2ggIk9wZXJhdGlvbiBUTFYiIA0KICBpbiB0aGUgcmVzcG9u c2UgY29ycmVzcG9uZHMgb25lLXRvLW9uZSB0byBhIFRMViBpbiB0aGUgbm90aWZpY2F0aW9uLjxC Uj4NCiAgPEJMT0NLUVVPVEUgY2l0ZT1taWQxMDg3MDFjNGI4NGEkODAyOGJhNjAkODQ1YzIxZDJA TmVjb20uaHppYy5lZHUuY24gDQogIHR5cGU9ImNpdGUiPjxQUkUgd3JhcD0iIj4mbHQ7dnNwYWNl IGJsYW5rTGluZXM9IjEiIC8mZ3Q7DQoNCiZsdDtmaWd1cmUgYW5jaG9yPSJ0bHZfUmVwc29uc2Vf UmVzdWx0IiZndDsNCiZsdDtwcmVhbWJsZSZndDsNClRoaXMgY29udGFpbnMgYSBUTFYgdGhhdCBk ZXNjcmliZSB0aGUgcmVzcG9uc2UgcmVzdWx0IA0KICAgIGFzIGJlbG93Og0KJmx0Oy9wcmVhbWJs ZSZndDsNCiZsdDthcnR3b3JrJmd0Ow0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgIFR5cGUgPSBP cGVyYXRpb25zIChSRVBPUlQpIHwgICAgICAgICAgICAgICBMZW5ndGggICAgICAgICAgfA0KICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgUGF0aChvciBFdmVudCBJ RD8pICAgICAgICAgICAgICAgICAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICB8ICAgIFJlc3Vs dCAgICAgfCAgIFJlYXNvbiAgICAgIHwgICAgICAgICBDb2RlICAgICAgICAgICAgICAgICAgfA0K ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQombHQ7L2FydHdvcmsmZ3Q7Jmx0Oy9maWd1cmUmZ3Q7DQombHQ7dCBo YW5nVGV4dD0gIlBhdGgob3IgRXZlbnQgSUQ/KTogIiZndDsmbHQ7dnNwYWNlIC8mZ3Q7DQpbVW5k ZXIgZGlzY3Vzc2lvbiBhbmQgVEJEXQ0KJmx0Oy90Jmd0Ow0KJmx0O3QgaGFuZ1RleHQ9ICJSZXN1 bHQ6ICImZ3Q7Jmx0O3ZzcGFjZSAvJmd0Ow0KVGhpcyBkZXNjcmliZXMgdGhlIHJlY2VwdGlvbiBy ZXN1bHQgb2YgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiANCiAgICBtZXNzYWdlIGFzIGJlbG93Og0K Jmx0Oy90Jmd0Ow0KJmx0O2ZpZ3VyZSZndDsmbHQ7YXJ0d29yayZndDsNCglSZXN1bHQgVmFsdWUg ICAgICAgICAgICAgTWVhbmluZw0KCSdTdWNjZXNzJyAgICAgICBUaGUgZXZlbnQgaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHJlY2VpdmVkLg0KCSdVbnN1Y2Nlc3MnICAgICBUaGUgZXZlbnQgaGFzIG5v dCBiZWVuIHN1Y2Nlc3NmdWxseSByZWNlaXZlZC4NCiZsdDsvYXJ0d29yayZndDsmbHQ7L2ZpZ3Vy ZSZndDsNCg0KJmx0O3QgaGFuZ1RleHQ9ICJSZWFzb24sIENvZGU6ICImZ3Q7Jmx0O3ZzcGFjZSAv Jmd0Ow0KVGhpcyBkZXNjcmliZXMgdGhlIHJlYXNvbiBhbmQgcG9zc2libGUgZXJyb3IgY29kZSB3 aGVuIA0KICAgIHRoZSBtZXNzYWdlIGlzIG5vdCBzdWNjZXNzZnVsbHkgcmVjZWl2ZWQuIE5vdGUg dGhhdCBvbmx5IHRoZSANCiAgICBmYWlsdXJlIGF0IHRoZSBwcm90b2NvbCBsYXllciByYXRoZXIg dGhhbiB0aGUgdHJhbnNwb3J0IGxheWVyIA0KICAgIGNhbiBiZSBhbGxvY2F0ZWQgaGVyZSw8L1BS RT48L0JMT0NLUVVPVEU+dHlwbzogbm90ICJhbGxvY2F0ZWQiIGJ1dCANCiAgImhhbmRsZWQiLjxC Uj4NCiAgPEJMT0NLUVVPVEUgY2l0ZT1taWQxMDg3MDFjNGI4NGEkODAyOGJhNjAkODQ1YzIxZDJA TmVjb20uaHppYy5lZHUuY24gDQogIHR5cGU9ImNpdGUiPjxQUkUgd3JhcD0iIj4gdGhhdCBpcywg aWYgZXZlbiB0aGUgaGVhZGVyIHBhcnQgb2YgdGhlIA0KICAgIG1lc3NhZ2UgdG8gYmUgcmVzcG9u ZGVkIGNhbiBub3QgYmUgY29ycmVjdGx5IHJlY2VpdmVkLCB0aGUgDQogICAgcmVzcG9uc2UgdG8g dGhlIG1lc3NhZ2Ugd2lsbCBub3QgYmUgYWJsZSB0byBiZSBnZW5lcmF0ZWQgYnkgDQogICAgdGhl IHJlY2VpdmVyLg0KJmx0Oy90Jmd0Ow0KJmx0O3ZzcGFjZSBibGFua0xpbmVzPSIxIiAvJmd0Ow0K Jmx0O2xpc3Qgc3R5bGU9ImhhbmdpbmciIGhhbmdJbmRlbnQ9IjE3IiZndDsNCiZsdDt0IGhhbmdU ZXh0PSJFZGl0b3JpYWwgTm90ZTogIiZndDsgDQpUaGVyZSBpcyBhIGRlYmF0ZSBvbiB3aGV0aGVy IHRoZSBFdmVudCBOb3RpZmljYXRpb24gDQogICAgUmVzcG9uc2UgTWVzc2FnZSBpcyBuZWNlc3Nh cnkgb3Igbm90LiBUaGUgcHJvIGZvciBpdCBpcyBzb21lIGV2ZW50IA0KICAgIG5vdGlmaWNhdGlv biBzZW5kZXJzIG1heSBiZSBpbnRlcmVzdGVkIGluIGtub3dpbmcgaWYgcmVjZWl2ZXJzIA0KICAg IGhhdmUgaGFkIHN1Y2Nlc3MvdW5zdWNjZXNzIHJlY2VwdGlvbnMgb2YgdGhlIGV2ZW50cyBvciBu b3QuIEFuIA0KICAgIGFsdGVybmF0aXZlIHRvIGdlbmVyYXRlIHN1Y2ggcmVzcG9uc2UgaXMgZm9y IHRoZSBwcm90b2NvbCB0byANCiAgICBkZWZpbmUgYSB1bml2ZXJzYWwgQUNLIG1lc3NhZ2Ugc28g dGhhdCBpdCBjYW4gYWN0IGFzIHJlc3BvbnNlcyANCiAgICBmb3IgYW55IHR5cGVzIG9mIG1lc3Nh Z2VzIGFzIHdlbGwgYXMgdGhlIGV2ZW50IG5vdGlmaWNhdGlvbiANCiAgICBtZXNzYWdlcywgd2hl biB0aGUgbWVzc2FnZSBzZW5kZXJzIGFyZSBpbnRlcmVzdGVkIGluIGtub3dpbmcgDQogICAgd2hl dGhlciB0aGUgbWVzc2FnZXMgaGF2ZSBiZWVuIHN1Y2Nlc3NmdWxseSByZWNlaXZlZCBvciBub3Qg DQogICAgKGRpZmZlcmVudCBmcm9tIHRoZSByZXNwb25zZXMgZm9yIHRoZSBtZXNzYWdlIHByb2Nl c3NpbmcgcmVzdWx0cykuDQombHQ7L3QmZ3Q7IA0KJmx0Oy9saXN0Jmd0Ow0KJmx0Oy9saXN0Jmd0 Ow0KJmx0Oy9zZWN0aW9uJmd0Ow0KJmx0Oy9zZWN0aW9uJmd0Ow0KDQombHQ7IS0tICRMb2c6IEV2 ZW50TXNnLnhtbCx2ICQNCiZsdDshLS0gUmV3cml0dGVuIGJ5IFdlaW1pbmcgV2FuZyAyMDA0LzEw LzIyDQombHQ7IS0tIEluY29ycGFyYXRlIExGQnNlbGVjdCBhbmQgT3BlcmF0aW9uIFRMViANCiZs dDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS43ICAyMDA0LzA3LzE5IDA5OjM4OjE2ICBhdnJpDQom bHQ7IS0tIFZlcnNpb24gMiBjaGVja2luDQombHQ7IS0tDQombHQ7IS0tIFJldmlzaW9uIDEuNiAg MjAwNC8wNi8yMyAwNTowNToyMCAgYXZyaQ0KJmx0OyEtLSBmaW5hbCBlZGl0IGZvciAwMA0KJmx0 OyEtLQ0KJmx0OyEtLSBSZXZpc2lvbiAxLjUgIDIwMDQvMDYvMjIgMDY6NTk6MjMgIGF2cmkNCiZs dDshLS0gcmVtb3ZlDQombHQ7IS0tDQombHQ7IS0tIFJldmlzaW9uIDEuNCAgMjAwNC8wNi8yMiAw Njo1ODoyNSAgYXZyaQ0KJmx0OyEtLSBUZWFtIGVkaXRzIGZyb20gMDAtNw0KJmx0OyEtLQ0KJmx0 OyEtLSBSZXZpc2lvbiAxLjIgIDIwMDQtMDYtMjEgMjE6NDA6NTgrMDggIGFkbWluaXN0cmF0b3IN CiZsdDshLS0gSW5jb3JwYXJhdGUgc29tZSBjb21tZW50cyBmcm9tIEphbWFsIChKdW5lIDIxLCAy MDA0IDEwOjUwIEFNKS4gLVdlaW1pbmcNCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS4xICAy MDA0LTA2LTIxIDIxOjA3OjU0KzA4ICBhZG1pbmlzdHJhdG9yDQombHQ7IS0tIFJldmlzaW9uIGhh bmRlZCBmcm9tIEF2cmkgIC0gV2VpbWluZw0KJmx0OyEtLQ0KJmx0OyEtLSBSZXZpc2lvbiAxLjMg IDIwMDQvMDYvMTkgMTM6MTM6MzAgIGF2cmkNCiZsdDshLS0gRm9ybWF0dGluZw0KJmx0OyEtLQ0K Jmx0OyEtLSBSZXZpc2lvbiAxLjIgIDIwMDQvMDYvMTkgMTI6Mjk6NTIgIGF2cmkNCiZsdDshLS0g LSBjaGFuZ2UgRW5jb2RpbmdUeXBlIHRvIFR5cGUuIChmcm9tIFdXKQ0KJmx0OyEtLSBGaWNlIGZv cm1hdHRpbmcNCiZsdDshLS0NCiZsdDshLS0gUmV2aXNpb24gMS4xICAyMDA0LzA2LzE3IDAzOjQ1 OjAyICBhdnJpDQombHQ7IS0tIEluaXRpYWwgcmV2aXNpb24NCiZsdDshLS0NCiAgICAgZWRpdGVk IHdpdGggJmx0O09YeWdlbi8mZ3Q7WE1MIGVkaXRvciA0LjEsIGJ5IFdlaW1pbmcgV2FuZyAmYW1w O0xpZ2FuZyBEb25nDQogICAgICoqKiBFdmVudE1zZyBWMS4wLCAyMDA0LTA2LTEzLCBjaGFuZ2Vz IHNpbmNlIGxhc3QgdmVyc2lvbjoNCiAgICAgLSBOb25lLCBhcyB0aGUgb3JpZ2luYWwgdmVyc2lv bi4NCi0tJmd0Ow0KICA8L1BSRT48L0JMT0NLUVVPVEU+PEJSPjxQUkUgY2xhc3M9bW96LXNpZ25h dHVyZSBjb2xzPSI3MiI+LS0gDQpSb2JlcnQgSGFhcw0KSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJv cmF0b3J5DQpT5HVtZXJzdHJhc3NlIDQNCkNILTg4MDMgUvxzY2hsaWtvbi9Td2l0emVybGFuZA0K cGhvbmUgKzQxLTEtNzI0LTg2OTggIGZheCArNDEtMS03MjQtODU3OCAgPEEgY2xhc3M9bW96LXR4 dC1saW5rLWZyZWV0ZXh0IGhyZWY9Imh0dHA6Ly93d3cuenVyaWNoLmlibS5jb20vfnJoYSI+aHR0 cDovL3d3dy56dXJpY2guaWJtLmNvbS9+cmhhPC9BPjwvUFJFPg0KICA8UD4NCiAgPEhSPg0KDQog IDxQPjwvUD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxC Uj5Gb3JjZXMtcHJvdG9jb2wgDQogIG1haWxpbmcgDQogIGxpc3Q8QlI+Rm9yY2VzLXByb3RvY29s QGlldGYub3JnPEJSPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNl cy1wcm90b2NvbDxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_1150_01C4B911.F8A43470-- --===============1618796184== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1618796184==-- From forces-protocol-bounces@ietf.org Sat Oct 23 03:29:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05168 for ; Sat, 23 Oct 2004 03:29:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLGYH-00085k-Pf for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 03:43:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLGEs-0007U9-Gw; Sat, 23 Oct 2004 03:22:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLG6e-0004d1-Ld for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 03:14:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04355 for ; Sat, 23 Oct 2004 03:14:26 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLGI9-0007nO-RN for forces-protocol@ietf.org; Sat, 23 Oct 2004 03:27:53 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Sat, 23 Oct 2004 15:31:24 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Sat, 23 Oct 2004 15:07:32 +0800 Message-ID: <115c01c4b8cf$41ed5370$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> Subject: Re: [Forces-protocol] Header Section Date: Sat, 23 Oct 2004 15:09:27 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.9 (+++) X-Scan-Signature: 7b1e34d2462e88c1c4311f8189331c59 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, hadi@znyx.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 3.9 (+++) X-Scan-Signature: a8403cbbf1773e27474a13192645c46f Avri, Here is the updated xmls that incorparated comments from Robert. thanks. weiming begin 666 RedirectMsg.xml M/#]X;6P@=F5R6=E;B\^6$U,(&5D:71O2!M87D@2!O=&AE2!M87D@#0H@(" @ M;V-C87-I;VYA;&QY(&)E(&]T:&5R('!R;W1O8V]L('!A8VME=',L('=H:6-H M('5S=6%L;'D@:&%P<&5N( T*(" @('=H96X@0T4@86YD($9%(&%R92!J;VEN M=&QY(&EM<&QE;65N=&EN9R!S;VUE(&AI9V@M=&]U8V@@#0H@(" @;W!E2!O9B!T:&ES M('!A=&@@8F5I;F<@1&]3(&%T=&%C:V5D+B!!='1A8VME2!R961I2X@/"]T/@T*#0H\=G-P86-E(&)L86YK3&EN97,](C$B("\^#0H\ M;&ES="!S='EL93TB:&%N9VEN9R(@:&%N9TEN9&5N=#TB,3'0@/2 B161I=&]R:6%L($YO=&4Z("(^( T*5&AE'0@/2(@(" @(%1H;W5G:'0@,3H@ M(CX-"E1O(&1E9FEN92!,1D)S(&-A;&QE9" G4F5D:7)E8W13:6YK)R!A;F0@ M)U)E9&ER96-T5&%P)R!F;W(-"G!A8VME="!R961I2!O=&AE M2P@=&AE("=2961I2!T:&4@#0H@(" @ M)U)E8VER96-T5&%P)R!,1D(@86-T2!A(%-C:&5D=6QE2!B>2!A(&9O65R(&]R M(&5V96X@;F5T=V]R:R!L979E;"!H96%D97(@:7,@96YO=6=H+B!4:&4@2!M;W)E(&]R(&QE'0]("));G-T86YC92!)1#H@(CX\=G-P86-E("\^ M#0I);G-T86YC92!)1"!F;W(@=&AE("=2961I2!&12!M;V1E;"P@;W(@8F%S960@;VX@=F5N9&]R('-P96-I9FEC M871I;VYS( T*(" @(&EF('1H92!R961I2!7 M96EM:6YG(%=A;F<@,C P-"\Q,"\R,@T*/"$M+2!);F-O6=E;B\^6$U,(&5D:71O4US9U8Q+C$L(#(P,#0M,#8M,3@-"B @(" @+2!C:&%N9V4@16YC M;V1I;F=4>7!E('1O(%1Y<&4-"B @(" @*BHJ(%%U97)Y37-G5C$N,BP@,C P M-"TQ,"TR, T*(" @(" M(&9O4US9R(@=&ET;&4](E%U97)Y(&%N9"!1 M=65R>2!297-P;VYS92!-97-S86=E2!R97-P;VYS92!M97-S86=E2(@=&ET;&4](E%U97)Y($UE2!M97-S86=E(&ES(&-O;7!O M2!F'0](")-97-S86=E M($AE861E7!E(&EN('1H M92!H96%D97(@:7,@7!E/2 G475E2!M97-S86=E(&ES(&%L=V%Y'!E8W1E9"X@268@=&AE( T*(" @ M($%#2R!F;&%G(&ES('-E="!O=&AE'0@/2 B365S M2!M97-S86=E(&)O M9'D@8V]N'0@/2 B M161I=&]R:6%L($YO=&4Z("(^#0H\+W0^#0H\;&ES="!S='EL93TB;G5M8F5R M'!L:6-I="!M=6QT:7!L90T* M(" @3$9"(&EN7!E($QE;F=T:"!686QU90T* M(" @(" @("!4>7!E(#H]($E.4W-E;&5C= T*(" @(" @("!686QU92 Z/2!) M;G-T86YC94E$("A286YG94UA&9F9F9F9F9F)RP@=&AE('9A;'5E(&]F('=H:6-H(&ES('1H92!S86UE M(&%S( T*(" @($EN2!H97)E+CPO=#X-"CPO;&ES=#X@(" -"CPO;&ES=#X-"CQV2<@;65S7!E(#T@1T54(" @(" @ M(" @(" @(" @("!\(" @(" @(" @(" @(" @3&5N9W1H(" @(" @(" @('P- M"B @(" @*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK M+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2L-"B @(" @?" @(" @(" @(" @ M(" @(" @(" @(" @(%!A=&@H;W(@071T2!$871A(" @(" @(" @ M(" @(" @(" @(" @(" @('P-"B @(" @+B @(" @(" @(" @(" @(" @(" @ M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @("X- M"B @(" @*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK M+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2L-"B -"CPO87)T=V]R:SX\+V9I M9W5R93X-"CQT(&AA;F=497AT/2 B4&%T:"AO6QE M/2)H86YG:6YG(B!H86YG26YD96YT/2(Q-R(^#0H\="!H86YG5&5X=" ](")% M9&ET;W)I86P@3F]T93HB/B -"E1H97)E(&ES(&$@9&5B871E(&]N('=H971H M97(@=V4@2!S<&5C:69Y( T*(" @('=H:6-H(&%T M=')I8G5T92!O7!E(#T@475E2!297-P;VYS92!-97-S86=E(CX-"CQT/E=H96X@2!R97-U;'0N(%1H92!R96-E:79E2 -"B @("!R97-U;'0N($1E M=&%I;&5D(&1E6QE M/2 B:&%N9VEN9R(@:&%N9TEN9&5N=#TB-"(^#0H\="!H86YG5&5X=#T@(DUE M5)E'!E8W1E9"X@268@=&AE($%# M2R!F;&%G(&ES( T*(" @('-E="!O=&AE'0](")-97-S86=E(&)O9'DZ("(^/'9S<&%C M92 O/@T*5&AE(&UE2!F;W(@82!Q=65R>2!R97-P;VYS92!M M97-S86=E(&-O;G-I2 -"B @("!T:&4@2!M97-S86=E M+"!E>&-E<'0@=&AE($]P97)A=&EO;B!43%8@:6YS:61E#0H@(" @:7,@9&EF M9F5R96YT+B!4:&4@;W)D97(@;V8@=&AE(%1,5B!H97)E(&UA=&-H97,@=&AE M(%1,5G,@:6X@=&AE(&-O5]297-P;VYS92(^#0H\87)T=V]R:SX-"B @(" @*RTK+2LM*RTK+2LM*RTK M+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM M*RTK+2L-"B @(" @?" @("!4>7!E(#T@1T54+5)%4U!/4T4@(" @(" @("!\ M(" @(" @(" @(" @(" @3&5N9W1H(" @(" @(" @('P-"B @(" @*RTK+2LM M*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK+2LM*RTK M+2LM*RTK+2LM*RTK+2L-"B @(" @?" @(" @(" @(" @(" @(" @(" @(" @ M(%!A=&@H;W(@071T'0](")1=65R>2!297-P;VYS92!$871A.B B/CQV&UL+'8@) T*/"$M+2!297=R:71T96X@8GD@5V5I;6EN9R!786YG M(#(P,#0O,3 O,C(-"CPA+2T@26YC;W)P87)A=&4@3$9"6=E;B\^6$U,(&5D:71O4US9R!6,2XP+" R,# T+3 V+3$S+"!C:&%N9V5S('-I;F-E(&QA6=E;B\^6$U,(&5D:71O7!E('1O(%1Y<&4N#0HM+3X-"@T*/'-E8W1I;VX@86YC:&]R/2)% M=F5N=$US9R(@=&ET;&4](D5V96YT($YO=&EF:6-A=&EO;B!A;F0@4F5S<&]N M6YC:')O;F]U2!O;F4@;W(@;6]R92!O=&AE2!&;W)# M15,@<')O=&]C;VPL($9O'0](")-97-S86=E(%1R M86YS9F5R($1I'0](")-97-S86=E($AE M861E7!E(#T@3$9"'0](")0 M871H*&]R($5V96YT($E$*3H@(CX\=G-P86-E("\^#0I;56YD97(@9&ES8W5S M2!R96-E:79E7-T96T@;6%N86=E M;65N="X@06X@179E;G0@#0H@(" @3F]T:69I8V%T:6]N(%)E'0](")-97-S86=E(%1R86YS9F5R($1I'0](")-97-S86=E($AE861E2 -"B @ M("!T:&4@2!R96-E:79E9"X@3F]T92!T:&%T(&]N;'D@ M=&AE( T*(" @(&9A:6QU65R(')A=&AE M2!B92!I;G1E2!R96-E:79E9"!O M6=E;B\^6$U,(&5D:71O; Sat, 23 Oct 2004 05:34:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLIVR-0001cn-UL for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 05:48:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLII7-0002QP-H4; Sat, 23 Oct 2004 05:34:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLIC8-0007v5-RV for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 05:28:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11287 for ; Sat, 23 Oct 2004 05:28:12 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLIP6-0001UP-Ph for forces-protocol@ietf.org; Sat, 23 Oct 2004 05:41:42 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9N9RGPJ530052; Sat, 23 Oct 2004 05:27:16 -0400 Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9N9REZZ142738; Sat, 23 Oct 2004 05:27:15 -0400 Received: from [9.4.69.18] (dhcp69-18.zurich.ibm.com [9.4.69.18]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA70464; Sat, 23 Oct 2004 11:27:13 +0200 Message-ID: <417A23E6.7010504@zurich.ibm.com> Date: Sat, 23 Oct 2004 11:27:02 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: avri@psg.com References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> In-Reply-To: <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e3.ny.us.ibm.com id i9N9RGPJ530052 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, hadi@znyx.com, Weiming Wang Subject: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review. X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable All, Below is a new draft of the sections related to FE/Protocol LFBs. Please=20 review. I will also try to add a table summarizing the operations allowed in=20 each type of PL message. I sent it in a previous message. BTW, I find it a bit odd to have Query messages defined before Config=20 messages in Section "Protocol Messages". Does anyone mind changing the=20 order ? Avri, Please send the xml files once you have updated them. I'll then=20 incorporate my text below directly taking suggestions/comments into=20 account, unless you want to do it ;-) BTW, we'll have to remove the State maintenance section and add a new=20 chapter for these LFBs (new xml file ?). Regards, -Robert -------------------------------------------------------------------------= ------------------------------------------ We can remove sections 3.3.2 and 3.3.3, and replace them with a single=20 section that provides an overview of what these "special LFBs": New section 3.3.2: Whereas four key PL messages have a specific type assigned (Association=20 Setup, Response, and Teardown, as well as Heartbeat) mostly for=20 simplicity and monitoring reasons, all other PL messages follow the LFB=20 structure as this provides more flexibility for future enhancements. In=20 addition, this shows how the ForCES protocol itself can be controlled by=20 the very same type of structures (LFBs) as it uses to control functions=20 such as IP forwarding, filtering, etc. To achieve this, the following LFBs are used: FE Protocol LFB, FE LFB,=20 and CE LFB. These LFBs are detailed in Section XXX. An short description=20 is provided here: The FE Protocol LFB is a logical entity in each FE that is used to=20 control the ForCES protocol. The CE operates on this LFB to subscribe or=20 unsubscribe to Heartbeat messages, define the Heartbeat interval, or=20 discover which ForCES protocol version and which TMLs the FE supports.=20 The FE Protocol LFB also contains the various ForCES ID to be used:=20 unicast IDs and table of the PL multicast IDs the FE must be listening to. [TBD: I don't think we need a CE Protocol LFB] The FE LFB (referred to as "FE attributes" in the model draft) should=20 not be confused with the FE Protocol Object. The FE LFB is a logical=20 entity in each FE and contains attributes relative to the FE itself, and=20 not to the operation of the ForCES protocol between the CE and the FE.=20 Such attributes can be FEState (refer to model draft), vendor, etc. The=20 FE LFB contains in particular an table that maps a virtual LFB Instance=20 ID to one or more Instance IDs of LFBs in the FE. The CE LFB is the counterpart of the FE LFB. The CE LFB is a logical=20 entity in each CE and contains attributes relative to the CE itself, and=20 not to the operation of the ForCES protocol between the CE and the FE.=20 This LFB can be used to convey event notifications from a CE to FEs.=20 Some events may be sent by the CE without prior subscription by the FEs. -------------------------------------------------------------------------= ------------------------------------------ The following section should be inserted just before the "Protocol=20 Messages" section. It provides the detail (in english, not xml) of the LF= Bs. Chapter X: FE, CE, and Protocol LFBs. The following LFBs are used to control the operation of the ForCES=20 protocol and interact with FEs and CEs. Section X.1 FE Protocol LFB The FE Protocol LFB is a logical entity in each FE that is used to=20 control the ForCES protocol. The FE Protocol LFB can be manipulated=20 using the standard PL messages. The FE Protocol LFB Class ID is assigned=20 the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There=20 must always be one and only one instance of the FE Protocol LFB in an=20 FE. The values of the attributes in the FE Protocol LFB have pre-defined=20 default values that are specified here. Unless explicit changes are made=20 to these values using Config messages from the CE, these default values=20 MUST be used for the operation of the protocol. The FE Protocol Object consists of the following elements: =20 FE Protocol events that can be subscribed/unsubscribed: FE heartbeat FE TML events (TBD) FE Protocol capabilities (read-only): Supported ForCES protocol version(s) by the FE Supported ForCES FE model(s) by the FE Some TML capability description(s) FE Protocol attributes (can be read and set): Current version of the ForCES protocol Current version of the FE model FE unicast ID(s) (list) FE multicast ID(s) (list) Association Expiry Timer Heartbeat Interval Primary CE FE failover and restart policy =20 Section X.2 The FE LFB is a logical entity in each FE and contains attributes=20 relative to the FE itself, and not to the operation of the ForCES=20 protocol. The FE LFB Class ID is assigned the value 0x2. The FE LFB=20 Instance ID is assigned the value 0x1. There must always be one and only=20 one instance of the FE LFB in an FE. The FE LFB consists of the following elements: FE Events: FEAllEvents (subscribing to this corresponds to subscribing to all=20 events below) FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failove= r) FE DoS alert FE capability change FE attributes: FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode=20 [Note: this replies the State Maintenance messages]) MIID table (a list of virtual LFB Instance IDs that map to a list of=20 Instance IDs of LFBs in that FE [Refer to Zsolt's note]) FE Behavior Exp. Timer HA Mode [the attributes below were previously under Query message] Inter-FE topology Intra-FE topology Section X.3 The CE LFB is a logical entity in each CE and contains attributes=20 relative to the CE itself, and not to the operation of the ForCES protoco= l. The FE LFB consists of the following elements: CE Events: CEAllEvents (subscribing to this corresponds to subscribing to all=20 events below) [Do we want to allow an FE to explicitely subscribe to CE=20 events ?] CEStatusChange (events that signal CE=20 Up/Down/Active/Inactive/Failover) [Such events do not necessarily need=20 to be subscribed to, they can fire even without subscription and inform=20 the FE] [TBD: what else do we need in the CE LFB ?] --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 09:59:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27197 for ; Sat, 23 Oct 2004 09:59:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLMdj-0005um-Oj for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 10:13:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLMMx-0007Ey-Iu; Sat, 23 Oct 2004 09:55:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLMF8-000520-2B for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 09:47:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26658 for ; Sat, 23 Oct 2004 09:47:34 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLMRt-0005gE-PZ for forces-protocol@ietf.org; Sat, 23 Oct 2004 10:01:06 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Sat, 23 Oct 2004 22:05:22 +0800 (CST) Received: from wwm1 (unverified [219.82.165.111]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Sat, 23 Oct 2004 21:41:25 +0800 Message-ID: <005b01c4b907$242b1790$020aa8c0@wwm1> From: "Weiming Wang" To: "Robert Haas" , References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408><1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> Subject: Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review. Date: Sat, 23 Oct 2004 21:49:20 +0800 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 X-Spam-Score: 0.3 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, hadi@znyx.com, Wang Weiming X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Hi Robert, A general comment is: I think the difference and the sameness of the FE protocol LFB and FE LFB with the general FE model LFBs should be specifically addressed. I can see the sameness is: 1. a LFB class id and an instance id are used to address them. 2. contains attributes, capabilities and events that can be operated via protocol messages. I can see the difference is: 1. These LFBs will be lunched along the time the FE is started, before first ForCES protocol message is sent or received, and whose status should not be allowed being changed by protocol messages then. Any status operation toward these LFBs will result in operation error. 2. a defaut value for these LFB attributes are needed , and the instance IDs for these LFBs are also predefined (I suppose LFBs defined by FE model, whose instance is configured by PL msg). (you'v described this point) 3. These LFBs will be defined as black blocks that do not have any input or output ports from FE LFB topology viewpoint. 4. Followed 3, these LFBs will then not be included in FE LFB topology. can now only think of these, we may have more later. Some more comments pls see inline for. regards, weiming ----- Original Message ----- From: "Robert Haas" All, Below is a new draft of the sections related to FE/Protocol LFBs. Please review. I will also try to add a table summarizing the operations allowed in each type of PL message. I sent it in a previous message. BTW, I find it a bit odd to have Query messages defined before Config messages in Section "Protocol Messages". Does anyone mind changing the order ? [Weiming]It's ok to me, and I also see it's not very normal compared with other systems. One difference with ForCES system is it' query message is first used than config msg(query capability). Anyway, i agree to change. Avri, Please send the xml files once you have updated them. I'll then incorporate my text below directly taking suggestions/comments into account, unless you want to do it ;-) BTW, we'll have to remove the State maintenance section and add a new chapter for these LFBs (new xml file ?). Regards, -Robert -------------------------------------------------------------------------------- ----------------------------------- We can remove sections 3.3.2 and 3.3.3, and replace them with a single section that provides an overview of what these "special LFBs": New section 3.3.2: Whereas four key PL messages have a specific type assigned (Association Setup, Response, and Teardown, as well as Heartbeat) mostly for simplicity and monitoring reasons, all other PL messages follow the LFB structure as this provides more flexibility for future enhancements. In addition, this shows how the ForCES protocol itself can be controlled by the very same type of structures (LFBs) as it uses to control functions such as IP forwarding, filtering, etc. To achieve this, the following LFBs are used: FE Protocol LFB, FE LFB, and CE LFB. These LFBs are detailed in Section XXX. An short description is provided here: The FE Protocol LFB is a logical entity in each FE that is used to control the ForCES protocol. The CE operates on this LFB to subscribe or unsubscribe to Heartbeat messages, define the Heartbeat interval, or discover which ForCES protocol version and which TMLs the FE supports. The FE Protocol LFB also contains the various ForCES ID to be used: unicast IDs and table of the PL multicast IDs the FE must be listening to. [TBD: I don't think we need a CE Protocol LFB] The FE LFB (referred to as "FE attributes" in the model draft) should not be confused with the FE Protocol Object. The FE LFB is a logical entity in each FE and contains attributes relative to the FE itself, and not to the operation of the ForCES protocol between the CE and the FE. Such attributes can be FEState (refer to model draft), vendor, etc. The FE LFB contains in particular an table that maps a virtual LFB Instance ID to one or more Instance IDs of LFBs in the FE. The CE LFB is the counterpart of the FE LFB. The CE LFB is a logical entity in each CE and contains attributes relative to the CE itself, and not to the operation of the ForCES protocol between the CE and the FE. This LFB can be used to convey event notifications from a CE to FEs. Some events may be sent by the CE without prior subscription by the FEs. [Weiming]I just see some repeats here of this section with followed specific section. -------------------------------------------------------------------------------- ----------------------------------- The following section should be inserted just before the "Protocol Messages" section. It provides the detail (in english, not xml) of the LFBs. Chapter X: FE, CE, and Protocol LFBs. The following LFBs are used to control the operation of the ForCES protocol and interact with FEs and CEs. [Weiming]I think more description include the difference and the sameness of these LFBs with FE model LFBs) should be described here. Section X.1 FE Protocol LFB The FE Protocol LFB is a logical entity in each FE that is used to control the ForCES protocol. The FE Protocol LFB can be manipulated using the standard PL messages. [Weiming]Except the LFB state operations. The FE Protocol LFB Class ID is assigned the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There must always be one and only one instance of the FE Protocol LFB in an FE. The values of the attributes in the FE Protocol LFB have pre-defined default values that are specified here. Unless explicit changes are made to these values using Config messages from the CE, these default values MUST be used for the operation of the protocol. [Weiming] do we need to tell which attributes whose value should be preset default values? The FE Protocol Object consists of the following elements: FE Protocol events that can be subscribed/unsubscribed: FE heartbeat FE TML events (TBD) FE Protocol capabilities (read-only): Supported ForCES protocol version(s) by the FE Supported ForCES FE model(s) by the FE Some TML capability description(s) FE Protocol attributes (can be read and set): Current version of the ForCES protocol Current version of the FE model FE unicast ID(s) (list) FE multicast ID(s) (list) [Weiming] Can these two be one attribute, only with two tables? Association Expiry Timer Heartbeat Interval Primary CE FE failover and restart policy [Weiming] I suppose to and CE failover or leave policy, because it is important. It will tell what FE will do if it finds it can not connect to a CE and get command from it. By using this plicy, CE can in advance tell the FE to go inactive, totally go down, or just do whatever it can (graceful restart?) if CE fails. Section X.2 The FE LFB is a logical entity in each FE and contains attributes relative to the FE itself, and not to the operation of the ForCES protocol. The FE LFB Class ID is assigned the value 0x2. The FE LFB Instance ID is assigned the value 0x1. There must always be one and only one instance of the FE LFB in an FE. The FE LFB consists of the following elements: FE Events: FEAllEvents (subscribing to this corresponds to subscribing to all events below) FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failover) FE DoS alert FE capability change FE attributes: FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode [Note: this replies the State Maintenance messages]) MIID table (a list of virtual LFB Instance IDs that map to a list of Instance IDs of LFBs in that FE [Refer to Zsolt's note]) FE Behavior Exp. Timer HA Mode [the attributes below were previously under Query message] Inter-FE topology Intra-FE topology [Weiming] although I'm not very sure of other's thoughts, I think the attribute for FE DoS Protect policy should be needed. This attribute will be transfered to TML layer via something (API ?). Section X.3 The CE LFB is a logical entity in each CE and contains attributes relative to the CE itself, and not to the operation of the ForCES protocol. The FE LFB consists of the following elements: [Weiming] should be CE LFB? CE Events: CEAllEvents (subscribing to this corresponds to subscribing to all events below) [Do we want to allow an FE to explicitely subscribe to CE events ?] CEStatusChange (events that signal CE Up/Down/Active/Inactive/Failover) [Such events do not necessarily need to be subscribed to, they can fire even without subscription and inform the FE] [TBD: what else do we need in the CE LFB ?] [Weiming] I see the CE LFB may only have events attributes appearing to FEs. I don't think CE attributes should be defined. -- Robert Haas IBM Zurich Research Laboratory Säumerstrasse 4 CH-8803 Rüschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 14:27:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13312 for ; Sat, 23 Oct 2004 14:27:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLQpO-0001g8-1g for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 14:41:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLQVB-0004vG-Np; Sat, 23 Oct 2004 14:20:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLQSC-0003ON-1F for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 14:17:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12814 for ; Sat, 23 Oct 2004 14:17:22 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLQfG-0001W2-0C for forces-protocol@ietf.org; Sat, 23 Oct 2004 14:30:55 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9NHqrep029798; Sat, 23 Oct 2004 19:52:54 +0200 In-Reply-To: <417A23E6.7010504@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review. Date: Sat, 23 Oct 2004 14:17:15 -0400 To: Robert Haas X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, hadi@znyx.com, Weiming Wang X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit On 23 okt 2004, at 05.27, Robert Haas wrote: > All, > Below is a new draft of the sections related to FE/Protocol LFBs. > Please review. http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-4.txt includes changes i have received so far and includes the text you sent. > > I will also try to add a table summarizing the operations allowed in > each type of PL message. I sent it in a previous message. i missed that. do you want me to build the table? > > BTW, I find it a bit odd to have Query messages defined before Config > messages in Section "Protocol Messages". Does anyone mind changing the > order ? Moved. > > Avri, > Please send the xml files once you have updated them. I'll then > incorporate my text below directly taking suggestions/comments into > account, unless you want to do it ;-) with 1-2 days left to finish, i don't mind making the changes. as i will be going through cleaning up format, fixing some xrefs and doing a language edit, it would be easiest at this point if people just send me text changes. i.e. not whole new text, but something of the sort: old text: bla bla bla new text: better bla, better bla, better bla. (regular unix diffs work just fine. :-) but if this is not ok with you, then i will send youi the changed xml files. > > BTW, we'll have to remove the State maintenance section and add a new > chapter for these LFBs (new xml file ?). > > At an earlier request, i removed the State maintenance section (i think). let me know what you want inserted. i will probably put out another version later today/tonight. cheers a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 15:02:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15297 for ; Sat, 23 Oct 2004 15:02:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRN3-0002CA-5a for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 15:16:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLR3x-0004sJ-Sm; Sat, 23 Oct 2004 14:56:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLR1J-0004FB-Hj for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 14:53:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14757 for ; Sat, 23 Oct 2004 14:53:39 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLREO-00024F-KB for forces-protocol@ietf.org; Sat, 23 Oct 2004 15:07:13 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9NIqipA149556; Sat, 23 Oct 2004 14:52:45 -0400 Received: from sihl.zurich.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9NIqh4G117934; Sat, 23 Oct 2004 14:52:43 -0400 Received: from [9.4.69.18] (dhcp69-18.zurich.ibm.com [9.4.69.18]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id UAA82352; Sat, 23 Oct 2004 20:52:42 +0200 Message-ID: <417AA86E.2030209@zurich.ibm.com> Date: Sat, 23 Oct 2004 20:52:30 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Weiming Wang Subject: Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review. References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408><1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> In-Reply-To: <005b01c4b907$242b1790$020aa8c0@wwm1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e5.ny.us.ibm.com id i9NIqipA149556 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Content-Transfer-Encoding: quoted-printable Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Ligang Dong X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Content-Transfer-Encoding: quoted-printable Weiming, Thanks for your valuable comments. I'll send an update to the text=20 shortly. See some answers in-line. Regards, -Robert Weiming Wang wrote: >Hi Robert, > >A general comment is: >I think the difference and the sameness of the FE protocol LFB and FE LF= B with >the general FE model LFBs should be specifically addressed. > >I can see the sameness is: > >1. a LFB class id and an instance id are used to address them. >2. contains attributes, capabilities and events that can be operated via >protocol messages. > >I can see the difference is: > >1. These LFBs will be lunched along the time the FE is started, before f= irst >ForCES protocol message is sent or received, and whose status should no= t be >allowed being changed by protocol messages then. Any status operation to= ward >these LFBs will result in operation error. >2. a defaut value for these LFB attributes are needed , and the instance= IDs for >these LFBs are also predefined (I suppose LFBs defined by FE model, whos= e >instance is configured by PL msg). (you'v described this point) >3. These LFBs will be defined as black blocks that do not have any input= or >output ports from FE LFB topology viewpoint. >4. Followed 3, these LFBs will then not be included in FE LFB topology. > > =20 > Agreed. >can now only think of these, we may have more later. > >Some more comments pls see inline for. > >regards, >weiming > >----- Original Message ----- >From: "Robert Haas" > >All, >Below is a new draft of the sections related to FE/Protocol LFBs. Please >review. > >I will also try to add a table summarizing the operations allowed in >each type of PL message. I sent it in a previous message. > >BTW, I find it a bit odd to have Query messages defined before Config >messages in Section "Protocol Messages". Does anyone mind changing the >order ? >[Weiming]It's ok to me, and I also see it's not very normal compared wit= h other >systems. One difference with ForCES system is it' query message is first= used >than config msg(query capability). Anyway, i agree to change. > >Avri, >Please send the xml files once you have updated them. I'll then >incorporate my text below directly taking suggestions/comments into >account, unless you want to do it ;-) > >BTW, we'll have to remove the State maintenance section and add a new >chapter for these LFBs (new xml file ?). > >Regards, >-Robert > > >------------------------------------------------------------------------= -------- >----------------------------------- >We can remove sections 3.3.2 and 3.3.3, and replace them with a single >section that provides an overview of what these "special LFBs": > >New section 3.3.2: > >Whereas four key PL messages have a specific type assigned (Association >Setup, Response, and Teardown, as well as Heartbeat) mostly for >simplicity and monitoring reasons, all other PL messages follow the LFB >structure as this provides more flexibility for future enhancements. In >addition, this shows how the ForCES protocol itself can be controlled by >the very same type of structures (LFBs) as it uses to control functions >such as IP forwarding, filtering, etc. > >To achieve this, the following LFBs are used: FE Protocol LFB, FE LFB, >and CE LFB. These LFBs are detailed in Section XXX. An short description >is provided here: > >The FE Protocol LFB is a logical entity in each FE that is used to >control the ForCES protocol. The CE operates on this LFB to subscribe or >unsubscribe to Heartbeat messages, define the Heartbeat interval, or >discover which ForCES protocol version and which TMLs the FE supports. >The FE Protocol LFB also contains the various ForCES ID to be used: >unicast IDs and table of the PL multicast IDs the FE must be listening t= o. >[TBD: I don't think we need a CE Protocol LFB] > >The FE LFB (referred to as "FE attributes" in the model draft) should >not be confused with the FE Protocol Object. The FE LFB is a logical >entity in each FE and contains attributes relative to the FE itself, and >not to the operation of the ForCES protocol between the CE and the FE. >Such attributes can be FEState (refer to model draft), vendor, etc. The >FE LFB contains in particular an table that maps a virtual LFB Instance >ID to one or more Instance IDs of LFBs in the FE. > >The CE LFB is the counterpart of the FE LFB. The CE LFB is a logical >entity in each CE and contains attributes relative to the CE itself, and >not to the operation of the ForCES protocol between the CE and the FE. >This LFB can be used to convey event notifications from a CE to FEs. >Some events may be sent by the CE without prior subscription by the FEs. > >[Weiming]I just see some repeats here of this section with followed spec= ific >section. > > =20 > It's on purpose, because the section below will only appear a few pages=20 later. >------------------------------------------------------------------------= -------- >----------------------------------- >The following section should be inserted just before the "Protocol >Messages" section. It provides the detail (in english, not xml) of the L= FBs. > >Chapter X: FE, CE, and Protocol LFBs. > >The following LFBs are used to control the operation of the ForCES >protocol and interact with FEs and CEs. >[Weiming]I think more description include the difference and the samenes= s of >these LFBs with FE model LFBs) should be described here. > > =20 > Done. >Section X.1 FE Protocol LFB > >The FE Protocol LFB is a logical entity in each FE that is used to >control the ForCES protocol. The FE Protocol LFB can be manipulated >using the standard PL messages. >[Weiming]Except the LFB state operations. > > =20 > Agreed. Removed the sentence from text. >The FE Protocol LFB Class ID is assigned >the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There >must always be one and only one instance of the FE Protocol LFB in an >FE. The values of the attributes in the FE Protocol LFB have pre-defined >default values that are specified here. Unless explicit changes are made >to these values using Config messages from the CE, these default values >MUST be used for the operation of the protocol. >[Weiming] do we need to tell which attributes whose value should be pres= et >default values? > > =20 > We will have to describe each attribute in more details at some point.=20 Not now. >The FE Protocol Object consists of the following elements: > >FE Protocol events that can be subscribed/unsubscribed: > FE heartbeat > FE TML events (TBD) > FE Protocol capabilities (read-only): > Supported ForCES protocol version(s) by the FE > Supported ForCES FE model(s) by the FE > Some TML capability description(s) > FE Protocol attributes (can be read and set): > Current version of the ForCES protocol > Current version of the FE model > > FE unicast ID(s) (list) > FE multicast ID(s) (list) >[Weiming] Can these two be one attribute, only with two tables? > > =20 > FE unicast should actually not be a list (otherwise how does the FE=20 decide which ID to use as Sender ?) > Association Expiry Timer > Heartbeat Interval > Primary CE > FE failover and restart policy >[Weiming] I suppose to and CE failover or leave policy, because it is >important. It will tell what FE will do if it finds it can not connect t= o a CE >and get command from it. By using this plicy, CE can in advance tell the= FE to >go inactive, totally go down, or just do whatever it can (graceful resta= rt?) if >CE fails. > > =20 > I thought that what you decribed is actually captured under the name "FE=20 failover and restart policy" Or what does that mean ? >Section X.2 > >The FE LFB is a logical entity in each FE and contains attributes >relative to the FE itself, and not to the operation of the ForCES >protocol. The FE LFB Class ID is assigned the value 0x2. The FE LFB >Instance ID is assigned the value 0x1. There must always be one and only >one instance of the FE LFB in an FE. > >The FE LFB consists of the following elements: > FE Events: > FEAllEvents (subscribing to this corresponds to subscribing to all >events below) > FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failov= er) > FE DoS alert > FE capability change > FE attributes: > FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode >[Note: this replies the State Maintenance messages]) > MIID table (a list of virtual LFB Instance IDs that map to a list of >Instance IDs of LFBs in that FE [Refer to Zsolt's note]) > FE Behavior Exp. Timer > HA Mode > [the attributes below were previously under Query message] > Inter-FE topology > Intra-FE topology >[Weiming] although I'm not very sure of other's thoughts, I think the at= tribute >for FE DoS Protect policy should be needed. This attribute will be tran= sfered >to TML layer via something (API ?). > > =20 > Added. >Section X.3 > >The CE LFB is a logical entity in each CE and contains attributes >relative to the CE itself, and not to the operation of the ForCES protoc= ol. > >The FE LFB consists of the following elements: >[Weiming] should be CE LFB? > CE Events: > CEAllEvents (subscribing to this corresponds to subscribing to all >events below) [Do we want to allow an FE to explicitely subscribe to CE >events ?] > CEStatusChange (events that signal CE >Up/Down/Active/Inactive/Failover) [Such events do not necessarily need >to be subscribed to, they can fire even without subscription and inform >the FE] > >[TBD: what else do we need in the CE LFB ?] >[Weiming] I see the CE LFB may only have events attributes appearing to = FEs. I >don't think CE attributes should be defined. > =20 > OK --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 15:03:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15420 for ; Sat, 23 Oct 2004 15:03:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLROE-0002Cz-Gk for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 15:17:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLR4x-00056s-0x; Sat, 23 Oct 2004 14:57:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLR2G-0004Ql-MX for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 14:54:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14939 for ; Sat, 23 Oct 2004 14:54:38 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.104]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRFM-00025h-2I for forces-protocol@ietf.org; Sat, 23 Oct 2004 15:08:12 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9NIrsCE482876; Sat, 23 Oct 2004 14:53:54 -0400 Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9NIrr0v289814; Sat, 23 Oct 2004 14:53:53 -0400 Received: from [9.4.69.18] (dhcp69-18.zurich.ibm.com [9.4.69.18]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id UAA82238; Sat, 23 Oct 2004 20:53:52 +0200 Message-ID: <417AA8B6.1040601@zurich.ibm.com> Date: Sat, 23 Oct 2004 20:53:42 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Weiming Wang Subject: Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review. References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408><1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> In-Reply-To: <005b01c4b907$242b1790$020aa8c0@wwm1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id i9NIrsCE482876 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: quoted-printable Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, Ligang Dong X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable All, Attached is the text updated according to Weiming's comments. Regards, -Robert -------------------------------------------------------------------------= ------------------------------------------=20 We can remove sections 3.3.2 and 3.3.3, and replace them with a single=20 section that provides an overview of what these "special LFBs": New section 3.3.2: Whereas four key PL messages have a specific type assigned (Association=20 Setup, Response, and Teardown, as well as Heartbeat) mostly for=20 simplicity and monitoring reasons, all other PL messages follow the LFB=20 structure as this provides more flexibility for future enhancements. In=20 addition, this shows how the ForCES protocol itself can be controlled by=20 the very same type of structures (LFBs) as it uses to control functions=20 such as IP forwarding, filtering, etc. To achieve this, the following LFBs are used: FE Protocol LFB, FE LFB,=20 and CE LFB. These LFBs are detailed in Section XXX. An short description=20 is provided here: The FE Protocol LFB is a logical entity in each FE that is used to=20 control the ForCES protocol. The CE operates on this LFB to subscribe or=20 unsubscribe to Heartbeat messages, define the Heartbeat interval, or=20 discover which ForCES protocol version and which TMLs the FE supports.=20 The FE Protocol LFB also contains the various ForCES ID to be used:=20 unicast IDs and table of the PL multicast IDs the FE must be listening to. [TBD: I don't think we need a CE Protocol LFB] The FE LFB (referred to as "FE attributes" in the model draft) should=20 not be confused with the FE Protocol Object. The FE LFB is a logical=20 entity in each FE and contains attributes relative to the FE itself, and=20 not to the operation of the ForCES protocol between the CE and the FE.=20 Such attributes can be FEState (refer to model draft), vendor, etc. The=20 FE LFB contains in particular an table that maps a virtual LFB Instance=20 ID to one or more Instance IDs of LFBs in the FE. The CE LFB is the counterpart of the FE LFB. The CE LFB is a logical=20 entity in each CE and contains attributes relative to the CE itself, and=20 not to the operation of the ForCES protocol between the CE and the FE.=20 This LFB can be used to convey event notifications from a CE to FEs.=20 Some events may be sent by the CE without prior subscription by the FEs. -------------------------------------------------------------------------= ------------------------------------------=20 The following section should be inserted just before the "Protocol=20 Messages" section. It provides the detail (in english, not xml) of the=20 LFBs. Chapter X: FE, CE, and Protocol LFBs. The FE LFB, CE LFB, and FE Protocol LFB are used to control the=20 operation of the ForCES protocol and interact with FEs and CEs. Although these LFBs have the same form and interface as other LFBs, they=20 are special in many respects: they have fixed well-known LFB Class and=20 Instance IDs. They are statically defined (no dynamic instantiation=20 allowed) and their status cannot be changed by the protocol: any=20 operation to change the state of such LFBs (for instance, in order to=20 disable the LFB) must result in an error. Moreover, these LFBs must=20 exist before the first ForCES message can be sent or received. All=20 attributes in these LFBs must have pre-defined default values. Finally,=20 these LFBs do not have input nor output ports and do not integrate into=20 the intra-FE LFB topology. Section X.1 FE Protocol LFB The FE Protocol LFB is a logical entity in each FE that is used to=20 control the ForCES protocol. The FE Protocol LFB Class ID is assigned=20 the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There=20 must always be one and only one instance of the FE Protocol LFB in an=20 FE. The values of the attributes in the FE Protocol LFB have pre-defined=20 default values that are specified here. Unless explicit changes are made=20 to these values using Config messages from the CE, these default values=20 MUST be used for the operation of the protocol. The FE Protocol Object consists of the following elements: FE Protocol events that can be subscribed/unsubscribed: FE heartbeat FE TML events (TBD) FE Protocol capabilities (read-only): Supported ForCES protocol version(s) by the FE Supported ForCES FE model(s) by the FE Some TML capability description(s) FE Protocol attributes (can be read and set): Current version of the ForCES protocol Current version of the FE model FE unicast ID FE multicast ID(s) (list) Association Expiry Timer Heartbeat Interval Primary CE FE failover and restart policy CE failover and restart policy [XXX: what is the diff with FE failover= ?] =20 [TBD: define default values for each attribute if applicable] Section X.2 The FE LFB is a logical entity in each FE and contains attributes=20 relative to the FE itself, and not to the operation of the ForCES=20 protocol. The FE LFB Class ID is assigned the value 0x2. The FE LFB=20 Instance ID is assigned the value 0x1. There must always be one and only=20 one instance of the FE LFB in an FE. The FE LFB consists of the following elements: FE Events: FEAllEvents (subscribing to this corresponds to subscribing to all=20 events below) FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failover= ) FE DoS alert FE capability change FE attributes: FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode=20 [Note: this replaces the State Maintenance messages]) MIID table (a list of virtual LFB Instance IDs that map to a list of=20 Instance IDs of LFBs in that FE [Refer to Zsolt's note]) FE Behavior Exp. Timer HA Mode FE DoS protection policy [the attributes below were previously under Query message] Inter-FE topology Intra-FE topology Section X.3 The CE LFB is a logical entity in each CE and contains attributes=20 relative to the CE itself, and not to the operation of the ForCES protoco= l. The CE LFB consists of the following elements: CE Events: CEAllEvents (subscribing to this corresponds to subscribing to all=20 events below) [Do we want to allow an FE to explicitely subscribe to CE=20 events ?] CEStatusChange (events that signal CE=20 Up/Down/Active/Inactive/Failover) [Such events do not necessarily need=20 to be subscribed to, they can fire even without subscription and inform=20 the FE] [TBD: what else do we need in the CE LFB ?] --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 15:08:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15968 for ; Sat, 23 Oct 2004 15:08:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRSv-0002GN-GN for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 15:22:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLREr-0006SX-AZ; Sat, 23 Oct 2004 15:07:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLRCN-00042x-Cj for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 15:05:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15568 for ; Sat, 23 Oct 2004 15:05:05 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRPO-0002Df-Qr for forces-protocol@ietf.org; Sat, 23 Oct 2004 15:18:39 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102312073130:39192 ; Sat, 23 Oct 2004 12:07:31 -0700 Subject: Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review. From: Jamal Hadi Salim To: avri@psg.com In-Reply-To: References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> Organization: ZNYX Networks Message-Id: <1098558297.1096.37.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Oct 2004 15:04:58 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 12:07:31 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 12:07:33 PM, Serialize complete at 10/23/2004 12:07:33 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit I think it is fair to separate in the acknowledgements the original proposal authors from others. Right now they are all lumped as: "The authors of this draft would like to acknowledge and thank all the protocol proposal authors" Sorry, thats all i read so far ;-> But i do plan to scrutinize this version. cheers, jamal On Sat, 2004-10-23 at 14:17, avri@psg.com wrote: > On 23 okt 2004, at 05.27, Robert Haas wrote: > > > All, > > Below is a new draft of the sections related to FE/Protocol LFBs. > > Please review. > > http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-4.txt > includes changes i have received so far and includes the text you sent. > > > > > I will also try to add a table summarizing the operations allowed in > > each type of PL message. I sent it in a previous message. > > i missed that. do you want me to build the table? > > > > > BTW, I find it a bit odd to have Query messages defined before Config > > messages in Section "Protocol Messages". Does anyone mind changing the > > order ? > > Moved. > > > > > Avri, > > Please send the xml files once you have updated them. I'll then > > incorporate my text below directly taking suggestions/comments into > > account, unless you want to do it ;-) > > with 1-2 days left to finish, i don't mind making the changes. as i > will be going through cleaning up format, fixing some xrefs and doing a > language edit, it would be easiest at this point if people just send me > text changes. > > i.e. not whole new text, but something of the sort: > > old text: > bla bla bla > > new text: > better bla, better bla, better bla. > > (regular unix diffs work just fine. :-) > > but if this is not ok with you, then i will send youi the changed xml > files. > > > > > BTW, we'll have to remove the State maintenance section and add a new > > chapter for these LFBs (new xml file ?). > > > > > > At an earlier request, i removed the State maintenance section (i > think). let me know what you want inserted. > > i will probably put out another version later today/tonight. > > > cheers > a. > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 15:15:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16742 for ; Sat, 23 Oct 2004 15:15:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRZi-0002MM-MD for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 15:29:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLRLi-0002c1-Bo; Sat, 23 Oct 2004 15:14:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLRJX-0001AF-3I for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 15:12:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16434 for ; Sat, 23 Oct 2004 15:12:29 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRWc-0002Jw-Et for forces-protocol@ietf.org; Sat, 23 Oct 2004 15:26:03 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102312145921:39197 ; Sat, 23 Oct 2004 12:14:59 -0700 From: Jamal Hadi Salim To: Robert Haas In-Reply-To: <417AA8B6.1040601@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> Organization: ZNYX Networks Message-Id: <1098558745.1097.42.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Oct 2004 15:12:26 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 12:15:00 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 12:15:01 PM, Serialize complete at 10/23/2004 12:15:01 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org, avri@psg.com, Ligang Dong Subject: [Forces-protocol] querry message (path vs attribute) X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit I think we need to add a definition for attribute. As far as iam concerned there is no such thing as a "attribute ID". What you specify is a path similar to an OID. Whether that path happens to be on an attribute, a table, an entry is not important because that wuill be the lement you are pointing to. so lets remove this from the query section ----- Editorial Note: There is a debate on whether we should use a 'Path' or simply an 'Attribute ID' or a 'Table ID' here at the protocol layer. A Path is used for data indexing for a table, while an 'Attribute ID' or a 'Table ID' only specify which attribute or table to use, leaving table index to be included in followed data. ---- cheers, jamal On Sat, 2004-10-23 at 14:53, Robert Haas wrote: > All, > Attached is the text updated according to Weiming's comments. > > Regards, > -Robert > > > ------------------------------------------------------------------------------------------------------------------- > > We can remove sections 3.3.2 and 3.3.3, and replace them with a single > section that provides an overview of what these "special LFBs": > > New section 3.3.2: > > Whereas four key PL messages have a specific type assigned (Association > Setup, Response, and Teardown, as well as Heartbeat) mostly for > simplicity and monitoring reasons, all other PL messages follow the LFB > structure as this provides more flexibility for future enhancements. In > addition, this shows how the ForCES protocol itself can be controlled by > the very same type of structures (LFBs) as it uses to control functions > such as IP forwarding, filtering, etc. > > To achieve this, the following LFBs are used: FE Protocol LFB, FE LFB, > and CE LFB. These LFBs are detailed in Section XXX. An short description > is provided here: > > The FE Protocol LFB is a logical entity in each FE that is used to > control the ForCES protocol. The CE operates on this LFB to subscribe or > unsubscribe to Heartbeat messages, define the Heartbeat interval, or > discover which ForCES protocol version and which TMLs the FE supports. > The FE Protocol LFB also contains the various ForCES ID to be used: > unicast IDs and table of the PL multicast IDs the FE must be listening to. > [TBD: I don't think we need a CE Protocol LFB] > > The FE LFB (referred to as "FE attributes" in the model draft) should > not be confused with the FE Protocol Object. The FE LFB is a logical > entity in each FE and contains attributes relative to the FE itself, and > not to the operation of the ForCES protocol between the CE and the FE. > Such attributes can be FEState (refer to model draft), vendor, etc. The > FE LFB contains in particular an table that maps a virtual LFB Instance > ID to one or more Instance IDs of LFBs in the FE. > > The CE LFB is the counterpart of the FE LFB. The CE LFB is a logical > entity in each CE and contains attributes relative to the CE itself, and > not to the operation of the ForCES protocol between the CE and the FE. > This LFB can be used to convey event notifications from a CE to FEs. > Some events may be sent by the CE without prior subscription by the FEs. > > ------------------------------------------------------------------------------------------------------------------- > > The following section should be inserted just before the "Protocol > Messages" section. It provides the detail (in english, not xml) of the > LFBs. > > Chapter X: FE, CE, and Protocol LFBs. > > The FE LFB, CE LFB, and FE Protocol LFB are used to control the > operation of the ForCES protocol and interact with FEs and CEs. > Although these LFBs have the same form and interface as other LFBs, they > are special in many respects: they have fixed well-known LFB Class and > Instance IDs. They are statically defined (no dynamic instantiation > allowed) and their status cannot be changed by the protocol: any > operation to change the state of such LFBs (for instance, in order to > disable the LFB) must result in an error. Moreover, these LFBs must > exist before the first ForCES message can be sent or received. All > attributes in these LFBs must have pre-defined default values. Finally, > these LFBs do not have input nor output ports and do not integrate into > the intra-FE LFB topology. > > Section X.1 FE Protocol LFB > > The FE Protocol LFB is a logical entity in each FE that is used to > control the ForCES protocol. The FE Protocol LFB Class ID is assigned > the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There > must always be one and only one instance of the FE Protocol LFB in an > FE. The values of the attributes in the FE Protocol LFB have pre-defined > default values that are specified here. Unless explicit changes are made > to these values using Config messages from the CE, these default values > MUST be used for the operation of the protocol. > > The FE Protocol Object consists of the following elements: > > FE Protocol events that can be subscribed/unsubscribed: > FE heartbeat > FE TML events (TBD) > FE Protocol capabilities (read-only): > Supported ForCES protocol version(s) by the FE > Supported ForCES FE model(s) by the FE > Some TML capability description(s) > FE Protocol attributes (can be read and set): > Current version of the ForCES protocol > Current version of the FE model > FE unicast ID > FE multicast ID(s) (list) > Association Expiry Timer > Heartbeat Interval > Primary CE > FE failover and restart policy > CE failover and restart policy [XXX: what is the diff with FE failover ?] > > [TBD: define default values for each attribute if applicable] > > Section X.2 > > The FE LFB is a logical entity in each FE and contains attributes > relative to the FE itself, and not to the operation of the ForCES > protocol. The FE LFB Class ID is assigned the value 0x2. The FE LFB > Instance ID is assigned the value 0x1. There must always be one and only > one instance of the FE LFB in an FE. > > The FE LFB consists of the following elements: > FE Events: > FEAllEvents (subscribing to this corresponds to subscribing to all > events below) > FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failover) > FE DoS alert > FE capability change > FE attributes: > FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode > [Note: this replaces the State Maintenance messages]) > MIID table (a list of virtual LFB Instance IDs that map to a list of > Instance IDs of LFBs in that FE [Refer to Zsolt's note]) > FE Behavior Exp. Timer > HA Mode > FE DoS protection policy > [the attributes below were previously under Query message] > Inter-FE topology > Intra-FE topology > > > Section X.3 > > The CE LFB is a logical entity in each CE and contains attributes > relative to the CE itself, and not to the operation of the ForCES protocol. > > The CE LFB consists of the following elements: > CE Events: > CEAllEvents (subscribing to this corresponds to subscribing to all > events below) [Do we want to allow an FE to explicitely subscribe to CE > events ?] > CEStatusChange (events that signal CE > Up/Down/Active/Inactive/Failover) [Such events do not necessarily need > to be subscribed to, they can fire even without subscription and inform > the FE] > > [TBD: what else do we need in the CE LFB ?] _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 15:25:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17457 for ; Sat, 23 Oct 2004 15:25:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRjX-0002UJ-9E for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 15:39:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLRPZ-0005xQ-4d; Sat, 23 Oct 2004 15:18:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLRMf-0003W1-RN for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 15:15:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16762 for ; Sat, 23 Oct 2004 15:15:43 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRZl-0002MQ-Ik for forces-protocol@ietf.org; Sat, 23 Oct 2004 15:29:17 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102312181521:39198 ; Sat, 23 Oct 2004 12:18:15 -0700 Subject: Re: [Forces-protocol] Header Section From: Jamal Hadi Salim To: avri@psg.com In-Reply-To: <5186A928-24AA-11D9-9DB1-000393CC2112@psg.com> References: <468F3FDA28AA87429AD807992E22D07E02FD9935@orsmsx408> <1098500299.1255.33.camel@jzny.localdomain> <5186A928-24AA-11D9-9DB1-000393CC2112@psg.com> Organization: ZNYX Networks Message-Id: <1098558941.1097.44.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Oct 2004 15:15:42 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 12:18:15 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 12:18:16 PM, Serialize complete at 10/23/2004 12:18:16 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Looks good as you have it now Avri. cheers, jamal On Sat, 2004-10-23 at 00:16, avri@psg.com wrote: > On 22 okt 2004, at 22.58, Jamal Hadi Salim wrote: > > > So my suggestion is lets have Avri make the changes to the major:minor > > done > > > and probably get rid of the resvd field > > what should i do with it. make a 8 bit version number? i would just > ass soon leave it reserved for now. > > > > and leave the rest for the next > > round. > > agree. > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 15:25:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17477 for ; Sat, 23 Oct 2004 15:25:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRjh-0002Ub-DZ for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 15:39:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLRPZ-0005xU-8h; Sat, 23 Oct 2004 15:18:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLRNm-0004OE-Pm for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 15:16:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16893 for ; Sat, 23 Oct 2004 15:16:52 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRar-0002Ml-AI for forces-protocol@ietf.org; Sat, 23 Oct 2004 15:30:26 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.12.10/NS PXFA) with ESMTP id i9NJGAUl417040; Sat, 23 Oct 2004 15:16:10 -0400 Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9NJG90v098072; Sat, 23 Oct 2004 15:16:09 -0400 Received: from [9.4.69.18] (dhcp69-18.zurich.ibm.com [9.4.69.18]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id VAA73032; Sat, 23 Oct 2004 21:16:08 +0200 Message-ID: <417AADED.9080605@zurich.ibm.com> Date: Sat, 23 Oct 2004 21:15:57 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: avri@psg.com Subject: Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review. References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e1.ny.us.ibm.com id i9NJGAUl417040 X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: quoted-printable Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, hadi@znyx.com, Weiming Wang X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: quoted-printable Thanks Avri. I sent out a note with my updated section after Weiming's=20 comments, your note crossed mine ... So I've added a diff below so you=20 can edit the text more easily now. A few comments: Remove section 3.3.2 (FE Protocol Object) Rename current section 3.3.3 (FE Object) to "FE, FE, and FE Protocol LFB= s" Typo "An short description" in section above Text I wrote with [] should be transformed into Editorial notes (and=20 maybe rephrase them to look less stupid ;-) rha@aigle:~$ diff -B -b --unified LFBs-rha.txt.old LFBs-rha.txt.new --- LFBs-rha.txt.old 2004-10-23 20:57:18.000000000 +0200 +++ LFBs-rha.txt.new 2004-10-23 20:56:24.000000000 +0200 @@ -18,11 +18,12 @@ Chapter X: FE, CE, and Protocol LFBs. -The following LFBs are used to control the operation of the ForCES=20 protocol and interact with FEs and CEs. +The FE LFB, CE LFB, and FE Protocol LFB are used to control the=20 operation of the ForCES protocol and interact with FEs and CEs. +Although these LFBs have the same form and interface as other LFBs,=20 they are special in many respects: they have fixed well-known LFB Class=20 and Instance IDs. They are statically defined (no dynamic instantiation=20 allowed) and their status cannot be changed by the protocol: any=20 operation to change the state of such LFBs (for instance, in order to=20 disable the LFB) must result in an error. Moreover, these LFBs must=20 exist before the first ForCES message can be sent or received. All=20 attributes in these LFBs must have pre-defined default values. Finally,=20 these LFBs do not have input nor output ports and do not integrate into=20 the intra-FE LFB topology. Section X.1 FE Protocol LFB -The FE Protocol LFB is a logical entity in each FE that is used to=20 control the ForCES protocol. The FE Protocol LFB can be manipulated=20 using the standard PL messages. The FE Protocol LFB Class ID is assigned=20 the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There=20 must always be one and only one instance of the FE Protocol LFB in an=20 FE. The values of the attributes in the FE Protocol LFB have pre-defined=20 default values that are specified here. Unless explicit changes are made=20 to these values using Config messages from the CE, these default values=20 MUST be used for the operation of the protocol. [diff is removal of the sentence "The FE Protocol LFB can be manipulated=20 using the standard PL messages."] +The FE Protocol LFB is a logical entity in each FE that is used to=20 control the ForCES protocol. The FE Protocol LFB Class ID is assigned=20 the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There=20 must always be one and only one instance of the FE Protocol LFB in an=20 FE. The values of the attributes in the FE Protocol LFB have pre-defined=20 default values that are specified here. Unless explicit changes are made=20 to these values using Config messages from the CE, these default values=20 MUST be used for the operation of the protocol. The FE Protocol Object consists of the following elements: @@ -33,15 +34,18 @@ Current version of the ForCES protocol Current version of the FE model - FE unicast ID(s) (list) + FE unicast ID FE multicast ID(s) (list) Association Expiry Timer Heartbeat Interval Primary CE FE failover and restart policy + CE failover and restart policy [XXX: what is the diff with FE failover= ?] + +[TBD: define default values for each attribute if applicable] Section X.2 @@ -53,11 +57,12 @@ FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failove= r) FE DoS alert FE capability change FE attributes: - FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode=20 [Note: this replies the State Maintenance messages]) + FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode=20 [Note: this replaces the State Maintenance messages]) MIID table (a list of virtual LFB Instance IDs that map to a list of=20 Instance IDs of LFBs in that FE [Refer to Zsolt's note]) FE Behavior Exp. Timer HA Mode + FE DoS protection policy [the attributes below were previously under Query message] Inter-FE topology Intra-FE topology @@ -67,8 +72,8 @@ The CE LFB is a logical entity in each CE and contains attributes=20 relative to the CE itself, and not to the operation of the ForCES protoco= l. - The FE LFB consists of the following elements: +The CE LFB consists of the following elements: CE Events: CEAllEvents (subscribing to this corresponds to subscribing to all=20 events below) [Do we want to allow an FE to explicitely subscribe to CE=20 events ?] CEStatusChange (events that signal CE=20 Up/Down/Active/Inactive/Failover) [Such events do not necessarily need=20 to be subscribed to, they can fire even without subscription and inform=20 the FE] Regards. -Robert avri@psg.com wrote: > > On 23 okt 2004, at 05.27, Robert Haas wrote: > >> All, >> Below is a new draft of the sections related to FE/Protocol LFBs.=20 >> Please review. > > > http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-4.txt > includes changes i have received so far and includes the text you sent. > >> >> I will also try to add a table summarizing the operations allowed in=20 >> each type of PL message. I sent it in a previous message. > > > i missed that. do you want me to build the table? > >> >> BTW, I find it a bit odd to have Query messages defined before Config=20 >> messages in Section "Protocol Messages". Does anyone mind changing=20 >> the order ? > > > Moved. > >> >> Avri, >> Please send the xml files once you have updated them. I'll then=20 >> incorporate my text below directly taking suggestions/comments into=20 >> account, unless you want to do it ;-) > > > with 1-2 days left to finish, i don't mind making the changes. as i=20 > will be going through cleaning up format, fixing some xrefs and doing=20 > a language edit, it would be easiest at this point if people just send=20 > me text changes. > > i.e. not whole new text, but something of the sort: > > old text: > bla bla bla > > new text: > better bla, better bla, better bla. > > (regular unix diffs work just fine. :-) > > but if this is not ok with you, then i will send youi the changed xml=20 > files. > >> >> BTW, we'll have to remove the State maintenance section and add a new=20 >> chapter for these LFBs (new xml file ?). >> >> > > At an earlier request, i removed the State maintenance section (i=20 > think). let me know what you want inserted. > > i will probably put out another version later today/tonight. > > > cheers > a. > > > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 15:26:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17530 for ; Sat, 23 Oct 2004 15:26:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRkK-0002W2-RJ for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 15:40:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLRWi-0002fV-GP; Sat, 23 Oct 2004 15:26:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLRQR-0006cT-G5 for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 15:19:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17199 for ; Sat, 23 Oct 2004 15:19:37 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLRdX-0002Q9-4p for forces-protocol@ietf.org; Sat, 23 Oct 2004 15:33:11 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102312220814:39203 ; Sat, 23 Oct 2004 12:22:08 -0700 Subject: Re: [Forces-protocol] FE Protocol LFB, FE LFB,CE LFB (draft sections) to review. From: Jamal Hadi Salim To: Weiming Wang In-Reply-To: <005b01c4b907$242b1790$020aa8c0@wwm1> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> Organization: ZNYX Networks Message-Id: <1098559174.1096.49.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Oct 2004 15:19:34 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 12:22:08 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 12:22:10 PM, Serialize complete at 10/23/2004 12:22:10 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit On Sat, 2004-10-23 at 09:49, Weiming Wang wrote: > Hi Robert, > > A general comment is: > I think the difference and the sameness of the FE protocol LFB and FE LFB with > the general FE model LFBs should be specifically addressed. > > I can see the sameness is: > > 1. a LFB class id and an instance id are used to address them. > 2. contains attributes, capabilities and events that can be operated via > protocol messages. > > I can see the difference is: > > 1. These LFBs will be lunched along the time the FE is started, before first > ForCES protocol message is sent or received, and whose status should not be > allowed being changed by protocol messages then. Any status operation toward > these LFBs will result in operation error. > 2. a defaut value for these LFB attributes are needed , and the instance IDs for > these LFBs are also predefined (I suppose LFBs defined by FE model, whose > instance is configured by PL msg). (you'v described this point) > 3. These LFBs will be defined as black blocks that do not have any input or > output ports from FE LFB topology viewpoint. > 4. Followed 3, these LFBs will then not be included in FE LFB topology. The ports are optional for any LFB. > can now only think of these, we may have more later. Sounds like you caught all. We need to list the attributes and capabilities. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 16:05:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19107 for ; Sat, 23 Oct 2004 16:05:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLSLz-0003Ax-Bw for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 16:19:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLS52-00067B-SY; Sat, 23 Oct 2004 16:01:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLS1T-00041D-JD for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 15:57:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18872 for ; Sat, 23 Oct 2004 15:57:53 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLSEY-00035V-Iw for forces-protocol@ietf.org; Sat, 23 Oct 2004 16:11:28 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9NJXLep029959; Sat, 23 Oct 2004 21:33:22 +0200 In-Reply-To: <1098558745.1097.42.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Date: Sat, 23 Oct 2004 15:57:44 -0400 To: hadi@znyx.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Weiming Wang , Robert Haas Subject: [Forces-protocol] 01-5 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit On 23 okt 2004, at 15.12, Jamal Hadi Salim wrote: > so lets remove this from the query section > > ----- > Editorial Note: There is a debate on whether we should use a > done. > I think it is fair to separate in the acknowledgements the original > proposal authors from others. instead i just removed the words about original proposals. but still lumped. i also added the command/message table http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-5.txt _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 16:09:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19483 for ; Sat, 23 Oct 2004 16:09:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLSPv-0003FB-Vh for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 16:23:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLSC2-00026u-Rz; Sat, 23 Oct 2004 16:08:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLSAh-00018E-Q8 for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 16:07:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19217 for ; Sat, 23 Oct 2004 16:07:25 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLSNn-0003CW-0w for forces-protocol@ietf.org; Sat, 23 Oct 2004 16:21:00 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102313095336:39222 ; Sat, 23 Oct 2004 13:09:53 -0700 From: Jamal Hadi Salim To: avri@psg.com In-Reply-To: References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> Organization: ZNYX Networks Message-Id: <1098562040.1097.65.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Oct 2004 16:07:20 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 01:09:53 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 01:09:57 PM, Serialize complete at 10/23/2004 01:09:57 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Weiming Wang , Robert Haas Subject: [Forces-protocol] Feedback section 6.1. X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit comments: - section 6.1 should have title "Core ForCES LFBs" - 6.1.1 FE Protocol LFB "Protocol LFB have pre-defined default values that are specified here." What? Where? - 6.1.2 FE LFB MIID table : Have we decided this is the mode we are using? Should this be under editorial note? Other things: + FELFBInstancelist missing + FENeighborList missing + FEStatusChange should probably be just "FEStatus" What is FE Behavior Exp. Timer ? Also we probably need some things like + FEPrivateData which will contain things like name, vendor, model and other proprietary info - 6.1.3 CE LFB I sense this is useful. Can someone list CE events the FE maybe interested in? cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 16:24:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20538 for ; Sat, 23 Oct 2004 16:24:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLSeS-0003XA-B6 for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 16:38:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLSQT-00074W-9K; Sat, 23 Oct 2004 16:23:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLSPV-0006sI-6O for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 16:22:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20483 for ; Sat, 23 Oct 2004 16:22:42 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLSca-0003Vw-Gq for forces-protocol@ietf.org; Sat, 23 Oct 2004 16:36:17 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102313251302:39230 ; Sat, 23 Oct 2004 13:25:13 -0700 From: Jamal Hadi Salim To: avri@psg.com In-Reply-To: References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> Organization: ZNYX Networks Message-Id: <1098562959.1096.80.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Oct 2004 16:22:39 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 01:25:13 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 01:25:14 PM, Serialize complete at 10/23/2004 01:25:14 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Weiming Wang , Robert Haas Subject: [Forces-protocol] Feedback: Section 6.2 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit - Section 6.2.1 +--- T = Operation = SHOW | +-- FE NAME What is the point of having this one operation called SHOW just for this? Is it an operation at all given its position in the hierachy? PENAME may have been a better name. In the diagram: + LFB Instance ID and LFB Class ID should those just be set to 0x1? We already know thats where they are going. + Type = operation, using the word "type" is confusing since it is also used in the main header. I dont think we can avoid using the word type in TLVs; my suggestion is we consider changing the main header type to "command". Thoughts? It is a command after all. + comment on SHOW applies here as well + "HBI will be exchanged with the CE using this LFB" ??? -6.2.2 Association Setup Response Message In the diagram: + LFB Instance ID and LFB Class ID should those just be set to 0x1? We already know thats where they are going. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = operation Show | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ FE Object LFB (optional) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What is that? + "HBI will be exchanged with the CE using this LFB" ??? + Type = T.reason ? This brings up that we need the following speacial TLVs. FORCES_REASON, FORCES_RESULT, FORCES_NAME. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 16:44:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21198 for ; Sat, 23 Oct 2004 16:44:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLSxw-0003nQ-4q for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 16:58:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLSgj-0001k3-BQ; Sat, 23 Oct 2004 16:40:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLSdC-00019V-30 for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 16:36:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20991 for ; Sat, 23 Oct 2004 16:36:51 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLSqI-0003h4-I7 for forces-protocol@ietf.org; Sat, 23 Oct 2004 16:50:26 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102313392355:39243 ; Sat, 23 Oct 2004 13:39:23 -0700 From: Jamal Hadi Salim To: avri@psg.com In-Reply-To: References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1098563810.1096.93.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Oct 2004 16:36:50 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 01:39:23 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 01:39:24 PM, Serialize complete at 10/23/2004 01:39:24 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Weiming Wang , Robert Haas Subject: [Forces-protocol] Feedback on section 6.3 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit section 6.3 And in general i hope those are seen as sample layouts of the message; i.e hopefully, nobody sees that layout as the way they must build the message with an ADD and a DEL etc. - 6.3.1 Config Message + "Config data" should be "Config data and path" + Type is bad to describe operations. That should be operations + UPDATE/REPLACE, DEL ALL are really flag extensions which will become clear once we have path-data noise cleared. Suggest you remove. + What is PACKET SUBSCRIBE/UNSUBSCRIBE? - 6.3.2 Config Response Message Why do we have " Operation Result " As far as i can see it is sufficient to look at the Main header type, a operation, path and its associated data. Unless this is meant to be a less verbose result? + BTW, what is the point of mentioning "single or Array LFB specific result entries" or result might be TLV. Just say the presentation of the data is stuill under discussion. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 16:57:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22494 for ; Sat, 23 Oct 2004 16:57:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLTAf-0004Ck-7W for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 17:11:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLSum-0004H8-JW; Sat, 23 Oct 2004 16:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLSot-0003PK-BZ for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 16:48:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21335 for ; Sat, 23 Oct 2004 16:48:56 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLT1y-0003rB-Ta for forces-protocol@ietf.org; Sat, 23 Oct 2004 17:02:32 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102313512749:39249 ; Sat, 23 Oct 2004 13:51:27 -0700 From: Jamal Hadi Salim To: avri@psg.com In-Reply-To: <1098562959.1096.80.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <1098562959.1096.80.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1098564534.1098.106.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Oct 2004 16:48:54 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 01:51:27 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 01:51:29 PM, Serialize complete at 10/23/2004 01:51:29 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Weiming Wang , Robert Haas Subject: [Forces-protocol] Feedback: Section 6.4 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit "The ForCES query and query response messages are used for one ForCES element (CE or FE) to query other ForCES element(s) for various kinds of information. " Isnt everything an LFB? Why not say that its for querying LFBs? - 6.4.1 Query Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = GET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path(or Attribute ID?) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query Data | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should really be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = GET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path to queried data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 6.4.2 Query Response Message I think the deviation from the norm in laying out the response will make it more programming work. Looking at main header one should be able to tell how to parse the contents and what they mean. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 17:03:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22751 for ; Sat, 23 Oct 2004 17:03:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLTGB-0004H4-T6 for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 17:17:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLT27-0005sC-0h; Sat, 23 Oct 2004 17:02:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLT21-0005ki-Q4 for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 17:02:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22718 for ; Sat, 23 Oct 2004 17:02:31 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLTF7-0004GC-DI for forces-protocol@ietf.org; Sat, 23 Oct 2004 17:16:06 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102314050227:39253 ; Sat, 23 Oct 2004 14:05:02 -0700 From: Jamal Hadi Salim To: avri@psg.com In-Reply-To: <1098563810.1096.93.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> <1098563810.1096.93.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1098565348.1255.120.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Oct 2004 17:02:28 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 02:05:02 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 02:05:03 PM, Serialize complete at 10/23/2004 02:05:03 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Weiming Wang , Robert Haas Subject: [Forces-protocol] Feedback on section 6.5 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit - 6.5 Event Notification and Response Messages "An event definition made by ForCES protocol, ForCES FE model, or by vendors will state if the event needs subscription or not." Events will be defined in the XML as attributes; i.e they will have a path to them that can be used by the config message to subscribe to. I think it is important to at least say that. - 6.5.1 Event Notification Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = REPORT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path(or Event ID?) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Data | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPER = REPORT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path and Data | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 17:09:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22939 for ; Sat, 23 Oct 2004 17:09:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLTLz-0004Li-GL for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 17:23:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLT79-0006iF-6J; Sat, 23 Oct 2004 17:07:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLT6i-0006Zr-Rc for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 17:07:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22856 for ; Sat, 23 Oct 2004 17:07:22 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLTJp-0004K8-J7 for forces-protocol@ietf.org; Sat, 23 Oct 2004 17:20:57 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102314095463:39258 ; Sat, 23 Oct 2004 14:09:54 -0700 From: Jamal Hadi Salim To: avri@psg.com In-Reply-To: <1098565348.1255.120.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> <1098563810.1096.93.camel@jzny.localdomain> <1098565348.1255.120.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1098565640.1096.124.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Oct 2004 17:07:21 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 02:09:55 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 02:09:55 PM, Serialize complete at 10/23/2004 02:09:55 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Weiming Wang , Robert Haas Subject: [Forces-protocol] Feedback on rest of section 6 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 1) The packet redirect section, I think we can leave as is for now but should open up a lot of discussion later. 2) Events - I have some implementation experiences/questions in regards to when you have hierachies of subscrisable events. Example: "tell me when table changes vs tell me when entry X of table changes". Lets talk afte rdraft goes out. 3) Section 6.7 - heartbeat section; seems to be missing some things. Double check please. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 17:23:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23404 for ; Sat, 23 Oct 2004 17:23:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLTZh-0004WH-DC for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 17:37:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLTLd-0000Nv-1U; Sat, 23 Oct 2004 17:22:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLTL1-0000G6-Ip for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 17:22:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23281 for ; Sat, 23 Oct 2004 17:22:08 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLTY8-0004Ul-4l for forces-protocol@ietf.org; Sat, 23 Oct 2004 17:35:44 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9NLMIY5000376; Sat, 23 Oct 2004 21:22:18 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9NLPGfU016995; Sat, 23 Oct 2004 21:25:18 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102314213731500 ; Sat, 23 Oct 2004 14:21:37 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 23 Oct 2004 14:21:37 -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 Date: Sat, 23 Oct 2004 14:21:26 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579214@orsmsx408> Thread-Topic: Feedback on section 6.3 Thread-Index: AcS5QAsAX0qkSGFIQsaswILUFnWiNwABgzcw From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 23 Oct 2004 21:21:37.0920 (UTC) FILETIME=[47F36800:01C4B946] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Robert Haas , Weiming Wang , Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] RE: Feedback on section 6.3 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Jamal, I'll respond to your comments by end of today (within next 12 hrs) Avri, pls don't make any changes before that, Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Saturday, October 23, 2004 1:37 PM To: avri@psg.com Cc: Khosravi, Hormuzd M; ram.gopal@nokia.com; Ligang Dong; forces-protocol@ietf.org; Weiming Wang; Robert Haas Subject: Feedback on section 6.3 section 6.3 And in general i hope those are seen as sample layouts of the message; i.e hopefully, nobody sees that layout as the way they must build the message with an ADD and a DEL etc. - 6.3.1 Config Message + "Config data" should be "Config data and path" + Type is bad to describe operations. That should be operations + UPDATE/REPLACE, DEL ALL are really flag extensions which will become clear once we have path-data noise cleared. Suggest you remove. + What is PACKET SUBSCRIBE/UNSUBSCRIBE? - 6.3.2 Config Response Message Why do we have " Operation Result " As far as i can see it is sufficient to look at the Main header type, a operation, path and its associated data. Unless this is meant to be a less verbose result? + BTW, what is the point of mentioning "single or Array LFB specific result entries" or result might be TLV. Just say the=20 presentation of the data is stuill under discussion. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 18:09:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26764 for ; Sat, 23 Oct 2004 18:09:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLUHu-0005En-4z for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 18:23:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLU1n-00006Z-81; Sat, 23 Oct 2004 18:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLTzJ-0007iP-SG for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 18:03:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26079 for ; Sat, 23 Oct 2004 18:03:46 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLUCQ-00059W-0l for forces-protocol@ietf.org; Sat, 23 Oct 2004 18:17:23 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102315061707:39285 ; Sat, 23 Oct 2004 15:06:17 -0700 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579214@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579214@orsmsx408> Organization: ZNYX Networks Message-Id: <1098569023.1255.127.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Oct 2004 18:03:44 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 03:06:17 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/23/2004 03:06:19 PM, Serialize complete at 10/23/2004 03:06:19 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Weiming Wang , Robert Haas Subject: [Forces-protocol] RE: Feedback on section 6.3 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Avri, Should probably have said it in my emails. These feedbacks on section 6 are not meant as changes to be made; rather as discussion points hopefully to be resolved before release of draft. cheers, jamal On Sat, 2004-10-23 at 17:21, Khosravi, Hormuzd M wrote: > Jamal, > > I'll respond to your comments by end of today (within next 12 hrs) > Avri, pls don't make any changes before that, > > Thanks > Hormuzd > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: Saturday, October 23, 2004 1:37 PM > To: avri@psg.com > Cc: Khosravi, Hormuzd M; ram.gopal@nokia.com; Ligang Dong; > forces-protocol@ietf.org; Weiming Wang; Robert Haas > Subject: Feedback on section 6.3 > > > section 6.3 > > And in general i hope those are seen as sample layouts of the message; > i.e hopefully, nobody sees that layout as the way they must build the > message with an ADD and a DEL etc. > > - 6.3.1 Config Message > > + "Config data" should be "Config data and path" > > + Type is bad to describe operations. That should be operations > > + UPDATE/REPLACE, DEL ALL are really flag extensions which will become > clear once we have path-data noise cleared. Suggest you remove. > > + What is PACKET SUBSCRIBE/UNSUBSCRIBE? > > - 6.3.2 Config Response Message > > Why do we have " Operation Result " > As far as i can see it is sufficient to look at the Main header type, > a operation, path and its associated data. > Unless this is meant to be a less verbose result? > > + BTW, what is the point of mentioning "single or Array LFB > specific result entries" or result might be TLV. Just say the > presentation of the data is stuill under discussion. > > > > cheers, > jamal > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sat Oct 23 18:11:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26996 for ; Sat, 23 Oct 2004 18:11:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLUJz-0005Gl-9E for forces-protocol-web-archive@ietf.org; Sat, 23 Oct 2004 18:25:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLU3u-0000oR-CV; Sat, 23 Oct 2004 18:08:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLU0H-00083i-3S for forces-protocol@megatron.ietf.org; Sat, 23 Oct 2004 18:04:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26209 for ; Sat, 23 Oct 2004 18:04:45 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLUDM-0005Af-VA for forces-protocol@ietf.org; Sat, 23 Oct 2004 18:18:22 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9NLeHep030185; Sat, 23 Oct 2004 23:40:18 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579214@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579214@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8A5F7941-253F-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Date: Sat, 23 Oct 2004 18:04:41 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org, hadi@znyx.com, Ligang Dong , Robert Haas Subject: [Forces-protocol] Re: Feedback on section 6.3 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit On 23 okt 2004, at 17.21, Khosravi, Hormuzd M wrote: > Jamal, > > I'll respond to your comments by end of today (within next 12 hrs) > Avri, pls don't make any changes before that, ok. though i did already make some based on Jamal's 6.1 comments. i can unwind them. for now i am putting out 01-6 and will stop working on this until tomorrow (have other stuff i should be doing anyway). http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-6.txt Specifically: > Jamal's comments: > > - section 6.1 should have title "Core ForCES LFBs" ok > > - 6.1.1 FE Protocol LFB > "Protocol LFB have pre-defined default values that are specified here." > > What? Where? > > - 6.1.2 FE LFB > > MIID table : Have we decided this is the mode we are using? > Should this be under editorial note? > > Other things: > + FELFBInstancelist missing added > + FENeighborList missing added > + FEStatusChange should probably be just "FEStatus" changed > > What is > FE Behavior Exp. Timer ? > Also we probably need some things like > + FEPrivateData which will contain things like name, vendor, > model and other proprietary info added _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 07:54:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21944 for ; Sun, 24 Oct 2004 07:54:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLhAe-0004fD-L5 for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 08:08:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLguD-0000b4-Hv; Sun, 24 Oct 2004 07:51:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLgr9-0008Us-LR for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 07:48:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21459 for ; Sun, 24 Oct 2004 07:48:14 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLh4M-0004YS-6b for forces-protocol@ietf.org; Sun, 24 Oct 2004 08:01:56 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CLgqx-0003Dn-1A for forces-protocol@ietf.org; Sun, 24 Oct 2004 07:48:05 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Sun, 24 Oct 2004 20:02:55 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Sun, 24 Oct 2004 19:38:47 +0800 Message-ID: <122b01c4b9be$50fa1cf0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , "Robert Haas" , References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> Date: Sun, 24 Oct 2004 19:40:52 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] Re: querry message (path vs attribute) X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Jamal, Firstly, I think it may be unwise to remove some editorial note when the isuuse is still under discussion. I can clearly see many different opinions regarding the issue. Then, some of my thougt on adding such an editorial note as below. Regards, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" > > I think we need to add a definition for attribute. > As far as iam concerned there is no such thing as a "attribute ID". [Weiming] Then, I just can not see how we can recognize different attributes in a LFB. Note that a 'Path' is a ID that is used and defined by USERS rather than standadized by IETF, therefore it's impossible to recoganize different attributes by 'path', and more, if the attribute ID is defined by USERS, there will be no interoperability. What I see the 'Attribute ID' is a standardized by IANA Identifier that is assigned to different attributes in all LFBs. > What you specify is a path similar to an OID. Whether that path > happens to be on an attribute, a table, an entry is not important I see it may be important, the reason is as above. > because that wuill be the lement you are pointing to. > so lets remove this from the query section [Weiming]I'v already put the 'path' as main select and the 'attribute ID/table ID' as a select for discussion. I don't have any intention to deny the 'path'. Therefore, I don't think it's reasonable currently to remove the note. > > ----- > Editorial Note: There is a debate on whether we should use a > 'Path' or simply an 'Attribute ID' or a 'Table > ID' here at the protocol layer. A Path is used > for data indexing for a table, while an > 'Attribute ID' or a 'Table ID' only specify > which attribute or table to use, leaving table > index to be included in followed data. > ---- > > cheers, > jamal > > > > > > On Sat, 2004-10-23 at 14:53, Robert Haas wrote: > > All, > > Attached is the text updated according to Weiming's comments. > > > > Regards, > > -Robert > > > > > > ------------------------------------------------------------------------------ ------------------------------------- > > > > We can remove sections 3.3.2 and 3.3.3, and replace them with a single > > section that provides an overview of what these "special LFBs": > > > > New section 3.3.2: > > > > Whereas four key PL messages have a specific type assigned (Association > > Setup, Response, and Teardown, as well as Heartbeat) mostly for > > simplicity and monitoring reasons, all other PL messages follow the LFB > > structure as this provides more flexibility for future enhancements. In > > addition, this shows how the ForCES protocol itself can be controlled by > > the very same type of structures (LFBs) as it uses to control functions > > such as IP forwarding, filtering, etc. > > > > To achieve this, the following LFBs are used: FE Protocol LFB, FE LFB, > > and CE LFB. These LFBs are detailed in Section XXX. An short description > > is provided here: > > > > The FE Protocol LFB is a logical entity in each FE that is used to > > control the ForCES protocol. The CE operates on this LFB to subscribe or > > unsubscribe to Heartbeat messages, define the Heartbeat interval, or > > discover which ForCES protocol version and which TMLs the FE supports. > > The FE Protocol LFB also contains the various ForCES ID to be used: > > unicast IDs and table of the PL multicast IDs the FE must be listening to. > > [TBD: I don't think we need a CE Protocol LFB] > > > > The FE LFB (referred to as "FE attributes" in the model draft) should > > not be confused with the FE Protocol Object. The FE LFB is a logical > > entity in each FE and contains attributes relative to the FE itself, and > > not to the operation of the ForCES protocol between the CE and the FE. > > Such attributes can be FEState (refer to model draft), vendor, etc. The > > FE LFB contains in particular an table that maps a virtual LFB Instance > > ID to one or more Instance IDs of LFBs in the FE. > > > > The CE LFB is the counterpart of the FE LFB. The CE LFB is a logical > > entity in each CE and contains attributes relative to the CE itself, and > > not to the operation of the ForCES protocol between the CE and the FE. > > This LFB can be used to convey event notifications from a CE to FEs. > > Some events may be sent by the CE without prior subscription by the FEs. > > > > ------------------------------------------------------------------------------ ------------------------------------- > > > > The following section should be inserted just before the "Protocol > > Messages" section. It provides the detail (in english, not xml) of the > > LFBs. > > > > Chapter X: FE, CE, and Protocol LFBs. > > > > The FE LFB, CE LFB, and FE Protocol LFB are used to control the > > operation of the ForCES protocol and interact with FEs and CEs. > > Although these LFBs have the same form and interface as other LFBs, they > > are special in many respects: they have fixed well-known LFB Class and > > Instance IDs. They are statically defined (no dynamic instantiation > > allowed) and their status cannot be changed by the protocol: any > > operation to change the state of such LFBs (for instance, in order to > > disable the LFB) must result in an error. Moreover, these LFBs must > > exist before the first ForCES message can be sent or received. All > > attributes in these LFBs must have pre-defined default values. Finally, > > these LFBs do not have input nor output ports and do not integrate into > > the intra-FE LFB topology. > > > > Section X.1 FE Protocol LFB > > > > The FE Protocol LFB is a logical entity in each FE that is used to > > control the ForCES protocol. The FE Protocol LFB Class ID is assigned > > the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There > > must always be one and only one instance of the FE Protocol LFB in an > > FE. The values of the attributes in the FE Protocol LFB have pre-defined > > default values that are specified here. Unless explicit changes are made > > to these values using Config messages from the CE, these default values > > MUST be used for the operation of the protocol. > > > > The FE Protocol Object consists of the following elements: > > > > FE Protocol events that can be subscribed/unsubscribed: > > FE heartbeat > > FE TML events (TBD) > > FE Protocol capabilities (read-only): > > Supported ForCES protocol version(s) by the FE > > Supported ForCES FE model(s) by the FE > > Some TML capability description(s) > > FE Protocol attributes (can be read and set): > > Current version of the ForCES protocol > > Current version of the FE model > > FE unicast ID > > FE multicast ID(s) (list) > > Association Expiry Timer > > Heartbeat Interval > > Primary CE > > FE failover and restart policy > > CE failover and restart policy [XXX: what is the diff with FE failover ?] > > > > [TBD: define default values for each attribute if applicable] > > > > Section X.2 > > > > The FE LFB is a logical entity in each FE and contains attributes > > relative to the FE itself, and not to the operation of the ForCES > > protocol. The FE LFB Class ID is assigned the value 0x2. The FE LFB > > Instance ID is assigned the value 0x1. There must always be one and only > > one instance of the FE LFB in an FE. > > > > The FE LFB consists of the following elements: > > FE Events: > > FEAllEvents (subscribing to this corresponds to subscribing to all > > events below) > > FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failover) > > FE DoS alert > > FE capability change > > FE attributes: > > FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode > > [Note: this replaces the State Maintenance messages]) > > MIID table (a list of virtual LFB Instance IDs that map to a list of > > Instance IDs of LFBs in that FE [Refer to Zsolt's note]) > > FE Behavior Exp. Timer > > HA Mode > > FE DoS protection policy > > [the attributes below were previously under Query message] > > Inter-FE topology > > Intra-FE topology > > > > > > Section X.3 > > > > The CE LFB is a logical entity in each CE and contains attributes > > relative to the CE itself, and not to the operation of the ForCES protocol. > > > > The CE LFB consists of the following elements: > > CE Events: > > CEAllEvents (subscribing to this corresponds to subscribing to all > > events below) [Do we want to allow an FE to explicitely subscribe to CE > > events ?] > > CEStatusChange (events that signal CE > > Up/Down/Active/Inactive/Failover) [Such events do not necessarily need > > to be subscribed to, they can fire even without subscription and inform > > the FE] > > > > [TBD: what else do we need in the CE LFB ?] > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 08:07:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22751 for ; Sun, 24 Oct 2004 08:07:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLhNA-0004ro-58 for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 08:21:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLh68-0002Hd-St; Sun, 24 Oct 2004 08:03:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLgzU-0001Op-Km for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 07:56:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22020 for ; Sun, 24 Oct 2004 07:56:51 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLhCg-0004gL-SP for forces-protocol@ietf.org; Sun, 24 Oct 2004 08:10:33 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Sun, 24 Oct 2004 20:16:30 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Sun, 24 Oct 2004 19:52:22 +0800 Message-ID: <124b01c4b9c0$3698cee0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Robert Haas" , References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <417AADED.9080605@zurich.ibm.com> Subject: Re: [Forces-protocol] FE Protocol LFB, FE LFB, CE LFB (draft sections) to review. Date: Sun, 24 Oct 2004 19:54:27 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ram.gopal@nokia.com, "Khosravi, Hormuzd M" , hadi@znyx.com, Ligang Dong , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Robert, ----- Original Message ----- From: "Robert Haas" > @@ -33,15 +34,18 @@ > Current version of the ForCES protocol > Current version of the FE model > - FE unicast ID(s) (list) > + FE unicast ID > FE multicast ID(s) (list) > Association Expiry Timer > Heartbeat Interval > Primary CE > FE failover and restart policy > + CE failover and restart policy [XXX: what is the diff with FE failover ?] [Weiming] I agree your idea that these two may be merged. Say it as 'CE and FE failover policy' ? > + > +[TBD: define default values for each attribute if applicable] > > Section X.2 > > @@ -53,11 +57,12 @@ > FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failover) > FE DoS alert > FE capability change > FE attributes: > - FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode > [Note: this replies the State Maintenance messages]) > + FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode > [Note: this replaces the State Maintenance messages]) > MIID table (a list of virtual LFB Instance IDs that map to a list of > Instance IDs of LFBs in that FE [Refer to Zsolt's note]) > FE Behavior Exp. Timer > HA Mode > + FE DoS protection policy > [the attributes below were previously under Query message] [Weiming] this editorial note is not needed anymore, fore I'v already removed the following items. > Inter-FE topology > Intra-FE topology > @@ -67,8 +72,8 @@ > > The CE LFB is a logical entity in each CE and contains attributes > relative to the CE itself, and not to the operation of the ForCES protocol. > > - The FE LFB consists of the following elements: > +The CE LFB consists of the following elements: > CE Events: > CEAllEvents (subscribing to this corresponds to subscribing to all > events below) [Do we want to allow an FE to explicitely subscribe to CE > events ?] > CEStatusChange (events that signal CE > Up/Down/Active/Inactive/Failover) [Such events do not necessarily need > to be subscribed to, they can fire even without subscription and inform > the FE] _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 08:09:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22890 for ; Sun, 24 Oct 2004 08:09:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLhP1-0004uD-L0 for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 08:23:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLh7z-0002Xt-2a; Sun, 24 Oct 2004 08:05:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLh4Y-00025G-PN for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 08:02:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22370 for ; Sun, 24 Oct 2004 08:02:05 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLhHn-0004lo-Fv for forces-protocol@ietf.org; Sun, 24 Oct 2004 08:15:47 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CLh4b-0003fo-0L for forces-protocol@ietf.org; Sun, 24 Oct 2004 08:02:09 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Sun, 24 Oct 2004 20:22:06 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Sun, 24 Oct 2004 19:57:57 +0800 Message-ID: <128f01c4b9c0$fe9df280$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> Date: Sun, 24 Oct 2004 20:00:02 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Robert Haas , Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] Re: 01-5 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Avri, ----- Original Message ----- From: Subject: 01-5 > > On 23 okt 2004, at 15.12, Jamal Hadi Salim wrote: > > so lets remove this from the query section > > > > ----- > > Editorial Note: There is a debate on whether we should use a > > > > done. It may be more fit to do so before we have decided it regarding this issue. > > > I think it is fair to separate in the acknowledgements the original > > proposal authors from others. > > instead i just removed the words about original proposals. but still > lumped. > > i also added the command/message table > > http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-5.txt > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 08:29:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23788 for ; Sun, 24 Oct 2004 08:29:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLhiN-0005Ad-GT for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 08:43:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLhSE-0004rr-Af; Sun, 24 Oct 2004 08:26:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLhNQ-0004JQ-CJ for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 08:21:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23440 for ; Sun, 24 Oct 2004 08:21:35 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLhaa-00053T-4b for forces-protocol@ietf.org; Sun, 24 Oct 2004 08:35:17 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Sun, 24 Oct 2004 20:41:16 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Sun, 24 Oct 2004 20:17:08 +0800 Message-ID: <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408><1E526654-24BF-11D9-9DB1-000393CC2112@psg.com><417A23E6.7010504@zurich.ibm.com><1098562959.1096.80.camel@jzny.localdomain> <1098564534.1098.106.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Feedback: Section 6.4 Date: Sun, 24 Oct 2004 20:19:12 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Robert Haas , Ligang Dong , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Jamal, Thank you for scrutinizing the sections one by one. Cheers, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" Subject: [Forces-protocol] Feedback: Section 6.4 > > "The ForCES query and query response messages are used for one ForCES > element (CE or FE) to query other ForCES element(s) for various kinds > of information. " > > Isnt everything an LFB? Why not say that its for querying LFBs? [Weimig]it's just a top level description I think we need. i don't think it conflict with the ideas of LFBs. Maybe we can add one more sentense as "The information of a ForCES element all reside in LFBs in the element, therefore, query message will actually query the LFBs for kinds of information." Does it work? > > - 6.4.1 Query Message > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = GET | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path(or Attribute ID?) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Query Data | > . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Should really be: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = GET | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path to queried data | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Weiming] This may be better described in the followed description. So, Avri, could you please add the 'Path to queried data' after the Path description, just before the [[Under discussion and TBD] Again, I think it may be better to leave the discussion topic on attribute ID/table ID here. > > - 6.4.2 Query Response Message > > I think the deviation from the norm in laying out the response > will make it more programming work. > Looking at main header one should be able to tell how to parse the > contents and what they mean. > > cheers, > jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 08:34:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24068 for ; Sun, 24 Oct 2004 08:34:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLhnD-0005Ej-Ad for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 08:48:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLhW6-0005KP-Dy; Sun, 24 Oct 2004 08:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLhSV-0004wq-6S for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 08:26:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23699 for ; Sun, 24 Oct 2004 08:26:49 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLhfg-00056Z-Ms for forces-protocol@ietf.org; Sun, 24 Oct 2004 08:40:32 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Sun, 24 Oct 2004 20:45:00 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Sun, 24 Oct 2004 20:20:51 +0800 Message-ID: <131601c4b9c4$31934480$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408><1E526654-24BF-11D9-9DB1-000393CC2112@psg.com><417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1><417AA8B6.1040601@zurich.ibm.com><1098558745.1097.42.camel@jzny.localdomain><1098563810.1096.93.camel@jzny.localdomain> <1098565348.1255.120.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Feedback on section 6.5 Date: Sun, 24 Oct 2004 20:22:56 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Robert Haas , Ligang Dong , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 ----- Original Message ----- From: "Jamal Hadi Salim" > - 6.5 Event Notification and Response Messages > > "An event definition > made by ForCES protocol, ForCES FE model, or by vendors will state if > the event needs subscription or not." > > Events will be defined in the XML as attributes; i.e they will have a > path to them that can be used by the config message to subscribe to. > I think it is important to at least say that. [Weiming]OK. Avri, pls help to add this. Thanks. > > - 6.5.1 Event Notification Message > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = REPORT | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path(or Event ID?) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Event Data | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Should be: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPER = REPORT | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path and Data | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Weiming]Do you think the "path' and the 'data' will be mixed? > > > cheers, > jamal > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 09:12:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26410 for ; Sun, 24 Oct 2004 09:12:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLiO4-0005rw-FI for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 09:26:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLi9n-0001q7-W4; Sun, 24 Oct 2004 09:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLi5h-0001IH-Kv for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 09:07:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26177 for ; Sun, 24 Oct 2004 09:07:20 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLiIw-0005nh-QE for forces-protocol@ietf.org; Sun, 24 Oct 2004 09:21:03 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102406094323:39635 ; Sun, 24 Oct 2004 06:09:43 -0700 Subject: Re: [Forces-protocol] Re: querry message (path vs attribute) From: Jamal Hadi Salim To: "Wang,Weiming" In-Reply-To: <122b01c4b9be$50fa1cf0$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> <122b01c4b9be$50fa1cf0$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1098623230.1255.136.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Oct 2004 09:07:10 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 06:09:43 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 06:09:51 AM, Serialize complete at 10/24/2004 06:09:51 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Weiming, On Sun, 2004-10-24 at 07:40, Wang,Weiming wrote: > Jamal, > > Firstly, I think it may be unwise to remove some editorial note when the isuuse > is still under discussion. I can clearly see many different opinions regarding > the issue. Then, some of my thougt on adding such an editorial note as below. > Is the concept of path still under discussion Weiming? Thats not my impression. And if not, why does it matter if the path is constructed from a single attribute or via table of table7 index 3 which is table8 ? > Regards, > Weiming > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > > > I think we need to add a definition for attribute. > > As far as iam concerned there is no such thing as a "attribute ID". > [Weiming] Then, I just can not see how we can recognize different attributes in > a LFB. Note that a 'Path' is a ID that is used and defined by USERS rather than > standadized by IETF, therefore it's impossible to recoganize different > attributes by 'path', and more, if the attribute ID is defined by USERS, there > will be no interoperability. What I see the 'Attribute ID' is a standardized by > IANA Identifier that is assigned to different attributes in all LFBs. The attribute IDs are defined by the person(s) who create the XML. The document/ClassID - that i can see as being owned by IANA. > > What you specify is a path similar to an OID. Whether that path > > happens to be on an attribute, a table, an entry is not important > I see it may be important, the reason is as above. > > because that wuill be the lement you are pointing to. > > so lets remove this from the query section > [Weiming]I'v already put the 'path' as main select and the 'attribute ID/table > ID' as a select for discussion. I don't have any intention to deny the 'path'. > Therefore, I don't think it's reasonable currently to remove the note. > I think we need to define how a path is selected once; then use the word path everywhere. I dont think that it matters if theres a table involved or not. Neither if its a single attribute that has nothing to do with a table. Is the above still under discussion? Thats not the impression i have. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 09:18:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26741 for ; Sun, 24 Oct 2004 09:18:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLiTs-0005wl-BC for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 09:32:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLiFg-0002lZ-6K; Sun, 24 Oct 2004 09:17:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLiEk-0002eo-Ha for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 09:16:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26546 for ; Sun, 24 Oct 2004 09:16:40 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLiRw-0005v8-PB for forces-protocol@ietf.org; Sun, 24 Oct 2004 09:30:24 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102406190698:39640 ; Sun, 24 Oct 2004 06:19:06 -0700 Subject: Re: [Forces-protocol] Feedback: Section 6.4 From: Jamal Hadi Salim To: "Wang,Weiming" In-Reply-To: <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <1098562959.1096.80.camel@jzny.localdomain> <1098564534.1098.106.camel@jzny.localdomain> <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1098623794.1255.145.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Oct 2004 09:16:34 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 06:19:07 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 06:19:09 AM, Serialize complete at 10/24/2004 06:19:09 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit On Sun, 2004-10-24 at 08:19, Wang,Weiming wrote: > > Isnt everything an LFB? Why not say that its for querying LFBs? > [Weimig]it's just a top level description I think we need. i don't think it > conflict with the ideas of LFBs. Maybe we can add one more sentense as "The > information of a ForCES element all reside in LFBs in the element, therefore, > query message will actually query the LFBs for kinds of information." Does it > work? So while you are defining that at the top; i think its also important to have a subsection somewhere which says something along the lines of: --- Every attribute within an LFB will have a unique 32 bit ID defined during the LFB definition. This allows mapping any attribute within an LFB to a path not unlike the SNMP OID. Below is an illustration of a complex example and how the different attributes could be accessed. Assume LFB Class A. It contains two Arrays, B, and C (assigned identifiers 1 and 2) A also contains a structure of type Stoo with a human name F. F is assigned ID 3. A also contains two attributes, D and E assigned identifiers 4 and 5. Array B is an array, indexed as a table, whose contents are int32s. Array C is an array, indexed as a table, whose contents are a structure named Star. Stoo type structures contain elements X and Y, each characters, assigned identifiers 1 and 2. Star contains An element N (a sting), assigned identifier 1, and an array Arr, assigned identifier 2, indexed as a table, containing int32s. To reference entities within an LFB instance of Class A, selectors are as follows: 1, meaning the full array B 3, meaning the full structure named F. 2, 7 meaning the full structure in the seventh entry of the array C. 4 means the attribute D 2, 8, 2, 9 meaning the 9th number in the array in the structure in the eigth slot of the array C. Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct type definition. ------- > > > > - 6.4.1 Query Message > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = GET | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Path(or Attribute ID?) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Query Data | > > . > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Should really be: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = GET | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Path to queried data | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > [Weiming] This may be better described in the followed description. So, Avri, > could you please add the 'Path to queried data' after the Path description, just > before the [[Under discussion and TBD] > > Again, I think it may be better to leave the discussion topic on attribute > ID/table ID here. Read my text above on examples. If you still think that this is still under discussion, lets tag it as so for now just so we can release the draft. My opinion is that we have agreement on the path concept. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 09:19:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26876 for ; Sun, 24 Oct 2004 09:19:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLiVB-0005yY-HC for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 09:33:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLiH8-0002wy-E4; Sun, 24 Oct 2004 09:19:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLiG3-0002mF-8p for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 09:18:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26612 for ; Sun, 24 Oct 2004 09:18:01 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLiTI-0005vu-MK for forces-protocol@ietf.org; Sun, 24 Oct 2004 09:31:44 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102406203214:39641 ; Sun, 24 Oct 2004 06:20:32 -0700 Subject: Re: [Forces-protocol] Feedback on section 6.5 From: Jamal Hadi Salim To: "Wang,Weiming" In-Reply-To: <131601c4b9c4$31934480$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> <1098563810.1096.93.camel@jzny.localdomain> <1098565348.1255.120.camel@jzny.localdomain> <131601c4b9c4$31934480$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1098623879.1255.148.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Oct 2004 09:17:59 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 06:20:32 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 06:20:33 AM, Serialize complete at 10/24/2004 06:20:33 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Sun, 2004-10-24 at 08:22, Wang,Weiming wrote: > > - 6.5.1 Event Notification Message > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = REPORT | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Path(or Event ID?) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Event Data | > > . . > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Should be: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | OPER = REPORT | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Path and Data | > > . . > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > [Weiming]Do you think the "path' and the 'data' will be mixed? > Path is clear. Data is under discussion. You will have path and data associated with it. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 12:42:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11165 for ; Sun, 24 Oct 2004 12:42:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLlfO-0000hU-Kf for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 12:56:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLlOA-0005Sp-Sf; Sun, 24 Oct 2004 12:38:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLlNe-0005OR-5z for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 12:38:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10782 for ; Sun, 24 Oct 2004 12:38:03 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLlav-0000d6-2t for forces-protocol@ietf.org; Sun, 24 Oct 2004 12:51:49 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9OGDPep032033; Sun, 24 Oct 2004 18:13:28 +0200 In-Reply-To: <128f01c4b9c0$fe9df280$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> <128f01c4b9c0$fe9df280$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0F5DC2E6-25DB-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Date: Sun, 24 Oct 2004 12:37:56 -0400 To: "Wang,Weiming" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, hadi@znyx.com, Ligang Dong , Robert Haas Subject: [Forces-protocol] Re: 01-5 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit >> On 23 okt 2004, at 15.12, Jamal Hadi Salim wrote: >>> so lets remove this from the query section >>> >>> ----- >>> Editorial Note: There is a debate on whether we should use a >>> >> >> done. > It may be more fit to do so before we have decided it regarding this > issue. As i said in an earlier note, i can always put things back in. I don't actually remove these things on the first pass, I just comment them out in the xml files. and if someone complains, I can uncomment them. Basically I am trying to find the rough consensus point - though I freely acknowledge that I can only recommend where i think that point is. At this point any issue that can't be resolved needs to go to the WG and the chairs for determination of the rough consensus. Frankly I thought we had rough consensus on the issue. It certainly seemed to be reflected in the decisions being made on the text. At this point there are only 20 hours left before I need to submit the draft. I have been reading the list rather faithfully and trying to understand which issues have been resolved and which have not. I honestly thought this debate had been resolved. If I make a mistake, and i acknowledge that i do make mistakes i will roll back the text. And since this is not the final version, anything can be changed - especially if/when we start to get some WG community feedback. Note: if, my editorial judgments are disturbing, and I try to make as few as I think this group can bear, I will pass on the document to someone else. Having said that, I think it is time to start making decisions and bringing them to the WG who are, in point of fact, the owners of the draft. Anyhow, over the next 20 hours I will try to remain available as much as possible to get a draft out that meets this team's rough consensus. Incidentally I have now uncommented that note - i.e. it will show up again in 01-7 unless it gets resolved between then and now. Another point. I have not managed to do the work necessary to activate the issues database, but will try to do so before the IETF. In my opinion, it is time to start moving these disagreements from the text into an issues database in an effort to drive this document to completion - our milestone is March 05 - only 5 months away at this point. also, how many of the team will be at the meeting. We really should have a face to face session to resolve as many issues as possible. I will be arriving in DC Saturday morning (for the HIP RG seminar) and will remain in town until the following Saturday morning a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 13:46:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16165 for ; Sun, 24 Oct 2004 13:46:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLmfG-0001rK-1a for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 14:00:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLmQ2-0003XZ-D2; Sun, 24 Oct 2004 13:44:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLmOE-0003N9-AV for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 13:42:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15911 for ; Sun, 24 Oct 2004 13:42:45 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLmbV-0001mo-8d for forces-protocol@ietf.org; Sun, 24 Oct 2004 13:56:30 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102410451276:39790 ; Sun, 24 Oct 2004 10:45:12 -0700 From: Jamal Hadi Salim To: avri@psg.com In-Reply-To: <0F5DC2E6-25DB-11D9-9DB1-000393CC2112@psg.com> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> <128f01c4b9c0$fe9df280$845c21d2@Necom.hzic.edu.cn> <0F5DC2E6-25DB-11D9-9DB1-000393CC2112@psg.com> Organization: ZNYX Networks Message-Id: <1098639759.1096.258.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Oct 2004 13:42:40 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 10:45:13 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 10:45:15 AM, Serialize complete at 10/24/2004 10:45:15 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, Ligang Dong , Robert Haas Subject: [Forces-protocol] Re: 01-5 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Hi Avri, On Sun, 2004-10-24 at 12:37, avri@psg.com wrote: > > As i said in an earlier note, i can always put things back in. I don't > actually remove these things on the first pass, I just comment them out > in the xml files. and if someone complains, I can uncomment them. > Basically I am trying to find the rough consensus point - though I > freely acknowledge that I can only recommend where i think that point > is. At this point any issue that can't be resolved needs to go to the > WG and the chairs for determination of the rough consensus. Frankly I > thought we had rough consensus on the issue. It certainly seemed to be > reflected in the decisions being made on the text. > Just keep up the good work. I think people may be confused if you are actually following the discussion (since you are unusually quiet) hence the comments you may have seen. But now that we know you are - you should be allowed to exercise your editorial powers on things IMO. What you are doing in keeping the old text around when the person who made the changes to that section hasnt responded is a very good idea. > At this point there are only 20 hours left before I need to submit the > draft. I have been reading the list rather faithfully and trying to > understand which issues have been resolved and which have not. I > honestly thought this debate had been resolved. If I make a mistake, > and i acknowledge that i do make mistakes i will roll back the text. > And since this is not the final version, anything can be changed - > especially if/when we start to get some WG community feedback. > The path issue has been resolved; i think we may be just talking past each other. The issue thats still open is the data packing. > Note: if, my editorial judgments are disturbing, and I try to make as > few as I think this group can bear, I will pass on the document to > someone else. Having said that, I think it is time to start making > decisions and bringing them to the WG who are, in point of fact, the > owners of the draft. > The WG should see the draft after we are done i think. I wouldnt say we are. > Anyhow, over the next 20 hours I will try to remain available as much > as possible to get a draft out that meets this team's rough consensus. > Great. > Incidentally I have now uncommented that note - i.e. it will show up > again in 01-7 unless it gets resolved between then and now. > > Another point. I have not managed to do the work necessary to activate > the issues database, but will try to do so before the IETF. In my > opinion, it is time to start moving these disagreements from the text > into an issues database in an effort to drive this document to > completion - our milestone is March 05 - only 5 months away at this > point. > This would be nice. > also, how many of the team will be at the meeting. We really should > have a face to face session to resolve as many issues as possible. I > will be arriving in DC Saturday morning (for the HIP RG seminar) and > will remain in town until the following Saturday morning > I plan to be there. cheers, jamal > a. > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 17:47:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02530 for ; Sun, 24 Oct 2004 17:47:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLqQV-00065O-NN for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 18:01:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLq8N-0004tx-3O; Sun, 24 Oct 2004 17:42:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLq3w-0004hL-JV for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 17:38:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02027 for ; Sun, 24 Oct 2004 17:38:02 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLqHG-0005vE-8k for forces-protocol@ietf.org; Sun, 24 Oct 2004 17:51:50 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9OLDPep032505; Sun, 24 Oct 2004 23:13:26 +0200 In-Reply-To: <1098639759.1096.258.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> <128f01c4b9c0$fe9df280$845c21d2@Necom.hzic.edu.cn> <0F5DC2E6-25DB-11D9-9DB1-000393CC2112@psg.com> <1098639759.1096.258.camel@jzny.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Date: Sun, 24 Oct 2004 17:37:57 -0400 To: Jamal Hadi Salim X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, Ligang Dong , Robert Haas Subject: [Forces-protocol] Re: 01-5 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit On 24 okt 2004, at 13.42, Jamal Hadi Salim wrote: > > I think people may be confused if you are actually following the > discussion (since you are unusually quiet) hence the comments you may > have seen. for the most part i was fine with the conclusions folks were coming up with. in my attempt to reman as impartial in this group as possible, i only get vocal when things really concern me. in many cases, i saw a lot of the disagreements as of the 6 of 1 and a 1.2 dozen of the other variety, with either option being workable. in those cases where i thought it mattered, things went in a direction i was comfortable with, so why say "me too". also due to my schedule, i have often been delayed many days in reading the email. so, often, by the time i read through the exchange there was very little left to say. > > The path issue has been resolved; i think we may be just talking past > each other. The issue thats still open is the data packing. can someone offer a note that expresses the still open conflict that all parties can agree with? the one i put back does not really express the still open issue as far as i can tell. > > The WG should see the draft after we are done i think. I wouldnt say we > are. i tend to disagree with this. now that this is a WG document, and the WG is the owner of the doc, i believe they should have more frequent snapshots and should be brought into the discussions. but i defer to the team and the chairs on this issue. > >> Anyhow, over the next 20 hours I will try to remain available as much >> as possible to get a draft out that meets this team's rough consensus. >> > > Great. except that i am not seeing any edits from anyone. 15 hours to go, and i plan to sleep some of them if at all possible. i am currently working on a 00 - 01 change list appendix. which will show up in 01-7. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 18:19:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05704 for ; Sun, 24 Oct 2004 18:19:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLqvU-0006c5-Bh for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 18:33:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLqhB-0005AC-II; Sun, 24 Oct 2004 18:18:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLqgF-0004pa-VD for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 18:17:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05492 for ; Sun, 24 Oct 2004 18:17:37 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLqtY-0006a5-Sd for forces-protocol@ietf.org; Sun, 24 Oct 2004 18:31:26 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9OML1VV023349; Sun, 24 Oct 2004 22:21:02 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9OMAW2U024224; Sun, 24 Oct 2004 22:10:32 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102415170220977 ; Sun, 24 Oct 2004 15:17:02 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 24 Oct 2004 15:17:02 -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 Date: Sun, 24 Oct 2004 15:16:49 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579216@orsmsx408> Thread-Topic: 01-5 Thread-Index: AcS559sUc5pDVZITT5aPdye6AIXrOwALdiTw From: "Khosravi, Hormuzd M" To: , , "Wang,Weiming" X-OriginalArrivalTime: 24 Oct 2004 22:17:02.0596 (UTC) FILETIME=[30067440:01C4BA17] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Robert Haas , Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] RE: 01-5 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Avri, I'll send you an update on Protocol Scenarios section by tonight. Jamal,=20 I looked at your comments...i don't think any of them are show stoppers, unfortunately I don't have the time to respond right now but will do so by tonight Sorry All (especially Avri), about not being able to respond faster over this weekend, but I guess you can never plan enough when you have a 2 month old in the house...very sorry about this! Avri, thanks for all your hard work in getting the draft in shape and incorporating all the comments...i understand its not easy sometimes. Let me know by when your time(EST), you would ideally like to have my changes...I will do my best to get them to you. Regards Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 Sent: Sunday, October 24, 2004 9:38 AM To: Wang,Weiming Cc: hadi@znyx.com; forces-protocol@ietf.org; Ligang Dong; Robert Haas; ram.gopal@nokia.com; Khosravi, Hormuzd M Subject: Re: 01-5 >> On 23 okt 2004, at 15.12, Jamal Hadi Salim wrote: >>> so lets remove this from the query section >>> >>> ----- >>> Editorial Note: There is a debate on whether we should use a >>> >> >> done. > It may be more fit to do so before we have decided it regarding this=20 > issue. As i said in an earlier note, i can always put things back in. I don't=20 actually remove these things on the first pass, I just comment them out=20 in the xml files. and if someone complains, I can uncomment them. =20 Basically I am trying to find the rough consensus point - though I=20 freely acknowledge that I can only recommend where i think that point=20 is. At this point any issue that can't be resolved needs to go to the=20 WG and the chairs for determination of the rough consensus. Frankly I=20 thought we had rough consensus on the issue. It certainly seemed to be=20 reflected in the decisions being made on the text. At this point there are only 20 hours left before I need to submit the=20 draft. I have been reading the list rather faithfully and trying to=20 understand which issues have been resolved and which have not. I=20 honestly thought this debate had been resolved. If I make a mistake,=20 and i acknowledge that i do make mistakes i will roll back the text.=20 And since this is not the final version, anything can be changed -=20 especially if/when we start to get some WG community feedback. Note: if, my editorial judgments are disturbing, and I try to make as=20 few as I think this group can bear, I will pass on the document to=20 someone else. Having said that, I think it is time to start making=20 decisions and bringing them to the WG who are, in point of fact, the=20 owners of the draft. Anyhow, over the next 20 hours I will try to remain available as much=20 as possible to get a draft out that meets this team's rough consensus. Incidentally I have now uncommented that note - i.e. it will show up=20 again in 01-7 unless it gets resolved between then and now. Another point. I have not managed to do the work necessary to activate=20 the issues database, but will try to do so before the IETF. In my=20 opinion, it is time to start moving these disagreements from the text=20 into an issues database in an effort to drive this document to=20 completion - our milestone is March 05 - only 5 months away at this=20 point. also, how many of the team will be at the meeting. We really should=20 have a face to face session to resolve as many issues as possible. I=20 will be arriving in DC Saturday morning (for the HIP RG seminar) and=20 will remain in town until the following Saturday morning a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 21:19:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15766 for ; Sun, 24 Oct 2004 21:19:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLtjl-0000yc-Ds for forces-protocol-web-archive@ietf.org; Sun, 24 Oct 2004 21:33:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLtVZ-0000hg-7K; Sun, 24 Oct 2004 21:18:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLtS0-0000P8-Id for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 21:15:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15508 for ; Sun, 24 Oct 2004 21:15:06 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLtfM-0000tz-43 for forces-protocol@ietf.org; Sun, 24 Oct 2004 21:28:56 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102418173293:39991 ; Sun, 24 Oct 2004 18:17:32 -0700 From: Jamal Hadi Salim To: avri@psg.com In-Reply-To: References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> <128f01c4b9c0$fe9df280$845c21d2@Necom.hzic.edu.cn> <0F5DC2E6-25DB-11D9-9DB1-000393CC2112@psg.com> <1098639759.1096.258.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1098666900.1096.267.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Oct 2004 21:15:00 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 06:17:33 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 06:17:38 PM, Serialize complete at 10/24/2004 06:17:38 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, Ligang Dong , Robert Haas Subject: [Forces-protocol] Re: 01-5 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit On Sun, 2004-10-24 at 17:37, avri@psg.com wrote: > On 24 okt 2004, at 13.42, Jamal Hadi Salim wrote: > > > > > I think people may be confused if you are actually following the > > discussion (since you are unusually quiet) hence the comments you may > > have seen. > > for the most part i was fine with the conclusions folks were coming up > with. in my attempt to reman as impartial in this group as possible, i > only get vocal when things really concern me. in many cases, i saw a > lot of the disagreements as of the 6 of 1 and a 1.2 dozen of the other > variety, with either option being workable. in those cases where i > thought it mattered, things went in a direction i was comfortable with, > so why say "me too". > Understood. > > > > The path issue has been resolved; i think we may be just talking past > > each other. The issue thats still open is the data packing. > > can someone offer a note that expresses the still open conflict that > all parties can agree with? the one i put back does not really express > the still open issue as far as i can tell. > In response to Weiming, I posted some text describing the path concept but i am not sure where best that goes. A path defines how to get to data being accessed; how that data gets shipped around is still a question mark. There has been a proposal from Steve/Zsolt which is insufficient to cover all known scenarios. I think this needs to be discussed seriously in the meeting. > > > > The WG should see the draft after we are done i think. I wouldnt say we > > are. > > i tend to disagree with this. now that this is a WG document, and the > WG is the owner of the doc, i believe they should have more frequent > snapshots and should be brought into the discussions. > > but i defer to the team and the chairs on this issue. > It is my opinion that sometimes it is easier to make progress with a smaller team. I actually dont think Weiming and I are disagreeing with each other for example; i just think we may be talking past each other. It is clear that the issue of data packing is still open. I still wanna hear from Weiming if he thinks the path issue is open - in which case we would need to involve more people. > except that i am not seeing any edits from anyone. > > 15 hours to go, and i plan to sleep some of them if at all possible. > > i am currently working on a 00 - 01 change list appendix. which will > show up in 01-7. > I think you should submit by 8am Eastern whatever verion you have then. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 23:49:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26886 for ; Sun, 24 Oct 2004 23:49:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLw53-0003nc-1n for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 00:03:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvni-0004PV-Vs; Sun, 24 Oct 2004 23:45:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvmf-0004HO-EU for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 23:44:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26600 for ; Sun, 24 Oct 2004 23:44:34 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLvzs-0003Y5-L8 for forces-protocol@ietf.org; Sun, 24 Oct 2004 23:58:26 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Mon, 25 Oct 2004 12:03:35 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Mon, 25 Oct 2004 11:39:18 +0800 Message-ID: <006f01c4ba44$7f3c7eb0$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> <122b01c4b9be$50fa1cf0$845c21d2@Necom.hzic.edu.cn> <1098623230.1255.136.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Re: querry message (path vs attribute) Date: Mon, 25 Oct 2004 11:41:22 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, jhalpern@megisto.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Jamal, Hormuzd, pls also give some feadback. I also add Joel to the list again for the discussion. Regards, Weiming ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: [Forces-protocol] Re: querry message (path vs attribute) > Weiming, > > On Sun, 2004-10-24 at 07:40, Wang,Weiming wrote: > > Jamal, > > > > Firstly, I think it may be unwise to remove some editorial note when the isuuse > > is still under discussion. I can clearly see many different opinions regarding > > the issue. Then, some of my thougt on adding such an editorial note as below. > > > > Is the concept of path still under discussion Weiming? Thats not my > impression. And if not, why does it matter if the path is constructed > from a single attribute or via table of table7 index 3 which is table8 ? [Weiming]Jamal, it's really a under discussion topic. I can see different view other than from me, you may miss me one person :), but it's true we have more. I stopped the discussion for I paid more attention to draft rewriting. At least I think Hormuzd also has some different views. > > > Regards, > > Weiming > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > > > > > > > I think we need to add a definition for attribute. > > > As far as iam concerned there is no such thing as a "attribute ID". > > [Weiming] Then, I just can not see how we can recognize different attributes in > > a LFB. Note that a 'Path' is a ID that is used and defined by USERS rather than > > standadized by IETF, therefore it's impossible to recoganize different > > attributes by 'path', and more, if the attribute ID is defined by USERS, there > > will be no interoperability. What I see the 'Attribute ID' is a standardized by > > IANA Identifier that is assigned to different attributes in all LFBs. > > The attribute IDs are defined by the person(s) who create the XML. > The document/ClassID - that i can see as being owned by IANA. [Weiming] Even if the attribute(type) ID will only be defined by XML which define LFBs (I still see the necessity for IANA to standardize the ID), it has already meant the ID will not be assigned by USERS. Then, if you want to have 'path' include the ID, I suppose we should leave a specific section for the ID, and the use of the section will be limited only for attribute type ID. To do like this, I more prefer to have it as a separate spicific field. Note that I'm not saying in any case, the 'path' is useless, I just suppose it can be put in Data field. Actually hat I think the more reasonable addressing map for LFB should be as follows: LFB class / \ LFB Instance ... / \ Attribue Type ... / \ Path to entries inside ... Rather than: LFB class / \ LFB Instance ... / \ Path to entries ... / \ Attribute Type ... The path can really be defined in Data as: Data : = Path Can you tell me what's the harm if we just define the 'path' one step down to the Data field. I just see it more flexible. > > > > What you specify is a path similar to an OID. Whether that path > > > happens to be on an attribute, a table, an entry is not important > > I see it may be important, the reason is as above. > > > because that wuill be the lement you are pointing to. > > > so lets remove this from the query section > > [Weiming]I'v already put the 'path' as main select and the 'attribute ID/table > > ID' as a select for discussion. I don't have any intention to deny the 'path'. > > Therefore, I don't think it's reasonable currently to remove the note. > > > > I think we need to define how a path is selected once; then use the word > path everywhere. [Weiming]So can you give more definition for the 'Path' then? Does it include 'AttributeTypeID'? >I dont think that it matters if theres a table involved > or not. Neither if its a single attribute that has nothing to do with a > table. > Is the above still under discussion? Thats not the impression i have. > > cheers, > jamal > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Sun Oct 24 23:51:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27059 for ; Sun, 24 Oct 2004 23:51:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLw6p-0003py-Uq for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 00:05:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvsh-0004kY-H7; Sun, 24 Oct 2004 23:50:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLvpY-0004Ta-DV for forces-protocol@megatron.ietf.org; Sun, 24 Oct 2004 23:47:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26726 for ; Sun, 24 Oct 2004 23:47:33 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLw2n-0003c1-Mc for forces-protocol@ietf.org; Mon, 25 Oct 2004 00:01:25 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Mon, 25 Oct 2004 12:07:05 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Mon, 25 Oct 2004 11:42:48 +0800 Message-ID: <007001c4ba44$fc908a50$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <1098562959.1096.80.camel@jzny.localdomain> <1098564534.1098.106.camel@jzny.localdomain> <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn> <1098623794.1255.145.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Feedback: Section 6.4 Date: Mon, 25 Oct 2004 11:44:52 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, jhalpern@megisto.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 ----- Original Message ----- From: "Jamal Hadi Salim" > On Sun, 2004-10-24 at 08:19, Wang,Weiming wrote: > > > > Isnt everything an LFB? Why not say that its for querying LFBs? > > [Weimig]it's just a top level description I think we need. i don't think it > > conflict with the ideas of LFBs. Maybe we can add one more sentense as "The > > information of a ForCES element all reside in LFBs in the element, therefore, > > query message will actually query the LFBs for kinds of information." Does it > > work? > > So while you are defining that at the top; i think its also important to > have a subsection somewhere which says something along the lines of: > > --- > Every attribute within an LFB will have a unique 32 bit ID defined > during the LFB definition. This allows mapping any attribute within an > LFB to a path not unlike the SNMP OID. > > Below is an illustration of a complex example and how the different > attributes could be accessed. > > Assume LFB Class A. > It contains two Arrays, B, and C (assigned identifiers 1 and 2) > A also contains a structure of type Stoo with a human name F. > F is assigned ID 3. > A also contains two attributes, D and E assigned identifiers 4 and 5. [Weiming]I suppose the attribute identifier (4, 5) will be assigned by XML as you mentioned (I see some necessity to be defined by IANA). Definitely, user will not be able to define the ID, or there will be no operabitlity. > Array B is an array, indexed as a table, whose contents are int32s. > Array C is an array, indexed as a table, whose contents are a structure > named Star. > Stoo type structures contain elements X and Y, each characters, > assigned identifiers 1 and 2. > Star contains An element N (a sting), assigned identifier 1, and an > array > Arr, assigned identifier 2, indexed as a table, containing int32s. > > To reference entities within an LFB instance of Class A, selectors > are as follows: > > 1, meaning the full array B > 3, meaning the full structure named F. > 2, 7 meaning the full structure in the seventh entry of the array C. > 4 means the attribute D > 2, 8, 2, 9 meaning the 9th number in the array in the structure in the > eigth slot of the array C. > Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct > type definition. > ------- [Weiming]Followed by above comments, a very simple question is how will you address the D and E attributes as you mentioned as two different attributes? I see it's possible only if you save a section inside the 32bit 'path' specifically for attribute type ID. That means this section are not allowed freely used by users. Because of this, i then prefer to have a specific field (AttributeTypeID, which I refered as attribute ID) for it. Note that I'm not saying 'path' is useless, I just think it can be followed in Data field. cheers, weiming > > > > > > > > - 6.4.1 Query Message > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Type = GET | Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Path(or Attribute ID?) | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Query Data | > > > . > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > Should really be: > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Type = GET | Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Path to queried data | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > [Weiming] This may be better described in the followed description. So, Avri, > > could you please add the 'Path to queried data' after the Path description, just > > before the [[Under discussion and TBD] > > > > Again, I think it may be better to leave the discussion topic on attribute > > ID/table ID here. > > > Read my text above on examples. If you still think that this is still > under discussion, lets tag it as so for now just so we can release the > draft. My opinion is that we have agreement on the path concept. > > cheers, > jamal > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 00:24:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28966 for ; Mon, 25 Oct 2004 00:24:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLwcp-0004Mm-W9 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 00:38:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwOh-0000Wq-0D; Mon, 25 Oct 2004 00:23:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwK3-0000IH-Jw for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 00:19:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28659 for ; Mon, 25 Oct 2004 00:19:04 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLwXQ-0004Gs-R6 for forces-protocol@ietf.org; Mon, 25 Oct 2004 00:32:57 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102421212517:40107 ; Sun, 24 Oct 2004 21:21:25 -0700 Subject: Re: [Forces-protocol] Re: querry message (path vs attribute) From: Jamal Hadi Salim To: "Wang,Weiming" In-Reply-To: <006f01c4ba44$7f3c7eb0$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> <122b01c4b9be$50fa1cf0$845c21d2@Necom.hzic.edu.cn> <1098623230.1255.136.camel@jzny.localdomain> <006f01c4ba44$7f3c7eb0$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1098677932.1255.309.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Oct 2004 00:18:52 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 09:21:26 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 09:21:37 PM, Serialize complete at 10/24/2004 09:21:37 PM Content-Type: multipart/mixed; boundary="=-VbkBesYBf1yqWiKpDjbM" X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, jhalpern@megisto.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c --=-VbkBesYBf1yqWiKpDjbM Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2004-10-24 at 23:41, Wang,Weiming wrote: > Jamal, > > Hormuzd, pls also give some feadback. I also add Joel to the list again for the > discussion. > > Regards, > Weiming > ----- Original Message ----- > From: "Jamal Hadi Salim" > Subject: Re: [Forces-protocol] Re: querry message (path vs attribute) > > > > Weiming, > > > > On Sun, 2004-10-24 at 07:40, Wang,Weiming wrote: > > > Jamal, > > > > > > Firstly, I think it may be unwise to remove some editorial note when the > isuuse > > > is still under discussion. I can clearly see many different opinions > regarding > > > the issue. Then, some of my thougt on adding such an editorial note as > below. > > > > > > > Is the concept of path still under discussion Weiming? Thats not my > > impression. And if not, why does it matter if the path is constructed > > from a single attribute or via table of table7 index 3 which is table8 ? > [Weiming]Jamal, it's really a under discussion topic. I can see different view > other than from me, you may miss me one person :), but it's true we have more. I > stopped the discussion for I paid more attention to draft rewriting. At least I > think Hormuzd also has some different views. > > > > > Regards, > > > Weiming > > > ----- Original Message ----- > > > From: "Jamal Hadi Salim" > > > > > > > > > > > I think we need to add a definition for attribute. > > > > As far as iam concerned there is no such thing as a "attribute ID". > > > [Weiming] Then, I just can not see how we can recognize different attributes > in > > > a LFB. Note that a 'Path' is a ID that is used and defined by USERS rather > than > > > standadized by IETF, therefore it's impossible to recoganize different > > > attributes by 'path', and more, if the attribute ID is defined by USERS, > there > > > will be no interoperability. What I see the 'Attribute ID' is a standardized > by > > > IANA Identifier that is assigned to different attributes in all LFBs. > > > > The attribute IDs are defined by the person(s) who create the XML. > > The document/ClassID - that i can see as being owned by IANA. > > [Weiming] Even if the attribute(type) ID will only be defined by XML which > define LFBs (I still see the necessity for IANA to standardize the ID), it has > already meant the ID will not be assigned by USERS. Not defined by users, rather static - defined at LFB XML template creation time. OTOH, there are some more dynamic IDs that are usable such as a table index. > Then, if you want to have > 'path' include the ID, I suppose we should leave a specific section for the ID, > and the use of the section will be limited only for attribute type ID. To do > like this, I more prefer to have it as a separate spicific field. Note that I'm > not saying in any case, the 'path' is useless, I just suppose it can be put in > Data field. Actually hat I think the more reasonable addressing map for LFB > should be as follows: > > LFB class > / \ > LFB Instance ... > / \ > Attribue Type ... > / \ > Path to entries inside ... > > Rather than: > LFB class > / \ > LFB Instance ... > / \ > Path to entries ... > / \ > Attribute Type ... > Why do you have the attribute type? To get to the attribute i.e to know its path, you dont need to know its type. > The path can really be defined in Data as: > > Data : = Path > > Can you tell me what's the harm if we just define the 'path' one step down to > the Data field. I just see it more flexible. > Above is what we have been refering to as path-data. Entry is the data. > > > > > > > What you specify is a path similar to an OID. Whether that path > > > > happens to be on an attribute, a table, an entry is not important > > > I see it may be important, the reason is as above. > > > > because that wuill be the lement you are pointing to. > > > > so lets remove this from the query section > > > [Weiming]I'v already put the 'path' as main select and the 'attribute > ID/table > > > ID' as a select for discussion. I don't have any intention to deny the > 'path'. > > > Therefore, I don't think it's reasonable currently to remove the note. > > > > > > > I think we need to define how a path is selected once; then use the word > > path everywhere. > [Weiming]So can you give more definition for the 'Path' then? Does it include > 'AttributeTypeID'? > 'AttributeTypeID' is not needed to get to the element. But the ID is needed. I have attached the noop LFB we looked at a while back, it may help reminding you a little ;-> cheers, jamal --=-VbkBesYBf1yqWiKpDjbM Content-Disposition: attachment; filename=noop.xml Content-Type: text/xml; name=noop.xml; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit dummyStruct table entry type for dummy LFB foo1 3 foo1 attribute int32 foo2 4 foo2 attribute int32 NOOP 5 a dummy class for explanation 1.0 baseclass fooInput Packet input fooOutput Packet output dataTable 6 the table of NooP information dummyStruct --=-VbkBesYBf1yqWiKpDjbM Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=-VbkBesYBf1yqWiKpDjbM-- From forces-protocol-bounces@ietf.org Mon Oct 25 00:30:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29575 for ; Mon, 25 Oct 2004 00:30:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLwia-0004Vq-On for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 00:44:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwV1-0000uT-8P; Mon, 25 Oct 2004 00:30:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLwUB-0000pg-38 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 00:29:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29429 for ; Mon, 25 Oct 2004 00:29:32 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLwhY-0004U6-3E for forces-protocol@ietf.org; Mon, 25 Oct 2004 00:43:24 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102421315628:40112 ; Sun, 24 Oct 2004 21:31:56 -0700 Subject: Re: [Forces-protocol] Feedback: Section 6.4 From: Jamal Hadi Salim To: "Wang,Weiming" In-Reply-To: <007001c4ba44$fc908a50$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <1098562959.1096.80.camel@jzny.localdomain> <1098564534.1098.106.camel@jzny.localdomain> <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn> <1098623794.1255.145.camel@jzny.localdomain> <007001c4ba44$fc908a50$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1098678563.1097.319.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Oct 2004 00:29:24 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 09:31:58 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/24/2004 09:32:04 PM, Serialize complete at 10/24/2004 09:32:04 PM Content-Type: multipart/mixed; boundary="=-1kNF6BOeofa0nzts3XrU" X-Spam-Score: 0.0 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, jhalpern@megisto.com, avri@psg.com, forces-protocol@ietf.org, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8df1ceff7d5e1ba4a25ab9834397277b --=-1kNF6BOeofa0nzts3XrU Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2004-10-24 at 23:44, Wang,Weiming wrote: > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > So while you are defining that at the top; i think its also important to > > have a subsection somewhere which says something along the lines of: > > > > --- > > Every attribute within an LFB will have a unique 32 bit ID defined > > during the LFB definition. This allows mapping any attribute within an > > LFB to a path not unlike the SNMP OID. > > > > Below is an illustration of a complex example and how the different > > attributes could be accessed. > > > > Assume LFB Class A. > > It contains two Arrays, B, and C (assigned identifiers 1 and 2) > > A also contains a structure of type Stoo with a human name F. > > F is assigned ID 3. > > A also contains two attributes, D and E assigned identifiers 4 and 5. > > [Weiming]I suppose the attribute identifier (4, 5) will be assigned by XML as > you mentioned (I see some necessity to be defined by IANA). Definitely, user > will not be able to define the ID, or there will be no operabitlity. > Right. As an example in noop.xml i posted earlier, foo1 has ID of 3 and foo2 has ID of 4. Thats defined when noop.xml was defined. > > Array B is an array, indexed as a table, whose contents are int32s. > > Array C is an array, indexed as a table, whose contents are a structure > > named Star. > > Stoo type structures contain elements X and Y, each characters, > > assigned identifiers 1 and 2. > > Star contains An element N (a sting), assigned identifier 1, and an > > array > > Arr, assigned identifier 2, indexed as a table, containing int32s. > > > > To reference entities within an LFB instance of Class A, selectors > > are as follows: > > > > 1, meaning the full array B > > 3, meaning the full structure named F. > > 2, 7 meaning the full structure in the seventh entry of the array C. > > 4 means the attribute D > > 2, 8, 2, 9 meaning the 9th number in the array in the structure in the > > eigth slot of the array C. > > Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct > > type definition. > > ------- > > [Weiming]Followed by above comments, a very simple question is how will you > address the D and E attributes as you mentioned as two different attributes? I > see it's possible only if you save a section inside the 32bit 'path' > specifically for attribute type ID. That means this section are not allowed > freely used by users. Because of this, i then prefer to have a specific field > (AttributeTypeID, which I refered as attribute ID) for it. Note that I'm not > saying 'path' is useless, I just think it can be followed in Data field. > Lets take an example of noop, since the xml for that is there and its a very simple example. The class NOOP is 5. owned by IANA. It has a simple table called datatable whose ID is 6. Defined at xml creation. To point to first entry of datatable: 6,1 to point to foo1 within entry 2 of datatable: 6,2,3 to point to foo2 of entry 3 of datatable: 6,3,4 I hope this clears it. I have attached two docs i worked on to clarify this. As i said earlier, the path issue is resolved but not the data packing. Of course if you disagree we could continue that discussion. As you will notice in these docs, the text clearly states that the data packing is not resolved. cheers, jamal --=-1kNF6BOeofa0nzts3XrU Content-Disposition: attachment; filename=msg-discuss.txt Content-Type: text/plain; name=msg-discuss.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is a document that captures thoughts discussed starting at the SD IETF and thereafter in many many emails involving the model team. It is only meant as a guidance, the Protocol design team may decide to rearrange things as long as the requirements discussed are met. PL level PDU : = MAINHDR+ LFBselect := LFBCLASSID LFBInstance + OPER:= ]*>+ - MAINHDR defines msg type, Target FE/CE ID etc. the MAINHDR also defines the content. As an example the content of a "config" message would be different from an "association" message. - LFBCLASSID is a 32 bit unique identifier per LFB class defined at class creation time. - LFBInstance is a 32 bit unique instance identifier of an LFB class - OPERATION is one of {ADD,DEL,GET, ??} path-data identifies the exact element targeted. It may have zero or more data values associated. In summary the described approach has the following characteristic: - there can be one or more LFB Class + InstanceId combo targeted in a message (batch) - There can one or more operation on an addressed LFB classid+instanceid combo(batch) - There can be one or more path targets per operation (batch) - paths may have zero or more data values associated (flexibility and operation specific) It should be noted that the above is optimized for the case of a a single classid+instance targeting. To target multiple instances within the same class, multiple LFBselect are needed. To illustrate, -------------- main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = 0x45 | | | | | +-- LFBInstance = 0x1234 | | | +-- T = ADD | | | | | +-- // one or more path targets | | // with their data here to be added | | | +-- T = DEL | . | | . +-- // one or more path targets to be deleted | | +--- T = LFBselect | | | +-- LFBCLASSID = 0x45 | | | | | +-- LFBInstance = 0x145 | | | | // at row index 7, replace foo1 | + -- T= ADD | | | | | | | // Block del operation on row 1-4 of table X | + -- T= DEL | | | | // at row index 70, get the value of foo2 | + -- T= GET | | +--- T = LFBselect | +-- LFBCLASSID = 0x145 | +-- LFBInstance = 0x14 . . . Main Hdr: -------- As shown above the layout begins with the main header identifies the the msg type such as "config". The main header identifies the source and target FEid/CEid. LFBselect --------- A TLV. The value contains the LFB class being selected, the instanceid within the LFB class being targetted and and one or operational TLVs defining various operations executed on the LFB instance. Operation --------- A TLV. The T defines the type of operation eg ADD. The value contains one or more path-data. path-data ---------- The layout is still under discussion and so is left out from this text. Each accessible attribute within an LFB is expected to have a 32 bit identifier. The path-data will have a map derived from the static class attribute IDs as well as those derived from variable content such table indices (derived at runtime). Below is an illustration of a complex example and how the different attributes could be accessed. Assume LFB Class A. It contains two Arrays, B, and C (assigned identifiers 1 and 2) A also contains a structure of type Stoo with a human name F. F is assigned ID 3. A also contains two attributes, D and E assigned identifiers 4 and 5. Array B is an array, indexed as a table, whose contents are int32s. Array C is an array, indexed as a table, whose contents are a structure named Star. Stoo type structures contain elements X and Y, each characters, assigned identifiers 1 and 2. Star contains An element N (a sting), assigned identifier 1, and an array Arr, assigned identifier 2, indexed as a table, containing int32s. To reference entities within an LFB instance of Class A, selectors are as follows: 1, meaning the full array B 3, meaning the full structure named F. 2, 7 meaning the full structure in the seventh entry of the array C. 4 means the attribute D 2, 8, 2, 9 meaning the 9th number in the array in the structure in the eigth slot of the array C. Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct type definition. Since the model team has asserted that class definitions can only change (version) in ways that leave existing references intact and usable it means backward compatibility is supported. Other Issues that came up -------------------------- 1) Scope of Ts. It is expected that most of the Ts would be global. There may be however desire to have localy scoped Ts depending on the LFB class 2) Can the same Ts be repeated multiple times within a hierachy? Yes. 3) Need to agree on content addressing $Log: msg-discuss.txt,v $ Revision 1.6 2004/10/12 14:34:40 hadi updated the instance and classid to be in the same TLV Revision 1.5 2004/10/06 15:10:37 hadi More discussions with Joel - I think we have reached a compromise Removed any references to how paths are achieved; leave that to the Doc from Steve and Zsolt (for now at least) Revision 1.4 2004/08/28 18:11:25 hadi reached semi-convergence with Joel Revision 1.3 2004/08/27 01:06:34 hadi Adding Joels views on the OPER approach Revision 1.2 2004/08/12 12:47:21 hadi updated diagram per Zsolts comments Revision 1.1 2004/08/12 11:34:25 hadi Initial revision --=-1kNF6BOeofa0nzts3XrU Content-Disposition: attachment; filename=path-data-oper.txt Content-Type: text/plain; name=path-data-oper.txt; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This doc builds up on what was posted by Steve/Zsolt[1] to try to map to protocol. It by no means imposes a decision i.e tghis is merely here as a discussion place holder with the a desire to speed things up. NOTE: ----- A small reminder on layout: main hdr (eg type = config) | | +--- T = LFBselect | | | +-- LFBCLASSID = 0x45 | | | | | +-- LFBInstance = 0x1234 | | | +-- T = ADD //operation | | | | | +-- // path target X | | // with data to be added | | // This is the discussion point | | | +-- T = ADD //operation | | | | | +-- // path target Y | | // with data to be added | | // This is the discussion point | | | | | +-- T = DEL //operation | . | | . +-- // path target Z | . // This is the discussion point | 1) There could be multiple operations on any instance 2) path-data comes after the operation. 3) there is only one path-data per operation. A possible path-data layout. ---------------------------- OPER_TLV : = PATH-DATA := flags IDcount [BLOCK_OR_KEY_NOTATION] [DATA] The operational TLV contains an opcode in the T part. Its V contains the PATH-DATA. Opcodes discussed so far: * SET (create, modify or both depending on PATH-DATA flags} * DEL (remove an existing entity specified by PATH-DATA } * GET (Access a entity specified in PATH-DATA } * EV_S (subscribe to an event defined in PATH-DATA } * EV_U (unsubscribe to an event defined in PATH-DATA } -> IDs := a series of 32bit IDs (whose size is given by IDcount) defining the path. -> flags are used to further refine the operation to be applied on the ID_TLV. -> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension defined in section 4.2 and 4.3 of [1] -> DATA : = Optional variable sized data dependent on PATH and applied operations (eg GET will not have DATA). Some Clarification in relation to [1]: ------------------------------------- [1] represents a requirement gathering/place holder. This document is into details closer to implementation. flags ----- Derived from netlink and BSD route sockets to meet requirements defined in [1]: --> F_EXCL: The exclusive flag. Donot replace the config attribute(s) if already exists - Report back error instead. A CREATE operation with this flag is equivalent to INS_IDX if index is passed and equivalent to INS if index is not passed in the IDs. A DEL with this flag is equivalent to DEL! in [1]. Without this flag the equivalency is to DEL. --> F_REPLACE: Replace existing matching config attribute(s) with passed data. An index must be passed. In the case of key operations, a KEY must be passed. A CREATE operation with this flag is equivalent to a SET or a INS_IDX!. Steve/Zsolt please double check that this is matching to your doc. A CREATE operation with F_EXCL|F_REPLACE is equivalent to SET! ** Other flags used for block operations mentioned in the BLOCK section. BLOCK and KEY path selection ----------------------------- The variant described in [1] is not needed. To get access to all of table contents, the IDs merely need to point to the table. Therefore to access a range, the IDs field will contain the ID leading to a table and an optional TLV will include the range information. - Additional flags needed: 1)F_BLOCK_ON, to indicate block selector embeded 2)F_KEY_ON, to indicate a key selector embeded #1 and #2 are mutually exclusive. 3) F_REV_TRAVERSE, to indicate reverse progress in the access. 4) F_KEY_MODE (2 bits or more) to select the KEY mode in case #2 is on. 5) F_BLOCK_MODE (1 bit); indicates count or range for second parameter of BLOCK Notation. In the case of block operations: Two modes exist. [a,b] or [a,N] We introduce a block TLV T = BLOCK_TLV start // "a" end // "b" or "N" The flag F_BLOCK_ON will indicate the presence of this TLV. F_BLOCK_MODE will indicate that "end" is an "a" or "N" F_REV_TRAVERSE will indicate whether reverse or forward progress In the case of the associative paths: the flag F_KEY_ON will indicate that we are using associative approach F_KEY_MODE will define the mode . We introduce a KEY_INFO TLV. T = BLOCK_TLV KEY KEY_DATA The length of the TLV will help deducing the size of the KEY_DATA. DATA: ----- Not discussing the optional data right now; a lot of details above need ironing out first. DATA is complex twist when it comes with variable sized data. $Log: path-data-oper.txt,v $ Revision 1.2 2004/10/16 14:03:25 hadi incoporating feedback from Joel et al Revision 1.1 2004/10/14 13:12:32 hadi Initial revision --=-1kNF6BOeofa0nzts3XrU Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --=-1kNF6BOeofa0nzts3XrU-- From forces-protocol-bounces@ietf.org Mon Oct 25 01:20:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03790 for ; Mon, 25 Oct 2004 01:20:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxUm-0005Si-Td for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 01:34:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxFT-00069b-Gl; Mon, 25 Oct 2004 01:18:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxEX-000644-Qm for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 01:17:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03630 for ; Mon, 25 Oct 2004 01:17:28 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxRv-0005QM-IJ for forces-protocol@ietf.org; Mon, 25 Oct 2004 01:31:20 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9P4qmep000788; Mon, 25 Oct 2004 06:52:49 +0200 In-Reply-To: References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <005b01c4b907$242b1790$020aa8c0@wwm1> <417AA8B6.1040601@zurich.ibm.com> <1098558745.1097.42.camel@jzny.localdomain> <128f01c4b9c0$fe9df280$845c21d2@Necom.hzic.edu.cn> <0F5DC2E6-25DB-11D9-9DB1-000393CC2112@psg.com> <1098639759.1096.258.camel@jzny.localdomain> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <279A441C-2645-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Date: Mon, 25 Oct 2004 01:17:24 -0400 To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Jamal Hadi Salim Subject: [Forces-protocol] 01-7 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-7.txt Changes to 01-7 - removed ETRI from front header - seemed unfair to list one company. - changed format listing all authors to be a paragraph instead of list for aesthetic reason; it broke across a page break and looked silly. - added changes section - though it is not complete yet. - re-inserted note on path vs. 'attribute id' discussion - some language editing. a bunch more needs to be done. i will probably work for another hour or so tonight, but this is essentially what i plant to submit before the deadline. if i work to much longer tonight i will submit it before going to sleeep so that i don't miss the morning deadline. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 01:41:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05423 for ; Mon, 25 Oct 2004 01:41:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxoj-0005rV-Ah for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 01:54:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxYA-0007oL-Cp; Mon, 25 Oct 2004 01:37:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxV4-0007Pq-Na for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 01:34:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04888 for ; Mon, 25 Oct 2004 01:34:33 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxiS-0005hK-Iu for forces-protocol@ietf.org; Mon, 25 Oct 2004 01:48:25 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9P5bvrk006516; Mon, 25 Oct 2004 05:37:57 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9P5bYsG017015; Mon, 25 Oct 2004 05:37:39 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102422335332157 ; Sun, 24 Oct 2004 22:33:53 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 24 Oct 2004 22:33:52 -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 Date: Sun, 24 Oct 2004 22:33:35 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579218@orsmsx408> Thread-Topic: 01-7- Quick Updates to draft! Thread-Index: AcS6UfGiPK0ILKKHSWClMTM9FqmeygAARFMA From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 25 Oct 2004 05:33:52.0371 (UTC) FILETIME=[3644BC30:01C4BA54] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Weiming Wang , Ligang Dong , Robert Haas Subject: [Forces-protocol] RE: 01-7- Quick Updates to draft! X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Avri, I am back and here is a list of quick changes... Acknowledgments - pls move this to the end of the draft as Jamal suggested, doesn't seem fair to the authors I think. Author Addresses - pls add all our names and address along with yours and Remove Appendix A. You can get most of it from the Requirements RFC (I am surprised no one noticed this before, including myself:)) Section 7.1 -> Replace State maintenance msg in the text With Config msg Replace | S.M. Activate FE | |<----------------------| With | Config-Activate FE | |<----------------------| =20 Section 7.2 -> Replace | S.M. FE Deactivate | |<----------------------| With | Config-FE Deactivate | |<----------------------| The author addresses moving around is important and fair to all of us who have contributed a lot to this protocol. Regards Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 Sent: Sunday, October 24, 2004 10:17 PM To: forces-protocol@ietf.org Cc: Jamal Hadi Salim; ram.gopal@nokia.com; Ligang Dong; Khosravi, Hormuzd M; Robert Haas; Weiming Wang Subject: 01-7 http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-7.txt Changes to 01-7 - removed ETRI from front header - seemed unfair to list one company. - changed format listing all authors to be a paragraph instead of list=20 for aesthetic reason; it broke across a page break and looked silly. - added changes section - though it is not complete yet. - re-inserted note on path vs. 'attribute id' discussion - some language editing. a bunch more needs to be done. i will=20 probably work for another hour or so tonight, but this is essentially=20 what i plant to submit before the deadline. if i work to much longer=20 tonight i will submit it before going to sleeep so that i don't miss=20 the morning deadline. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 01:46:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05900 for ; Mon, 25 Oct 2004 01:46:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxuL-00060S-2b for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:00:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxgh-0000Md-3A; Mon, 25 Oct 2004 01:46:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxcI-0008JC-FC for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 01:42:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05479 for ; Mon, 25 Oct 2004 01:42:01 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxpf-0005sd-Gf for forces-protocol@ietf.org; Mon, 25 Oct 2004 01:55:52 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9P5HJep000826; Mon, 25 Oct 2004 07:17:19 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579218@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579218@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9416488A-2648-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Date: Mon, 25 Oct 2004 01:41:54 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas Subject: [Forces-protocol] Re: 01-7- Quick Updates to draft! X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit On 25 okt 2004, at 01.33, Khosravi, Hormuzd M wrote: > Avri, > > I am back and here is a list of quick changes... you definitely waited for the last minute. thanks. > > Acknowledgments - pls move this to the end of the draft as Jamal > suggested, doesn't seem fair to the authors I think. if you insist. > > Author Addresses - pls add all our names and address along with yours > and Remove Appendix A. You can get most of it from the Requirements RFC > (I am surprised no one noticed this before, including myself:)) > if you insist. and if we are rejected because of the 5 names rule, so be it. i will probably not spend a lot of time on addresses at this point. it takes a while to get that stuff right. > Section 7.1 -> Replace State maintenance msg in the text With Config > msg > Replace > | S.M. Activate FE | > |<----------------------| > With > | Config-Activate FE | > |<----------------------| > > Section 7.2 -> > Replace > | S.M. FE Deactivate | > |<----------------------| > With > | Config-FE Deactivate | > |<----------------------| > > ok. > The author addresses moving around is important and fair to all of us > who have contributed a lot to this protocol. > whatever. i assume i don't need to wait for everyone to second your demands. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 01:47:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05979 for ; Mon, 25 Oct 2004 01:47:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxv6-00062g-Gl for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:01:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxgm-0000QI-6r; Mon, 25 Oct 2004 01:46:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxdp-0000CR-N0 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 01:43:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05598 for ; Mon, 25 Oct 2004 01:43:36 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxrA-0005th-R2 for forces-protocol@ietf.org; Mon, 25 Oct 2004 01:57:28 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9P5gfr8031864; Mon, 25 Oct 2004 05:42:41 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9P5a9Jc006959; Mon, 25 Oct 2004 05:36:29 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102422425929901 ; Sun, 24 Oct 2004 22:42:59 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 24 Oct 2004 22:42:59 -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 Date: Sun, 24 Oct 2004 22:42:41 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0257921A@orsmsx408> Thread-Topic: 01-7- Quick Updates to draft! Thread-Index: AcS6UfGiPK0ILKKHSWClMTM9FqmeygAARFMAAABswuA= From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 25 Oct 2004 05:42:59.0503 (UTC) FILETIME=[7C6273F0:01C4BA55] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Weiming Wang , Ligang Dong , Robert Haas Subject: [Forces-protocol] RE: 01-7- Quick Updates to draft! X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Avri, Here are some of our addresses that I found for your convenience... Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 264 0334 EMail: hormuzd.m.khosravi@intel.com Robert Haas IBM Research Zurich Research Laboratory Saumerstrasse 4 8803 Ruschlikon Switzerland EMail: rha@zurich.ibm.com Ram Gopal Nokia Research Center 5, Wayside Road, Burlington, MA 01803 Phone: 1-781-993-3685 EMail: ram.gopal@nokia.com Jamal Hadi Salim Znyx Networks Ottawa, Ontario Canada EMail: hadi@znyx.com Weiming Wang=20 Department of Information and Electronic Engineering =20 Zhejiang Gongshang University =20 149 Jiaogong Road=20 Hangzhou, 310035, P.R.China =20 Phone: +86-571-88057712=20 Email: wangwm@hzcnc.com Ligang Dong=20 Zhejiang Gongshang University=20 149 Jiaogong Road=20 Hangzhou, 310035, P.R.China =20 Phone: +86-571-88071024=20 Email: donglg@mail.hzic.edu.cn =20 Thanks Hormuzd -----Original Message----- From: Khosravi, Hormuzd M=20 Sent: Sunday, October 24, 2004 10:34 PM To: 'avri@psg.com'; forces-protocol@ietf.org Cc: Jamal Hadi Salim; ram.gopal@nokia.com; Ligang Dong; Robert Haas; Weiming Wang Subject: RE: 01-7- Quick Updates to draft! Avri, I am back and here is a list of quick changes... Acknowledgments - pls move this to the end of the draft as Jamal suggested, doesn't seem fair to the authors I think. Author Addresses - pls add all our names and address along with yours and Remove Appendix A. You can get most of it from the Requirements RFC (I am surprised no one noticed this before, including myself:)) Section 7.1 -> Replace State maintenance msg in the text With Config msg Replace | S.M. Activate FE | |<----------------------| With | Config-Activate FE | |<----------------------| =20 Section 7.2 -> Replace | S.M. FE Deactivate | |<----------------------| With | Config-FE Deactivate | |<----------------------| The author addresses moving around is important and fair to all of us who have contributed a lot to this protocol. Regards Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 Sent: Sunday, October 24, 2004 10:17 PM To: forces-protocol@ietf.org Cc: Jamal Hadi Salim; ram.gopal@nokia.com; Ligang Dong; Khosravi, Hormuzd M; Robert Haas; Weiming Wang Subject: 01-7 http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-7.txt Changes to 01-7 - removed ETRI from front header - seemed unfair to list one company. - changed format listing all authors to be a paragraph instead of list=20 for aesthetic reason; it broke across a page break and looked silly. - added changes section - though it is not complete yet. - re-inserted note on path vs. 'attribute id' discussion - some language editing. a bunch more needs to be done. i will=20 probably work for another hour or so tonight, but this is essentially=20 what i plant to submit before the deadline. if i work to much longer=20 tonight i will submit it before going to sleeep so that i don't miss=20 the morning deadline. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 01:50:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06128 for ; Mon, 25 Oct 2004 01:50:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxy0-00065i-RM for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:04:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxkJ-0000g0-Ai; Mon, 25 Oct 2004 01:50:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxj1-0000ca-Ck for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 01:48:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06064 for ; Mon, 25 Oct 2004 01:48:58 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxwP-00063W-Jj for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:02:49 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9P5m6r8001218; Mon, 25 Oct 2004 05:48:06 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9P5q1sG024497; Mon, 25 Oct 2004 05:52:03 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102422482001509 ; Sun, 24 Oct 2004 22:48:20 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 24 Oct 2004 22:48:21 -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 Date: Sun, 24 Oct 2004 22:48:09 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0257921B@orsmsx408> Thread-Topic: 01-7- Quick Updates to draft! Thread-Index: AcS6VV1cy97H/czmSAKbJ8tgWvdiRgAAEiwg From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 25 Oct 2004 05:48:21.0184 (UTC) FILETIME=[3C1F1400:01C4BA56] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas Subject: [Forces-protocol] RE: 01-7- Quick Updates to draft! X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Avri, I am only asking for Authors Addresses to be added to the end of the draft...I think you misunderstood me. I don't think there is any problem with that, we did the same with the Requirements RFC http://www.ietf.org/rfc/rfc3654.txt, so I am not sure what the problem with that is. (I thought the only restriction was with listing the names on the front page) I apologize for sending this out so late, as I said I had a tough weekend. I think we might have to distribute this work in the future so that it is not so burdensome on you. Regards Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 Sent: Sunday, October 24, 2004 10:42 PM To: Khosravi, Hormuzd M Cc: Weiming Wang; forces-protocol@ietf.org; Ligang Dong; Robert Haas; ram.gopal@nokia.com; Jamal Hadi Salim Subject: Re: 01-7- Quick Updates to draft! On 25 okt 2004, at 01.33, Khosravi, Hormuzd M wrote: > Avri, > > I am back and here is a list of quick changes... you definitely waited for the last minute. thanks. > > Acknowledgments - pls move this to the end of the draft as Jamal > suggested, doesn't seem fair to the authors I think. if you insist. > > Author Addresses - pls add all our names and address along with yours > and Remove Appendix A. You can get most of it from the Requirements RFC > (I am surprised no one noticed this before, including myself:)) > if you insist. and if we are rejected because of the 5 names rule, so be it. i will probably not spend a lot of time on addresses at this point. it=20 takes a while to get that stuff right. > Section 7.1 -> Replace State maintenance msg in the text With Config=20 > msg > Replace > | S.M. Activate FE | > |<----------------------| > With > | Config-Activate FE | > |<----------------------| > > Section 7.2 -> > Replace > | S.M. FE Deactivate | > |<----------------------| > With > | Config-FE Deactivate | > |<----------------------| > > ok. > The author addresses moving around is important and fair to all of us > who have contributed a lot to this protocol. > whatever. i assume i don't need to wait for everyone to second your demands. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:12:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19896 for ; Mon, 25 Oct 2004 02:12:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyJb-0006Rs-P0 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:26:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLy55-0005Iz-C7; Mon, 25 Oct 2004 02:11:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLy3s-0004pz-Ec for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:10:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17438 for ; Mon, 25 Oct 2004 02:10:31 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyHG-0006P9-Kr for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:24:23 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9P5jpep000870; Mon, 25 Oct 2004 07:45:52 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579218@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579218@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9106BAA6-264C-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Date: Mon, 25 Oct 2004 02:10:27 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas Subject: [Forces-protocol] 01-8 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-8.txt On 25 okt 2004, at 01.33, Khosravi, Hormuzd M wrote: > Avri, > > I am back and here is a list of quick changes... > > Acknowledgments - pls move this to the end of the draft as Jamal > suggested, doesn't seem fair to the authors I think. done. don't see the fairness issue, but i have moved as per your instructions. > > Author Addresses - pls add all our names and address along with yours > and Remove Appendix A. You can get most of it from the Requirements RFC > (I am surprised no one noticed this before, including myself:)) can't add the addresses without the header as far as i know - certainly can't in xml. the only addresses that belong in the address section in the end are the ones in the header and are the ones that need to be contacted during 48 hours. i have added all the names to the header as per your instructions. > > Section 7.1 -> Replace State maintenance msg in the text With Config > msg > Replace > | S.M. Activate FE | > |<----------------------| > With > | Config-Activate FE | > |<----------------------| > > Section 7.2 -> > Replace > | S.M. FE Deactivate | > |<----------------------| > With > | Config-FE Deactivate | > |<----------------------| > > done > The author addresses moving around is important and fair to all of us > who have contributed a lot to this protocol. > is this a different instruction the the one you gave me in the beginning of this note? a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:21:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22101 for ; Mon, 25 Oct 2004 02:21:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyRT-0006b0-LH for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:34:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLy8r-0006lY-RD; Mon, 25 Oct 2004 02:15:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLy8f-0006dq-5L for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:15:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21346 for ; Mon, 25 Oct 2004 02:15:27 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLyLr-0006Ti-6z for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:29:19 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Mon, 25 Oct 2004 14:34:54 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Mon, 25 Oct 2004 14:10:36 +0800 Message-ID: <011b01c4ba59$a233b590$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , , References: <468F3FDA28AA87429AD807992E22D07E0257921A@orsmsx408> Date: Mon, 25 Oct 2004 14:12:40 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Ligang Dong , Robert Haas Subject: [Forces-protocol] Re: 01-7- Quick Updates to draft! X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi Avri, Hormuzd, Thank Hormuzd for the address summary. A little change to my and ligang addresses, pls Avri help to fit in. One more thing is, I suggest to list the address still along the sequence of ABC, just as in the first page. Thank you. Weiming Ligang Dong Colledge of Information and Electronic Engineering Zhejiang Gongshang University 149 Jiaogong Road Hangzhou, 310035, P.R.China Phone: +86-571-88071024 ext. Email: donglg@mail.zjgsu.edu.cn Weiming Wang Colledge of Information and Electronic Engineering Zhejiang Gongshang University 149 Jiaogong Road Hangzhou, 310035, P.R.China Phone: +86-571-88071024 ext. Email: wmwang@mail.zjgsu.edu.cn _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:26:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23021 for ; Mon, 25 Oct 2004 02:26:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyX4-0006jv-13 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:40:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyEt-0000zF-Ag; Mon, 25 Oct 2004 02:21:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyCz-0000CU-Gn for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:19:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21914 for ; Mon, 25 Oct 2004 02:19:55 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyQN-0006Xu-O2 for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:33:48 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9P6NMrk024632; Mon, 25 Oct 2004 06:23:22 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9P6MJsg008269; Mon, 25 Oct 2004 06:23:05 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102423192306103 ; Sun, 24 Oct 2004 23:19:23 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 24 Oct 2004 23:19:23 -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 Date: Sun, 24 Oct 2004 23:19:11 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0257921F@orsmsx408> Thread-Topic: 01-8 Thread-Index: AcS6WVnmvv1i/KnmSJypql9dohHqKgAAOHcw From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 25 Oct 2004 06:19:23.0241 (UTC) FILETIME=[91FE6D90:01C4BA5A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas Subject: [Forces-protocol] RE: 01-8 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Avri, You definitely misunderstood me, I did not ask you at add all our names in the front page...just asked you to add our addresses in the end...what gave you this impression ? I know it's a bit late your time, but pls reverse this...i did not ask for it. Thanks and sorry if I said something which caused this confusion, Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 Sent: Sunday, October 24, 2004 11:10 PM To: Khosravi, Hormuzd M Cc: Weiming Wang; forces-protocol@ietf.org; Ligang Dong; Robert Haas; ram.gopal@nokia.com; Jamal Hadi Salim Subject: 01-8 http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-8.txt On 25 okt 2004, at 01.33, Khosravi, Hormuzd M wrote: > Avri, > > I am back and here is a list of quick changes... > > Acknowledgments - pls move this to the end of the draft as Jamal > suggested, doesn't seem fair to the authors I think. done. don't see the fairness issue, but i have moved as per your instructions. > > Author Addresses - pls add all our names and address along with yours > and Remove Appendix A. You can get most of it from the Requirements RFC > (I am surprised no one noticed this before, including myself:)) can't add the addresses without the header as far as i know - certainly=20 can't in xml. the only addresses that belong in the address section in=20 the end are the ones in the header and are the ones that need to be=20 contacted during 48 hours. i have added all the names to the header as per your instructions. > > Section 7.1 -> Replace State maintenance msg in the text With Config=20 > msg > Replace > | S.M. Activate FE | > |<----------------------| > With > | Config-Activate FE | > |<----------------------| > > Section 7.2 -> > Replace > | S.M. FE Deactivate | > |<----------------------| > With > | Config-FE Deactivate | > |<----------------------| > > done > The author addresses moving around is important and fair to all of us > who have contributed a lot to this protocol. > is this a different instruction the the one you gave me in the=20 beginning of this note? a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:28:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23186 for ; Mon, 25 Oct 2004 02:28:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyYX-0006mO-TN for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:42:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyJx-0003Pl-3T; Mon, 25 Oct 2004 02:27:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyGA-0001R6-RV for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:23:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22477 for ; Mon, 25 Oct 2004 02:23:13 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyTY-0006eb-4t for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:37:05 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9P5wWep000916; Mon, 25 Oct 2004 07:58:33 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0257921F@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0257921F@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <561F7F38-264E-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Date: Mon, 25 Oct 2004 02:23:07 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas Subject: [Forces-protocol] Re: 01-8 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit can't have the addresses in the back without having them in the front. i have just spent the last hour adding them. now you want me to remove them? a. On 25 okt 2004, at 02.19, Khosravi, Hormuzd M wrote: > Avri, > > You definitely misunderstood me, I did not ask you at add all our names > in the front page...just asked you to add our addresses in the > end...what gave you this impression ? I know it's a bit late your time, > but pls reverse this...i did not ask for it. > > Thanks and sorry if I said something which caused this confusion, > > Hormuzd > > -----Original Message----- > From: avri@psg.com [mailto:avri@psg.com] > Sent: Sunday, October 24, 2004 11:10 PM > To: Khosravi, Hormuzd M > Cc: Weiming Wang; forces-protocol@ietf.org; Ligang Dong; Robert Haas; > ram.gopal@nokia.com; Jamal Hadi Salim > Subject: 01-8 > > http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-8.txt > > On 25 okt 2004, at 01.33, Khosravi, Hormuzd M wrote: > >> Avri, >> >> I am back and here is a list of quick changes... >> >> Acknowledgments - pls move this to the end of the draft as Jamal >> suggested, doesn't seem fair to the authors I think. > > done. > don't see the fairness issue, but i have moved as per your > instructions. > >> >> Author Addresses - pls add all our names and address along with yours >> and Remove Appendix A. You can get most of it from the Requirements > RFC >> (I am surprised no one noticed this before, including myself:)) > > can't add the addresses without the header as far as i know - certainly > can't in xml. the only addresses that belong in the address section in > the end are the ones in the header and are the ones that need to be > contacted during 48 hours. > > i have added all the names to the header as per your instructions. > >> >> Section 7.1 -> Replace State maintenance msg in the text With Config >> msg >> Replace >> | S.M. Activate FE | >> |<----------------------| >> With >> | Config-Activate FE | >> |<----------------------| >> >> Section 7.2 -> >> Replace >> | S.M. FE Deactivate | >> |<----------------------| >> With >> | Config-FE Deactivate | >> |<----------------------| >> >> > > done > >> The author addresses moving around is important and fair to all of us >> who have contributed a lot to this protocol. >> > > is this a different instruction the the one you gave me in the > beginning of this note? > > a. > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:28:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23219 for ; Mon, 25 Oct 2004 02:28:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyYt-0006mx-3s for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:42:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyLE-0003Wy-LJ; Mon, 25 Oct 2004 02:28:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyHE-0001ts-FQ for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:24:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22741 for ; Mon, 25 Oct 2004 02:24:18 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyUc-0006fb-VP for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:38:11 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9P6Rkrk026252; Mon, 25 Oct 2004 06:27:46 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9P6HHJU027828; Mon, 25 Oct 2004 06:17:17 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102423234401529 ; Sun, 24 Oct 2004 23:23:44 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 24 Oct 2004 23:23:44 -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 Date: Sun, 24 Oct 2004 23:23:33 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579220@orsmsx408> Thread-Topic: 01-8 Thread-Index: AcS6WVnmvv1i/KnmSJypql9dohHqKgAAVbMw From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 25 Oct 2004 06:23:44.0554 (UTC) FILETIME=[2DBFA0A0:01C4BA5B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas Subject: [Forces-protocol] RE: 01-8 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Avri, -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 > > Author Addresses - pls add all our names and address along with yours > and Remove Appendix A. You can get most of it from the Requirements RFC > (I am surprised no one noticed this before, including myself:)) can't add the addresses without the header as far as i know - certainly=20 can't in xml. the only addresses that belong in the address section in=20 the end are the ones in the header and are the ones that need to be=20 contacted during 48 hours. [HK] For the Requirements RFC, we listed all the authors addresses at the end and only the Editors names in the front (header). We actually listed the Editors addresses separately at the end, you can do the same here...no problem with that. Have the rules changed again, in this regard ? Pls correct me if I am wrong... Thanks=20 Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:30:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23313 for ; Mon, 25 Oct 2004 02:30:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyaD-0006oO-KX for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:43:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyLF-0003X2-0c; Mon, 25 Oct 2004 02:28:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyJp-0003Nq-7s for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:27:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23053 for ; Mon, 25 Oct 2004 02:26:59 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyXD-0006kG-PQ for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:40:52 -0400 Received: from [202.96.99.56] (helo=202.96.99.56) by mx2.foretec.com with smtp (Exim 4.24) id 1CLyJt-0000sV-8J for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:27:05 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Mon, 25 Oct 2004 14:47:07 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Mon, 25 Oct 2004 14:22:49 +0800 Message-ID: <01a001c4ba5b$57078f40$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07E0257921F@orsmsx408> Date: Mon, 25 Oct 2004 14:24:53 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Robert Haas , Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] Re: 01-8 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 It's really a misunderstanding. Avri, pls change back. ----- Original Message ----- From: "Khosravi, Hormuzd M" Subject: RE: 01-8 Avri, You definitely misunderstood me, I did not ask you at add all our names in the front page...just asked you to add our addresses in the end...what gave you this impression ? I know it's a bit late your time, but pls reverse this...i did not ask for it. Thanks and sorry if I said something which caused this confusion, Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com] Sent: Sunday, October 24, 2004 11:10 PM To: Khosravi, Hormuzd M Cc: Weiming Wang; forces-protocol@ietf.org; Ligang Dong; Robert Haas; ram.gopal@nokia.com; Jamal Hadi Salim Subject: 01-8 http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-8.txt On 25 okt 2004, at 01.33, Khosravi, Hormuzd M wrote: > Avri, > > I am back and here is a list of quick changes... > > Acknowledgments - pls move this to the end of the draft as Jamal > suggested, doesn't seem fair to the authors I think. done. don't see the fairness issue, but i have moved as per your instructions. > > Author Addresses - pls add all our names and address along with yours > and Remove Appendix A. You can get most of it from the Requirements RFC > (I am surprised no one noticed this before, including myself:)) can't add the addresses without the header as far as i know - certainly can't in xml. the only addresses that belong in the address section in the end are the ones in the header and are the ones that need to be contacted during 48 hours. i have added all the names to the header as per your instructions. > > Section 7.1 -> Replace State maintenance msg in the text With Config > msg > Replace > | S.M. Activate FE | > |<----------------------| > With > | Config-Activate FE | > |<----------------------| > > Section 7.2 -> > Replace > | S.M. FE Deactivate | > |<----------------------| > With > | Config-FE Deactivate | > |<----------------------| > > done > The author addresses moving around is important and fair to all of us > who have contributed a lot to this protocol. > is this a different instruction the the one you gave me in the beginning of this note? a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:35:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23634 for ; Mon, 25 Oct 2004 02:35:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyfe-0006u1-MQ for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:49:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyQi-0003yV-7g; Mon, 25 Oct 2004 02:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyOe-0003os-PQ for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:32:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23412 for ; Mon, 25 Oct 2004 02:31:59 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyc3-0006q7-6X for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:45:51 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9P6W9Qm023709; Mon, 25 Oct 2004 06:32:09 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9P6ObJe031182; Mon, 25 Oct 2004 06:24:56 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102423312702302 ; Sun, 24 Oct 2004 23:31:27 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 24 Oct 2004 23:31:28 -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 Date: Sun, 24 Oct 2004 23:31:17 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579222@orsmsx408> Thread-Topic: 01-8 Thread-Index: AcS6Wx9WPHsg1BqORnqHM4UxTbvPgAAAKPPQ From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 25 Oct 2004 06:31:28.0122 (UTC) FILETIME=[420E7DA0:01C4BA5C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas Subject: [Forces-protocol] RE: 01-8 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Avri, Just add our addresses to the end of the draft. Pls remove our names from the header and list your name as it was before. That is all I asked for, I don't think there should be any problem with that, Thanks Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 Sent: Sunday, October 24, 2004 11:23 PM To: Khosravi, Hormuzd M Cc: Weiming Wang; forces-protocol@ietf.org; Ligang Dong; Robert Haas; ram.gopal@nokia.com; Jamal Hadi Salim Subject: Re: 01-8 can't have the addresses in the back without having them in the front. =20 i have just spent the last hour adding them. now you want me to remove=20 them? a. On 25 okt 2004, at 02.19, Khosravi, Hormuzd M wrote: > Avri, > > You definitely misunderstood me, I did not ask you at add all our names > in the front page...just asked you to add our addresses in the > end...what gave you this impression ? I know it's a bit late your time, > but pls reverse this...i did not ask for it. > > Thanks and sorry if I said something which caused this confusion, > > Hormuzd > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:36:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23658 for ; Mon, 25 Oct 2004 02:36:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyg4-0006uI-60 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:50:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyQm-0003yZ-Lp; Mon, 25 Oct 2004 02:34:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyOz-0003p5-9B for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:32:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23454 for ; Mon, 25 Oct 2004 02:32:19 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLycG-0006qJ-5s for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:46:12 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Mon, 25 Oct 2004 14:51:58 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Mon, 25 Oct 2004 14:27:40 +0800 Message-ID: <01ad01c4ba5c$0437f470$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07E02579220@orsmsx408> Date: Mon, 25 Oct 2004 14:29:44 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Robert Haas , Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] Re: 01-8 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Hi Hormuzd, Avri as well. I think it's not bad to keep a 'Author' section at the first pages, while at the draft end, followed by a 'Author Address' section. I don't think it's necessary to remove the first 'Author' section if it is allowed to be there. What you mean may ask Avri to change the 'Author Address' section to be normal rather than a table of email list, right? Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Subject: RE: 01-8 Avri, -----Original Message----- From: avri@psg.com [mailto:avri@psg.com] > > Author Addresses - pls add all our names and address along with yours > and Remove Appendix A. You can get most of it from the Requirements RFC > (I am surprised no one noticed this before, including myself:)) can't add the addresses without the header as far as i know - certainly can't in xml. the only addresses that belong in the address section in the end are the ones in the header and are the ones that need to be contacted during 48 hours. [HK] For the Requirements RFC, we listed all the authors addresses at the end and only the Editors names in the front (header). We actually listed the Editors addresses separately at the end, you can do the same here...no problem with that. Have the rules changed again, in this regard ? Pls correct me if I am wrong... Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:37:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23787 for ; Mon, 25 Oct 2004 02:37:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyhY-0006w1-7M for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:51:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyTb-00049a-HY; Mon, 25 Oct 2004 02:37:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyRY-00041s-Pv for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:35:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23591 for ; Mon, 25 Oct 2004 02:34:59 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyew-0006sl-DE for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:48:51 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9P6Y6r8019196; Mon, 25 Oct 2004 06:34:06 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9P6c6sE016133; Mon, 25 Oct 2004 06:38:09 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102423342408059 ; Sun, 24 Oct 2004 23:34:24 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 24 Oct 2004 23:34:24 -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 Date: Sun, 24 Oct 2004 23:34:12 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579223@orsmsx408> Thread-Topic: 01-8 Thread-Index: AcS6XEXK22wRECqaSbmPnH7iLWlqxQAABIeQ From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 25 Oct 2004 06:34:24.0844 (UTC) FILETIME=[AB6420C0:01C4BA5C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Robert Haas , Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] RE: 01-8 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Exactly, you got it right Weiming...thats all I asked for. I am not sure what gave Avri a different impression...but I can understand...its 2:30 AM in the morning her time! Thanks for doing this, Avri! Hormuzd -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn]=20 Sent: Sunday, October 24, 2004 11:30 PM To: Khosravi, Hormuzd M; avri@psg.com Cc: forces-protocol@ietf.org; Ligang Dong; Robert Haas; ram.gopal@nokia.com; Jamal Hadi Salim Subject: Re: 01-8 Hi Hormuzd, Avri as well. I think it's not bad to keep a 'Author' section at the first pages, while at the draft end, followed by a 'Author Address' section. I don't think it's necessary to remove the first 'Author' section if it is allowed to be there. What you mean may ask Avri to change the 'Author Address' section to be normal rather than a table of email list, right? Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" Subject: RE: 01-8 Avri, -----Original Message----- From: avri@psg.com [mailto:avri@psg.com] > > Author Addresses - pls add all our names and address along with yours > and Remove Appendix A. You can get most of it from the Requirements RFC > (I am surprised no one noticed this before, including myself:)) can't add the addresses without the header as far as i know - certainly can't in xml. the only addresses that belong in the address section in the end are the ones in the header and are the ones that need to be contacted during 48 hours. [HK] For the Requirements RFC, we listed all the authors addresses at the end and only the Editors names in the front (header). We actually listed the Editors addresses separately at the end, you can do the same here...no problem with that. Have the rules changed again, in this regard ? Pls correct me if I am wrong... Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:41:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23985 for ; Mon, 25 Oct 2004 02:41:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyld-0006zL-09 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:55:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyXC-0004Mv-Pb; Mon, 25 Oct 2004 02:40:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyWa-0004KL-90 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:40:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23944 for ; Mon, 25 Oct 2004 02:40:10 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyjy-0006y7-Ln for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:54:03 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9P6FUep000963; Mon, 25 Oct 2004 08:15:31 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579220@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579220@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] RE: 01-8 Date: Mon, 25 Oct 2004 02:40:06 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit On 25 okt 2004, at 02.23, Khosravi, Hormuzd M wrote: > Avri, > > -----Original Message----- > From: avri@psg.com [mailto:avri@psg.com] >> >> Author Addresses - pls add all our names and address along with yours >> and Remove Appendix A. You can get most of it from the Requirements > RFC >> (I am surprised no one noticed this before, including myself:)) > > can't add the addresses without the header as far as i know - certainly > can't in xml. the only addresses that belong in the address section in > the end are the ones in the header and are the ones that need to be > contacted during 48 hours. > > [HK] For the Requirements RFC, we listed all the authors addresses at > the end and only the Editors names in the front (header). We actually > listed the Editors addresses separately at the end, you can do the same > here...no problem with that. Have the rules changed again, in this > regard ? Pls correct me if I am wrong... > i am totally at a loss to know how to satisfy you all on this address thing. xml certainly does not support listing as authors in the back and not in the front. i am sure there is someway around it, but the point is the authors addresses in the back are supposed to correspond to the addresses in the header. i expect you did not use xml in the requirements. i can't believe you started this all at the last minute. it is now 2:30 in the morning and instead of doing a read through i am ditzing around with addresses. i expect i will try to submit with the entire list. see what happens. it will probably get through the id editor - just won't get through rfc editor without special petitions and good reasons. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:43:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24079 for ; Mon, 25 Oct 2004 02:43:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLynP-00071B-Q7 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 02:57:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyZD-0004TM-Vg; Mon, 25 Oct 2004 02:42:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyYq-0004PX-MW for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:42:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24037 for ; Mon, 25 Oct 2004 02:42:31 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLymF-000702-8s for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:56:23 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9P6Hqep000972; Mon, 25 Oct 2004 08:17:52 +0200 In-Reply-To: <011b01c4ba59$a233b590$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E0257921A@orsmsx408> <011b01c4ba59$a233b590$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <09EA59E1-2651-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Re: 01-7- Quick Updates to draft! Date: Mon, 25 Oct 2004 02:42:28 -0400 To: "Wang,Weiming" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit On 25 okt 2004, at 02.12, Wang,Weiming wrote: > Thank Hormuzd for the address summary. A little change to my and ligang > addresses, pls Avri help to fit in. One more thing is, I suggest to > list the > address still along the sequence of ABC, just as in the first page. yes, Dong's name will be first. if that is what you mean. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:46:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24203 for ; Mon, 25 Oct 2004 02:46:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyqG-00074G-8b for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 03:00:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLybs-0004hz-SD; Mon, 25 Oct 2004 02:45:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyb3-0004ec-7P for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:44:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24143 for ; Mon, 25 Oct 2004 02:44:47 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyoR-00071m-R2 for forces-protocol@ietf.org; Mon, 25 Oct 2004 02:58:40 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9P6mErk002087; Mon, 25 Oct 2004 06:48:14 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9P6beJY004711; Mon, 25 Oct 2004 06:37:45 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102423441703452 ; Sun, 24 Oct 2004 23:44:17 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 24 Oct 2004 23:44:17 -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 Date: Sun, 24 Oct 2004 23:44:02 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579224@orsmsx408> Thread-Topic: Feedback on section 6.3 Thread-Index: AcS5QAsAX0qkSGFIQsaswILUFnWiNwBF4SaQ From: "Khosravi, Hormuzd M" To: , X-OriginalArrivalTime: 25 Oct 2004 06:44:17.0227 (UTC) FILETIME=[0C7A99B0:01C4BA5E] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Robert Haas , Weiming Wang , Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] RE: Feedback on section 6.3 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Jamal, Thanks for your comments and very sorry for the delay in responding to you, I hope you will understand (having a 6 month old yourself)... Pls see my replies below... -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 section 6.3 - 6.3.1 Config Message + "Config data" should be "Config data and path" [Sure, this is minor, I'll make this change in the next version] + Type is bad to describe operations. That should be operations [not sure what you mean?, this is according to your diagram] + UPDATE/REPLACE, DEL ALL are really flag extensions which will become clear once we have path-data noise cleared. Suggest you remove. [These are basic operations everyone (including model team) agrees with, I don't think these are related with path-data in any way...] + What is PACKET SUBSCRIBE/UNSUBSCRIBE? [This is to support the Requirements RFC section 6 #9 "The ForCES protocol MUST also define a way for the CE to configure the behavior of a) and b) (above), to specify which packets are affected by each"...I you have an alternative way to support this in the protocol messages, let me know] - 6.3.2 Config Response Message Why do we have " Operation Result " As far as i can see it is sufficient to look at the Main header type, a operation, path and its associated data. Unless this is meant to be a less verbose result? [exactly, that's the reason] + BTW, what is the point of mentioning "single or Array LFB specific result entries" or result might be TLV. Just say the=20 presentation of the data is stuill under discussion. [sure, I will make this change as well in the next release...hopefully we have more details by then ] Thanks & Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:48:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24295 for ; Mon, 25 Oct 2004 02:48:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLysA-00076j-5G for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 03:02:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLydy-0004u8-7i; Mon, 25 Oct 2004 02:47:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLydc-0004q8-U8 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:47:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24261 for ; Mon, 25 Oct 2004 02:47:27 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyr1-000768-Js for forces-protocol@ietf.org; Mon, 25 Oct 2004 03:01:20 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9P6Mlep000990; Mon, 25 Oct 2004 08:22:48 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579220@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579220@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Date: Mon, 25 Oct 2004 02:47:24 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , Weiming Wang , Robert Haas Subject: [Forces-protocol] 01-9 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-9.txt _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:49:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24348 for ; Mon, 25 Oct 2004 02:49:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLytB-00077z-Qk for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 03:03:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyf1-00050o-FD; Mon, 25 Oct 2004 02:48:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyeS-0004xQ-E6 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:48:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24292 for ; Mon, 25 Oct 2004 02:48:18 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CLyro-00076G-VZ for forces-protocol@ietf.org; Mon, 25 Oct 2004 03:02:11 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Mon, 25 Oct 2004 15:06:50 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Mon, 25 Oct 2004 14:42:32 +0800 Message-ID: <022701c4ba5e$17fc2830$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E02579220@orsmsx408> Subject: Re: [Forces-protocol] RE: 01-8 Date: Mon, 25 Oct 2004 14:44:36 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ram.gopal@nokia.com, Jamal Hadi Salim , Robert Haas , Ligang Dong , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hi Avri, I know xml2rfc does not support direct author address listing. I suggest you may just use a normal section to currently add it. Later when you have much time, you can add the xml2rfc style address listing. does it help? weiming ----- Original Message ----- From: To: "Khosravi, Hormuzd M" Cc: ; "Jamal Hadi Salim" ; "Ligang Dong" ; ; "Robert Haas" ; "Weiming Wang" Sent: Monday, October 25, 2004 2:40 PM Subject: Re: [Forces-protocol] RE: 01-8 > > On 25 okt 2004, at 02.23, Khosravi, Hormuzd M wrote: > > > Avri, > > > > -----Original Message----- > > From: avri@psg.com [mailto:avri@psg.com] > >> > >> Author Addresses - pls add all our names and address along with yours > >> and Remove Appendix A. You can get most of it from the Requirements > > RFC > >> (I am surprised no one noticed this before, including myself:)) > > > > can't add the addresses without the header as far as i know - certainly > > can't in xml. the only addresses that belong in the address section in > > the end are the ones in the header and are the ones that need to be > > contacted during 48 hours. > > > > [HK] For the Requirements RFC, we listed all the authors addresses at > > the end and only the Editors names in the front (header). We actually > > listed the Editors addresses separately at the end, you can do the same > > here...no problem with that. Have the rules changed again, in this > > regard ? Pls correct me if I am wrong... > > > > i am totally at a loss to know how to satisfy you all on this address > thing. > > xml certainly does not support listing as authors in the back and not > in the front. i am sure there is someway around it, but the point is > the authors addresses in the back are supposed to correspond to the > addresses in the header. i expect you did not use xml in the > requirements. > > i can't believe you started this all at the last minute. it is now > 2:30 in the morning and instead of doing a read through i am ditzing > around with addresses. > > i expect i will try to submit with the entire list. see what happens. > it will probably get through the id editor - just won't get through rfc > editor without special petitions and good reasons. > > > > a. > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:53:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24497 for ; Mon, 25 Oct 2004 02:53:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyx1-0007BT-N5 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 03:07:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyig-0005GB-6l; Mon, 25 Oct 2004 02:52:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyhh-0005C1-7O for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:51:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24444 for ; Mon, 25 Oct 2004 02:51:39 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyv5-00079j-VG for forces-protocol@ietf.org; Mon, 25 Oct 2004 03:05:32 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9P6t6rk004858; Mon, 25 Oct 2004 06:55:06 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9P6spsE024627; Mon, 25 Oct 2004 06:54:51 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102423510810166 ; Sun, 24 Oct 2004 23:51:08 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 24 Oct 2004 23:51:08 -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 Subject: RE: [Forces-protocol] RE: 01-8 Date: Sun, 24 Oct 2004 23:50:50 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579226@orsmsx408> Thread-Topic: [Forces-protocol] RE: 01-8 Thread-Index: AcS6XXwzKdVpb5jLTKC35z73v8MS9AAAQfJA From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 25 Oct 2004 06:51:08.0921 (UTC) FILETIME=[01DE1E90:01C4BA5F] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Ok, I didn't realize this is an XML problem...i am not an XML expert, but this was definitely very easy to do in Word. I would go with Weiming's suggestion and make this change in the final text file, instead of figuring out XML right now. Again, I apologize for the delay...i had no idea this would be so difficult with XML. Thanks & regards Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 i am totally at a loss to know how to satisfy you all on this address=20 thing. xml certainly does not support listing as authors in the back and not=20 in the front. i am sure there is someway around it, but the point is=20 the authors addresses in the back are supposed to correspond to the=20 addresses in the header. i expect you did not use xml in the=20 requirements. i can't believe you started this all at the last minute. it is now=20 2:30 in the morning and instead of doing a read through i am ditzing=20 around with addresses. i expect i will try to submit with the entire list. see what happens. =20 it will probably get through the id editor - just won't get through rfc=20 editor without special petitions and good reasons. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 02:58:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24700 for ; Mon, 25 Oct 2004 02:58:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLz1p-0007Ft-R3 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 03:12:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLylh-0005Ta-EV; Mon, 25 Oct 2004 02:55:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLylR-0005Ql-7k for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:55:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24569 for ; Mon, 25 Oct 2004 02:55:31 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyyo-0007D6-Vs for forces-protocol@ietf.org; Mon, 25 Oct 2004 03:09:24 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9P6Upep001011; Mon, 25 Oct 2004 08:30:52 +0200 In-Reply-To: <022701c4ba5e$17fc2830$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E02579220@orsmsx408> <022701c4ba5e$17fc2830$845c21d2@Necom.hzic.edu.cn> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] RE: 01-8 Date: Mon, 25 Oct 2004 02:55:27 -0400 To: "Wang,Weiming" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit On 25 okt 2004, at 02.44, Wang,Weiming wrote: > I know xml2rfc does not support direct author address listing. I > suggest you may > just use a normal section to currently add it. Later when you have > much time, > you can add the xml2rfc style address listing. does it help? it would still be a separate section, e.g. an appendix. i cannot figure out a way to put the names in the normal author's section without also putting them in the header. as i said, i figure the id editor will let it pass, so we can have the header fight some other time. it is still my hope that the WG chairs will pick editors and put an put an end to the question. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 03:00:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24755 for ; Mon, 25 Oct 2004 03:00:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLz3A-0007HF-NL for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 03:13:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLyoo-0005aX-Ih; Mon, 25 Oct 2004 02:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLym5-0005Uc-O5 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 02:56:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24615 for ; Mon, 25 Oct 2004 02:56:12 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLyzU-0007Ds-GF for forces-protocol@ietf.org; Mon, 25 Oct 2004 03:10:04 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9P6Upeq001011; Mon, 25 Oct 2004 08:31:33 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579226@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579226@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] RE: 01-8 Date: Mon, 25 Oct 2004 02:56:09 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Weiming Wang , forces-protocol@ietf.org, Jamal Hadi Salim , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit On 25 okt 2004, at 02.50, Khosravi, Hormuzd M wrote: > Again, I apologize for the delay...i had no idea this would be so > difficult with XML. XML is not hard. it follows the rules precisely. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 03:18:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26083 for ; Mon, 25 Oct 2004 03:18:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzLM-0007cI-Du for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 03:32:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLz6s-0006xF-FR; Mon, 25 Oct 2004 03:17:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLz3K-0006go-GB for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 03:14:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25720 for ; Mon, 25 Oct 2004 03:14:00 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzGj-0007W2-69 for forces-protocol@ietf.org; Mon, 25 Oct 2004 03:27:53 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9P7D9r8001640; Mon, 25 Oct 2004 07:13:09 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9P76wJU020747; Mon, 25 Oct 2004 07:06:58 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102500132906339 ; Mon, 25 Oct 2004 00:13:29 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 00:13:30 -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 Subject: RE: [Forces-protocol] RE: 01-8 Date: Mon, 25 Oct 2004 00:13:19 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579227@orsmsx408> Thread-Topic: [Forces-protocol] RE: 01-8 Thread-Index: AcS6X6G0ZllXic/2THWzkoeFafBnIgAASC7Q From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" X-OriginalArrivalTime: 25 Oct 2004 07:13:30.0235 (UTC) FILETIME=[215A64B0:01C4BA62] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Jamal Hadi Salim , ram.gopal@nokia.com, Robert Haas , Ligang Dong , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Avri, Just to clarify my position one final time, I believe you are the editor of this draft and I did not intent to start any fight again. I was thinking of the Requirements RFC when I asked you to add our addresses. If it is easy enough, we should just do this in the final generated text file...the header should list your name as editor and the small text paragraph with our names (authors) as it was before (01-7) and we should have all our addresses at the end. That's all. IMHO, this will have no issues with the id or rfc editor, Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 Sent: Sunday, October 24, 2004 11:55 PM To: Wang,Weiming Cc: Ligang Dong; forces-protocol@ietf.org; Robert Haas; Jamal Hadi Salim; Khosravi, Hormuzd M; ram.gopal@nokia.com Subject: Re: [Forces-protocol] RE: 01-8 On 25 okt 2004, at 02.44, Wang,Weiming wrote: > I know xml2rfc does not support direct author address listing. I=20 > suggest you may > just use a normal section to currently add it. Later when you have=20 > much time, > you can add the xml2rfc style address listing. does it help? it would still be a separate section, e.g. an appendix. i cannot=20 figure out a way to put the names in the normal author's section=20 without also putting them in the header. as i said, i figure the id editor will let it pass, so we can have the=20 header fight some other time. it is still my hope that the WG chairs will pick editors and put an put=20 an end to the question. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 03:28:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26531 for ; Mon, 25 Oct 2004 03:28:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzUs-0007km-LU for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 03:42:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzGd-0007e7-LF; Mon, 25 Oct 2004 03:27:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzCb-0007P7-I9 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 03:23:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26355 for ; Mon, 25 Oct 2004 03:23:35 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzPz-0007gT-Iz for forces-protocol@ietf.org; Mon, 25 Oct 2004 03:37:29 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9P6wtep001094; Mon, 25 Oct 2004 08:58:55 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579227@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579227@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] RE: 01-8 Date: Mon, 25 Oct 2004 03:23:31 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , "Wang, Weiming" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit On 25 okt 2004, at 03.13, Khosravi, Hormuzd M wrote: > Just to clarify my position one final time, I believe you are the > editor > of this draft and I did not intent to start any fight again. I was > thinking of the Requirements RFC when I asked you to add our addresses. > If it is easy enough, we should just do this in the final generated > text > file...the header should list your name as editor and the small text > paragraph with our names (authors) as it was before (01-7) and we > should > have all our addresses at the end. That's all. ok. does this variant meet with your approval? http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-10.txt a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 03:31:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26690 for ; Mon, 25 Oct 2004 03:31:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzXm-0007oF-Pa for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 03:45:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzJS-0007tC-Ni; Mon, 25 Oct 2004 03:30:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzJI-0007rL-4h for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 03:30:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26670 for ; Mon, 25 Oct 2004 03:30:30 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzWh-0007mf-2U for forces-protocol@ietf.org; Mon, 25 Oct 2004 03:44:23 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9P7Xvrk020537; Mon, 25 Oct 2004 07:33:57 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9P7XWsE011736; Mon, 25 Oct 2004 07:33:39 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102500295015417 ; Mon, 25 Oct 2004 00:29:50 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 00:29:50 -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 Subject: RE: [Forces-protocol] RE: 01-8 Date: Mon, 25 Oct 2004 00:29:38 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579228@orsmsx408> Thread-Topic: [Forces-protocol] RE: 01-8 Thread-Index: AcS6Y41H8LNPTQ6HQUKFdbMMZ6S7fQAAIoog From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 25 Oct 2004 07:29:50.0343 (UTC) FILETIME=[698B0170:01C4BA64] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , "Wang, Weiming" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Yes, this is exactly what I requested. Thanks a lot, I am glad we resolved this misunderstanding! Good Night! Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 Sent: Monday, October 25, 2004 12:24 AM To: Khosravi, Hormuzd M Cc: Ligang Dong; forces-protocol@ietf.org; Wang,Weiming; Robert Haas; Jamal Hadi Salim; ram.gopal@nokia.com Subject: Re: [Forces-protocol] RE: 01-8 On 25 okt 2004, at 03.13, Khosravi, Hormuzd M wrote: > Just to clarify my position one final time, I believe you are the=20 > editor > of this draft and I did not intent to start any fight again. I was > thinking of the Requirements RFC when I asked you to add our addresses. > If it is easy enough, we should just do this in the final generated=20 > text > file...the header should list your name as editor and the small text > paragraph with our names (authors) as it was before (01-7) and we=20 > should > have all our addresses at the end. That's all. ok. does this variant meet with your approval? http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-10.txt a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 03:37:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27058 for ; Mon, 25 Oct 2004 03:37:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzd5-0007tf-PL for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 03:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzNW-00089f-Ph; Mon, 25 Oct 2004 03:34:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLzNA-00086I-G4 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 03:34:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26989 for ; Mon, 25 Oct 2004 03:34:30 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzaZ-0007rJ-ED for forces-protocol@ietf.org; Mon, 25 Oct 2004 03:48:23 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9P79oep001118; Mon, 25 Oct 2004 09:09:51 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579228@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579228@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4C9FC587-2658-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] RE: 01-8 Date: Mon, 25 Oct 2004 03:34:26 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , "Wang, Weiming" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit On 25 okt 2004, at 03.29, Khosravi, Hormuzd M wrote: > Yes, this is exactly what I requested. > > Thanks a lot, I am glad we resolved this misunderstanding! > > by moving it to an appendix, i think it looks a little better. as it then comes at the right place in the document. do you still approve? http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-11.txt _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 04:21:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00156 for ; Mon, 25 Oct 2004 04:21:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM0KS-0000Kg-8w for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 04:35:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM03t-0002SR-J2; Mon, 25 Oct 2004 04:18:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM03A-0002Ol-U7 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 04:17:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29850 for ; Mon, 25 Oct 2004 04:17:44 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM0GQ-0000Ee-2H for forces-protocol@ietf.org; Mon, 25 Oct 2004 04:31:38 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9P7r4ep001211; Mon, 25 Oct 2004 09:53:05 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579228@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579228@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <572328E8-265E-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Date: Mon, 25 Oct 2004 04:17:41 -0400 To: forces-protocol@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Hormuzd M Khosravi , Jamal Hadi Salim Subject: [Forces-protocol] draft-ietf-forces-protocol-01.txt X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit I have submitted the following draft: http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-11.txt hope it is ok. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 05:12:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03329 for ; Mon, 25 Oct 2004 05:12:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM17X-0001Dj-H8 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 05:26:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM0tw-0008EE-Oo; Mon, 25 Oct 2004 05:12:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM0sv-0007ut-Cb for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 05:11:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03251 for ; Mon, 25 Oct 2004 05:11:22 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CM15S-00019V-GP for forces-protocol@ietf.org; Mon, 25 Oct 2004 05:25:17 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Mon, 25 Oct 2004 17:30:12 +0800 (CST) Received: from dlg (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with SMTP id ; Mon, 25 Oct 2004 17:05:52 +0800 Message-ID: <00c601c4ba72$241599d0$8401a8c0@dlg> From: "Ligang Dong" To: References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> <1098383190.2883.386.camel@localhost.localdomain> <00dd01c4b803$806bd620$8401a8c0@dlg> <1098442868.1112.38.camel@jzny.localdomain> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Mon, 25 Oct 2004 17:08:06 +0800 MIME-Version: 1.0 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 X-Spam-Score: 1.4 (+) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , Zsolt Haraszti , "Joel M. Halpern" , forces-protocol@ietf.org, "Wang, Weiming" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1856779557==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 --===============1856779557== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGksIEphbWFsLCANClNvcnJ5IGZvciB0aGUgZGVsYXkgYmVjYXVzZSBvZiBteSBob2xpZGF5Lg0K SSBsaWtlIHlvdXIgZXhhbXBsZSBhbHRob3VnaCBJIGhhdmUgbm90IHVzZWQgQVNJQyBpbiBteSBp bXBsZW1lbnRhdGlvbiBwcm90b3R5cGUuDQpNeSBjdXJyZW50IGV4cGVyaWVuY2VzIHRlbGwgbWUg dGhhdCBtdWx0aWNhc3QgYWRkcmVzc2luZyBjYW4gbWFrZSB0aGUgbWVzc2FnZSBzaW1wbGVyIGFu ZCBoYXZlIGJldHRlciB0cmFuc21pc3Npb24gZWZmaWNpZW5jeS4NCg0KSW4geW91ciBkZXNpZ24g YWJvdXQgdGhlIG11bHRpY2FzdCwgSSBub3RpY2UgdGhhdCB5b3UgdXNlICJMRkJJbnN0YW5jZU1h c2siLiBJdCBtZWFucyB0aGF0IHlvdSB1c2UgbXVsdGljYXN0IGFkZHJlc3MuIEl0IGlzIG9idmlv dXNseSBhbiBhcHByb2FjaC4gQW5vdGhlciBhcHByb2FjaCBpcyB0byB1c2UgYSBsaXN0IG9mIGlu Y2x1ZGVkIExGQiBpbnN0YW5jZSBhZGRyZXNzZXMuDQoNCmJlc3QgcmVnYXJkcw0KTGlnYW5nDQoN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKYW1hbCBIYWRpIFNhbGlt IiA8aGFkaUB6bnl4LmNvbT4NClRvOiAiTGlnYW5nIERvbmciIDxkb25nbGdAbWFpbC5oemljLmVk dS5jbj4NCkNjOiAiWnNvbHQgSGFyYXN6dGkiIDx6c29sdEBtb2R1bGFybmV0LmNvbT47ICJXYW5n LFdlaW1pbmciIDx3bXdhbmdAbWFpbC5oemljLmVkdS5jbj47ICJLaG9zcmF2aSwgSG9ybXV6ZCBN IiA8aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbT47ICJKb2VsIE0uIEhhbHBlcm4iIDxqaGFs cGVybkBtZWdpc3RvLmNvbT47IDxyYW0uZ29wYWxAbm9raWEuY29tPjsgIlN0ZXZlbiBCbGFrZSAo cGV0cmktbWVhdCkiIDxzbGJsYWtlQHBldHJpLW1lYXQuY29tPjsgIkFsYW4gRGVLb2siIDxhbGFu LmRla29rQGlkdC5jb20+OyA8Zm9yY2VzLXByb3RvY29sQGlldGYub3JnPjsgIkVsbGVuIE0gRGVs ZWdhbmVzIiA8ZWxsZW4ubS5kZWxlZ2FuZXNAaW50ZWwuY29tPjsgIllhbmcsTGlseSBMIiA8bGls eS5sLnlhbmdAaW50ZWwuY29tPg0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDIyLCAyMDA0IDc6MDEg UE0NClN1YmplY3Q6IFJlOiBbRm9yY2VzLXByb3RvY29sXSBSRTogR0VUL1NFVCBpbiBvbmUgbXNn ID8NCg0KDQo+IExpZ2FuZywNCj4gDQo+IExldHMgY29udGludWUgdGhpcyBkaXNjdXNzaW9uIGFz c3VtaW5nIHdlIGRvbnQgbmVlZCB0byB1cGRhdGUgYW55dGhpbmcNCj4gaW4gdGhlIGRyYWZ0IGZv ciBub3cuDQo+IA0KPiBDYW4geW91IGV4cGxhaW4gdW5kZXIgd2hpY2ggY2lyY3Vtc3RhbmNlcyBp dCB3YXMgZGVzaXJhYmxlIHRvIGRvDQo+IG11bHRpY2FzdCB0byBzZXZlcmFsIGluc3RhbmNlcz8N Cj4gSSBjYW4gZ2l2ZSB5b3UgYW4gZXhhbXBsZSB3aGVyZSB0aGlzIHdvdWxkIGJlIHZhbHVhYmxl IHRvIG1lOg0KPiBUd28gb2YgdGhlIChjb21tb2RpdHkpIEFTSUNzIHdlIHVzZSBoYXZlIGEgdGFi bGUgcGVyIHNldCBvZiBwb3J0cw0KPiByYW5naW5nIGZyb20gMS04IHBvcnRzIHBlciB0YWJsZS4g U28gSSBjb3VsZCBoYXZlIGFueXdoZXJlDQo+IDYtMjQgTFBNIHRhYmxlcyBmb3IgZXhhbXBsZSBv biB0aGUgc2FtZSBGRSAtIGRlcGVuZGluZyBvbiB0aGUgY2hpcCBwb3J0DQo+IGVudW1lcmF0aW9u IG9yIGJvYXJkIGxheW91dC4gVG8gbWUgdGhlc2UgYXJlIDYtNDggaW5zdGFuY2VzIG9mIHRoZSBz YW1lDQo+IChMUE0pIExGQi4gd2hlbiBpIGxvb2sgYXQgYWxsIG9mIHRoZW0gYXMgcGFydCBvZiBh IHNpbmdsZSBORSwgSSBoYXZlDQo+IGRvbmUgc29tZSByb3VnaCBjYWxjdWxhdGlvbiBhbmQgYW55 d2hlcmUgYmV0d2VlbiA5MC04MCUgb2YgdGhlIHRpbWUNCj4gaSB3b3VsZCBzZW5kIHRoZSBfc2Ft ZV8gdGFibGUgdmFsdWVzLiBUaGUgcmVzdCBvZiB0aGUgdGltZSB0aGV5IHdpbGwNCj4gdmFyeS4g DQo+IFNvIHRvIG1lIHRoZSBtdXRsaWNhc3QvYnJvYWRjYXN0L3BvcnQgcmFuZ2UgaXMgdmFsdWFi bGUuIEkgZG9udCB0aGluaw0KPiB0aGlzIGlzIG9ubHkgdmFsdWFibGUgdG8gbWUgb3IgeW91IChT b3JyeSBpIG1pc3NlZCB0aGUgcmVhc29uaW5nIG9uIHlvdXINCj4gYW5kIFdlaW1pbmcgcGFydCBp biB0aGUgZW1haWwgdGhyZWFkKSwgcmF0aGVyIHRoZXNlIGFyZSBjb21tb2RpdHkgQVNJQ3MNCj4g d2hpY2ggaSBleHBjdGUgdG8gYmUgdXNlZCBhIGxvdCB0byBoZWxwIEZvckNFUyBiZWNvbWUgdWJp cXVpdG91cy4gRm9sa3MsDQo+IFdlIGNhbnQganVzdCBpZ25vcmUgdGhlIGZhY3QgdGhleSBleGlz dCBhbmQgaG9wZSB0aGV5IHdpbGwgZ28gYXdheS4NCj4gDQo+IE15IG9waW5pb24sIHNpbmNlIHdl IGFyZSBkaXNjdXNzaW5nIHRoaXMgcG9zdCBkcmFmdCByZWxlYXNlOg0KPiBUbyBicmluZyBiYWNr IG9sZCBkaXNjdXNzaW9ucyAoQXBvbG9naWVzIGluIGFkdmFuY2UpLCB0byBtZWV0IHRoZSBhYm92 ZQ0KPiByZXF1aXJlbWVudHMsIG9uZSB3b3VsZCBuZWVkIHRvIHNwbGl0IHRoZSBncmFtbWFyIHNv IHdlIGhhdmUgYSBJbnN0YW5jZQ0KPiBzZWxlY3RvciBsZXZlbCB3aGVyZSB3ZSBjb3VsZCBoYXZl IHNwZWNpZmljIGluc3RhbmNlcyB3aXRoaW4gYSBjbGFzczsgYXMNCj4gd2VsbCBhYmlsaXR5IHRv IHNlbGVjdCBtdWx0aXBsZSBpbiBvbmUgaW5zdGFuY2Ugc2VsZWN0aW9uOyBpLmUgc29tZXRoaW5n DQo+IGFsb25nIHRoZSBsaW5lcyBvZiAoaG9wZWZ1bGx5IGRpYWdyYW1zIGxvb2sgcmlnaHQpOg0K PiANCj4gDQo+ICAgICAgKy0tLSBUID0gTEZCc2VsZWN0DQo+ICAgICAgfCAgICAgICAgfCAgICAN Cj4gICAgICB8ICAgICAgICB8DQo+ICAgICAgfCAgICAgICAgKy0tIExGQkNMQVNTSUQgPSAweDQ1 IA0KPiAgICAgIHwgICAgICAgIHwNCj4gICAgICB8ICAgICAgICArLS0tVCA9IExGQlRBUkdFVF9V TklDQVNUDQo+ICAgICAgfCAgICAgICAgfCAgICAgfA0KPiAgICAgIHwgICAgICAgIHwgICAgICst LSBMRkJJbnN0YW5jZSA9IDB4NDMyMQ0KPiAgICAgIHwgICAgICAgIHwgICAgIHwNCj4gICAgICB8 ICAgICAgICB8ICAgICArLS0gVCA9IEFERA0KPiAgICAgIHwgICAgICAgIHwgICAgIHwgICB8DQo+ ICAgICAgfCAgICAgICAgfCAgICAgfCAgICstLSAgLy8gcGF0aC1kYXRhIA0KPiAgICAgIHwgICAg ICAgIHwgICAgIHwgICAgICAgIA0KPiAgICAgIHwgICAgICAgIHwgICAgDQo+ICAgICAgfCAgICAg ICAgKy0tLVQgPSBMRkJUQVJHRVRfTUNBU1QNCj4gICAgICB8ICAgICAgICB8ICAgICB8DQo+ICAg ICAgfCAgICAgICAgfCAgICAgKy0tIExGQkluc3RhbmNlID0gMHgxMjM0DQo+ICAgICAgfCAgICAg ICAgfCAgICAgfA0KPiAgICAgIHwgICAgICAgIHwgICAgIHwNCj4gICAgICB8ICAgICAgICB8ICAg ICArLS0gTEZCSW5zdGFuY2VNYXNrID0gMHhmDQo+ICAgICAgfCAgICAgICAgfCAgICAgfA0KPiAg ICAgIHwgICAgICAgIHwgICAgICstLSBUID0gQUREDQo+ICAgICAgfCAgICAgICAgfCAgICAgfCAg IHwNCj4gICAgICB8ICAgICAgICB8ICAgICB8ICAgKy0tICAvLyBwYXRoLWRhdGENCj4gICAgICB8 ICAgICAgICB8ICAgICB8ICAgICAgDQo+ICAgICAgfCAgICAgICAgfCAgICAgfA0KPiAgICAgIHwg ICAgICAgIHwgICAgDQo+ICAgICAgfCAgICAgICAgKy0tLVQgPSBMRkJUQVJHRVRfVU5JQ0FTVA0K PiAgICAgIHwgICAgICAgIHwgICAgIHwNCj4gICAgICB8ICAgICAgICB8ICAgICArLS0gTEZCSW5z dGFuY2UgPSAweDU2NzgNCj4gICAgICB8ICAgICAgICB8ICAgICB8DQo+ICAgICAgfCAgICAgICAg fCAgICAgKy0tIFQgPSBERUwNCj4gICAgICB8ICAgICAgICB8ICAgICB8ICAgfA0KPiAgICAgIHwg ICAgICAgIHwgICAgIHwgICArLS0gIC8vIHBhdGgtZGF0YQ0KPiAgICAgIHwgICAgICAgIHwgICAg IHwgICAgICANCj4gICAgICB8ICAgICAgICB8ICAgICB8DQo+IA0KPiBBcG9sb2dpZXMgaWYgdGhp cyBpcyB3aGF0IGlzIGJlaW5nIGRpc2N1c3NlZCBhbHJlYWR5IGluIHRocmVhZA0KPiBpbnZvbHZp bmcgU3RldmUvUm9iZXJ0L1dlaW1pbmcuDQo+IEFnYWluLCBJIG1heSBoYXZlIG1pc2NvbnRydWVk IHlvdXIgbmVlZCwgYnV0IHBsZWFzZSBjaGlwIGluLg0KPiANCj4gY2hlZXJzLA0KPiBqYW1hbA0K PiANCj4gDQo+IE9uIEZyaSwgMjAwNC0xMC0yMiBhdCAwMjo1MSwgTGlnYW5nIERvbmcgd3JvdGU6 DQo+ID4gaGksDQo+ID4gDQo+ID4gVGhlIGZvbGxvd2luZyBpcyBteSBvcGluaW9uIGFib3V0IHRo ZSBkZWJhdGUgd2hldGhlciBtdWx0aWNhc3QgKGkuZS4sIG11bHRpcGxlIGFkZHJlc3NpbmcpIG9m IExGQiBJbnN0YW5jZSBpcyByZXF1aXJlZCBvciBub3QuIA0KPiA+IA0KPiA+ICgxKSBJbiBwYXN0 IHNldmVyYWwgbW9udGhzLCBJIGFtIGVuZ2FnZWQgaW4gdGhlIGltcGxlbWVudGF0aW9uIG9mIEZv ckNFUyAmIEdSTVAuIFRpbGwgbm93LCBhIGJhc2ljIHByb3RvdHlwZSBpcyBhbHJlYWR5IGNvbnN0 cnVjdGVkLiBBbHNvIGl0IGhhcyBiZWVuIHNob3duIHRvIHNldmVyYWwgZ3V5cyBpbiB0aGlzIHJl c2VhcmNoIGZpZWxkLiBGcm9tIHRoZSB2aWV3IG9mIGltcGxlbWVudGF0aW9uLCB0aGUgbXVsdGlj YXN0IG9mIExGQiBpbnN0YW5jZSBpcyBlYXN5LiANCj4gPiAoMikgRnVydGhlcm1vcmUsIG11bHRp Y2FzdCBvZiBMRkIgaW5zdGFuY2UgaXMgbW9yZSBlZmZpY2llbnQgdGhhbiB0aGUgInVuaWNhc3Qi IGFwcHJvYWNoIGFuZCB0aGUgInZpcnR1YWxJRCIgYXBwcm9hY2guIFRoZXJlZm9yZSwgd2h5IG5v dCBhZG9wdCBtdWx0aWNhc3Qgb2YgTEZCIGluc3RhbmNlIGluIHRoZSBwcm90b2NvbC4gDQo+ID4g YmVzdCByZWdhcmRzDQo+ID4gTGlnYW5nDQo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LSANCj4gPiBGcm9tOiAiWnNvbHQgSGFyYXN6dGkiIDx6c29sdEBtb2R1bGFybmV0LmNvbT4NCj4g PiBUbzogIldhbmcsV2VpbWluZyIgPHdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuPg0KPiA+IENjOiAi S2hvc3JhdmksIEhvcm11emQgTSIgPGhvcm11emQubS5raG9zcmF2aUBpbnRlbC5jb20+OyAiSm9l bCBNLiBIYWxwZXJuIiA8amhhbHBlcm5AbWVnaXN0by5jb20+OyA8cmFtLmdvcGFsQG5va2lhLmNv bT47ICJTdGV2ZW4gQmxha2UgKHBldHJpLW1lYXQpIiA8c2xibGFrZUBwZXRyaS1tZWF0LmNvbT47 ICJBbGFuIERlS29rIiA8YWxhbi5kZWtva0BpZHQuY29tPjsgIkphbWFsIEhhZGkgU2FsaW0iIDxo YWRpQHpueXguY29tPjsgPGZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZz47ICJFbGxlbiBNIERlbGVn YW5lcyIgPGVsbGVuLm0uZGVsZWdhbmVzQGludGVsLmNvbT47ICJZYW5nLExpbHkgTCIgPGxpbHku bC55YW5nQGludGVsLmNvbT4NCj4gPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMDQgMjoy NiBBTQ0KPiA+IFN1YmplY3Q6IFJlOiBbRm9yY2VzLXByb3RvY29sXSBSRTogR0VUL1NFVCBpbiBv bmUgbXNnID8NCj4gPiANCj4gPiANCj4gPiA+IFdlaW1pbmcsDQo+ID4gPiANCj4gPiA+IEkgaGF2 ZSBhIHZlcnkgaGFyZCB0aW1lIHRvIHJlc29uYXRlIHdpdGggeW91ciBleGFtcGxlcywgYW5kIHRo ZXJlZm9yZQ0KPiA+ID4gd2l0aCB5b3VyIHJlYXNvbmluZy4NCj4gPiA+IA0KPiA+ID4gRm9yIG9u ZSwgaWYgeW91IGVuZCB1cCBuZWVkaW5nIDY0ayBMRkJzIGZyb20gdGhlIHNhbWUgY2xhc3MsIEkg dGhpbmsNCj4gPiA+IHlvdSBvciB3ZSBkaWQgc29tZXRoaW5nIHdyb25nIHdpdGggdGhlIG1vZGVs LiAgU3VyZSB5b3UgbWVhbiBpdCBhbg0KPiA+ID4gZXh0cmVtZSBjYXNlLCBidXQgSSB0aGluayBp dCBpcyBhIG1pc2xlYWRpbmcgb25lLiAgSSBlbnZpc2lvbg0KPiA+ID4gcHJhY3RpY2FsIExGQiBt b2RlbHMgaGF2aW5nIHVwIHRvIGEgZmV3IGh1bmRyZWQgTEZCIGluc3RhbmNlcywgd2hlcmUNCj4g PiA+IG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgc2FtZSBjbGFzcyB3aWxsIGJlIGluIHZlcnkg ZGlmZmVyZW50IHJvbGVzDQo+ID4gPiAoZS5nLiwgYSBDbGFzc2lmaWVyIExGQiBzdXBwb3J0aW5n IERpZmZzZXJ2IHZlcnN1cyBhIENsYXNzaWZpZXINCj4gPiA+IExGQiBzdXBwb3J0aW5nIElQc2Vj LCBldGMuKSwgaGVuY2UgbW9yZSBvZnRlbiBub3Qgc2hhcmluZyBhbnkgY29uZmlnDQo+ID4gPiBk YXRhIHRoYW4gc2hhcmluZyBzb21lLg0KPiA+ID4gDQo+ID4gPiBGb3IgdHdvLCBkaXNwbGFjaW5n IHRoZSB0d28gcGFydHMgb2YgdGhlIExGQiBhZGRyZXNzIChjbGFzcyBJRCBhbmQNCj4gPiA+IGlu c3RhbmNlIElEKSBpbiB0aGUgcHJvdG9jb2wgaXMgYSBtdWNoIGJpZ2dlciBjb25jZXJuIHRvIG1l IHRoYW4gdG8NCj4gPiA+IGFsbG93IGFkLWhvYy9zdGF0ZS1sZXNzIG11bHRpY2FzdCBhZGRyZXNz aW5nLiAgSXQgd291bGQgYmUgaW4gc29tZQ0KPiA+ID4gc2Vuc2Ugc2ltaWxhciB0byBpZiBpbiB0 aGUgSVAgaGVhZGVyIHRoZSAoc3ViLSluZXR3b3JrIGFkZHJlc3MgYW5kDQo+ID4gPiBob3N0LWFk ZHJlc3MgcGFydCBvZiB0aGUgSVAgYWRkcmVzcyB3ZXJlIHBsYWNlZCBpbiBkaXN0YW50IG9mZnNl dHMuDQo+ID4gPiANCj4gPiA+IEZvciB0aHJlZSwgb24gc3RhdGUtbGVzcyB2ZXJzdXMgc3RhdGUt ZnVsIG11bHRpY2FzdDogIFlvdXIgZXhhbXBsZQ0KPiA+ID4gYmVsb3cgaXMgYmFzZWQgb24gdGhl IHZlcnkgZXh0cmVtZSBjYXNlIHdoZW4geW91IGhhdmUgYSBTSU5HTEUNCj4gPiA+IGNvbmZpZyBt ZXNzYWdlIGFkZHJlc3NlZCB0byBhIFZFUlkgTEFSR0UgbnVtYmVyIG9mIExGQiBpbnN0YW5jZXMN Cj4gPiA+IG9mIHRoZSBzYW1lIGNsYXNzLiAgSSBoYXZlIG5vdCB5ZXQgc2VlbiBhIHByYWN0aWNh bCBjYXNlIGZvciB0aGlzDQo+ID4gPiBzY2VuYXJpby4gIEkgcmVpdGVyYXRlIHRoYXQgbXVsdGlj YXN0IGdyb3VwcyBhcmUgbm90IGFkLWhvYywgYW5kDQo+ID4gPiB0aGVyZSB3aWxsIGJlIHR5cGlj YWxseSBhIGxhcmdlIG51bWJlciBvZiBjb25maWcgdXBkYXRlcyBzZW50IHRvIGENCj4gPiA+IGdy b3VwIGFmdGVyIHRoZSBncm91cCBpcyBmb3JtZWQuDQo+ID4gPiANCj4gPiA+IFJlZ2FyZHMsDQo+ ID4gPiBac29sdA0KPiA+ID4gDQo+ID4gPiBPbiBXZWQsIDIwMDQtMTAtMjAgYXQgMDE6NTYsIFdh bmcsV2VpbWluZyB3cm90ZToNCj4gPiA+ID4gSm9lbCwNCj4gPiA+ID4gDQo+ID4gPiA+IC0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gPiA+ID4gRnJvbTogIkpvZWwgTS4gSGFscGVybiIg PGpoYWxwZXJuQE1FR0lTVE8uY29tPg0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW0ZvcmNlcy1wcm90 b2NvbF0gUkU6IEdFVC9TRVQgaW4gb25lIG1zZyA/DQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ ID4gPiBJIGRvIHRoaW5rIHRoYXQgdGhlcmUgbWF5IGJlIHRob3VzYW5kcyBvZiBpbnN0YW5jZXMu DQo+ID4gPiA+ID4gSSBkbyBub3QgdGhpbmsgdGhhdCB0aGlzIHJlcXVpcmVzIG11bHRpcGxlIGFk ZHJlc3NpbmcuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIHRoaW5rIHRoYXQgdGhlcmUgYXJlIHNv bWUgaW50ZXJlc3RpbmcgY2FzZXMgcHJvbXB0ZWQgYnkgdGhlIHBvc3NpYmlsaXR5DQo+ID4gPiA+ ID4gb2YgdmVyeSBsYXJnZSBudW1iZXJzIG9mIExGQnMsIGJ1dCB0aGV5IGRvIG5vdCBkcml2ZSBt dWx0aXBsZSBhZGRyZXNzaW5nLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gTXkgcmVhc29uaW5nIGlz IGJhc2VkIG9uIHRoZSBmb2xsb3dpbmcgcHJlbWlzZS4NCj4gPiA+ID4gPiBGaXJzdGx5LCBpZiB0 aGVyZSBhcmUgbWFueSBMRkJpbnN0YW5jZXMgcyBvZiBhIGNsYXNzLCB0aGVuIGl0IGlzIGxpa2Vs eQ0KPiA+ID4gPiA+IHRoYXQgbWFueSBmaWVsZHMgb2YgdGhlIExGQiBpbnN0YW5jZXMgd2lsbCBi ZSB0aGUgc2FtZSwgYnV0IGl0IGlzIGV4dHJlbWVseQ0KPiA+ID4gPiA+IHVubGlrZWx5IHRoYXQg YWxsIGZpZWxkcyBvZiB0aGUgTEZCIGluc3RhbmNlcyB3aWxsIGJlIHRoZSBzYW1lLg0KPiA+ID4g PiBbV2VpbWluZ11UaGF0J3MganVzdCB3aHkgZXhwbGljaXQgbXVsdGlwdWwgYWRkcmVzc2luZyBp cyBuZWVkZWQuIEZvciB0aGUgY2FzZSBvZg0KPiA+ID4gPiBmaWVsZHMgb2YgYWxsIExGQmluc2F0 bmNlcyBhcmUgdGhlIHNhbWUsIHdlIGNhbiBzaW1wbHkgdXNlIGEgYnJvYWRjYXN0IHRvIGRvIHNv Lg0KPiA+ID4gPiBMZXQgbWUgdHJ5IHRvIHNob3cgYSBzY2VuYXJpbyB3aHkgbXVsdGlwdWwgYWRk cmVzc2luZyBpcyBuZWVkZWQgZm9yIGRpZmZlcmVudA0KPiA+ID4gPiBmaWVsZHMgY2FzZS4NCj4g PiA+ID4gDQo+ID4gPiA+IEZpcnN0bHksIGJlY2F1c2Ugd2UgaGF2ZSBhc3N1bWVkIHRoZSAxNmJp dCBpbnNhdG5jZSBJZCBpcyBub3QgZW5vdWdoLCB3ZSBjYW4NCj4gPiA+ID4gcmVhc29uYWJseSBh c3NtdWUgdGhlcmUgaXMgYSBjYXNlIHdoZXJlIHRoZXJlIGFyZSA2NGsgb3IgbW9yZSBpbnN0YW5j ZXMgKHNheQ0KPiA+ID4gPiA2NGspLiBGdXJ0aGVyLCB3ZSBzdXBwb3NlIElkMSB0byBJZDMyayBu ZWVkIHRvIGNvbmZpZyBwYXJhbWV0ZXIgMSwgSWQoMzJrKzEpIHRvDQo+ID4gPiA+IElkIDY0ayB0 byBzZXQgcGFyYW1ldGVyMi4NCj4gPiA+ID4gDQo+ID4gPiA+IFRoZW4sIGJ5IHVzaW5nIHNpbmds ZSBpbnN0YW5jZSBhZGRyZXNzaW5nLCB0aGUgcHJvdG9jb2wgYmVjb21lcyBob3JyaWJsZSwgZWl0 aGVyDQo+ID4gPiA+IHVzaW5nIG9uZSBtZXNzYWdlIG9yIHVzaW5nIHNlcGFyYXRlIG1lc3NhZ2Vz LiBJIGp1c3Qgc2hvdyB0aGUgb25lIG1lc3NhZ2UgY2FzZS4NCj4gPiA+ID4gVGhlIG1lc3NhZ2Ug Zm9ybWF0IHdvdWxkIGxpa2UgbGlrZToNCj4gPiA+ID4gDQo+ID4gPiA+IE1zZ2hkcg0KPiA+ID4g PiBMRkJzZWxlY3QNCj4gPiA+ID4gTEZCQ2xhc3NJRA0KPiA+ID4gPiBJbnN0YW5jZSBJRDENCj4g PiA+ID4gUGFyYW1ldGVyMQ0KPiA+ID4gPiBJbnN0YW5jZSBJRDINCj4gPiA+ID4gUGFyYW1ldGVy MQ0KPiA+ID4gPiAuLi4NCj4gPiA+ID4gLi4uDQo+ID4gPiA+IEluc3RhbmNlIElEIDMyaw0KPiA+ ID4gPiBQYXJhbWV0ZXIxDQo+ID4gPiA+IEluc2F0bmNlIElEICgzMmsrMSkNCj4gPiA+ID4gUGFy YW1ldGVyMg0KPiA+ID4gPiAuLi4uDQo+ID4gPiA+IEluc3RhbmNlIElEIDY0aw0KPiA+ID4gPiBQ YXJhbWV0ZXIgMg0KPiA+ID4gPiANCj4gPiA+ID4gUmVtZW1iZXIgd2UgdGhlbiBoYXZlIDY0ayBw YWlyIG9mIGluc3RhbmNlIGFuZCBwYXJhbWV0ZXIgaW4gdGhlIHByb3RvY29sIHRleHQuDQo+ID4g PiA+IEluIHNvbWUgY2FzZXMsIEknbSBqdXN0IHdvcnJpZWQgdGhpcyBtYWtlIHByb3RvY29sIHVu cHJhY3RpY2FsLg0KPiA+ID4gPiANCj4gPiA+ID4gQnkgdXNpbmcgbXVsdGlwdWwgYWRkcmVzc2lu ZywgdGhlIG9ubHkgdGV4dCBpcyBhczoNCj4gPiA+ID4gTXNnaGRyDQo+ID4gPiA+IExGQnNlbGVj dA0KPiA+ID4gPiBMRkJDbGFzc0lEDQo+ID4gPiA+IEluc3RhbmNlIElEMSB0byBJRCAzMmsNCj4g PiA+ID4gUGFyYW1ldGVyMQ0KPiA+ID4gPiBJbnN0YW5jZSBJRCAoMzJrKzEpIHRvIElEIDY0aw0K PiA+ID4gPiBQYXJhbWV0ZXIyDQo+ID4gPiA+IA0KPiA+ID4gPiBCeSB1c2luZyBtdWx0aWNhc3Qg c2NoZW1lIHN1cHBvc2VkIGJ5IFpzb2x0LCBJIHN1cHBvc2Ugd2UgbmVlZCBmb2xsb3dpbmcgc3Rl cHM6DQo+ID4gPiA+IDEuIHNlbmQgYSBGRSBhdHRyaWJ1dGUgdG8gRkUgb2JqZWN0IHRvIHNldHVw IGEgdmlydHVhbElEMSBmb3IgSW5zdGFuY2UgMSB0bw0KPiA+ID4gPiBJbnN0YW5jZSAzMmsNCj4g PiA+ID4gMi4gc2VuZCBhIEZFIGF0dHJpYnV0ZSB0byBGRSBvYmplY3QgdG8gc2V0dXAgYSB2aXJ0 dWFsSUQyIGZvciBJbnN0YW5jZSAoMzJrKzEpDQo+ID4gPiA+IHRvIEluc3RhbmNlIDY0aw0KPiA+ ID4gPiAzLiBjb25maWc6DQo+ID4gPiA+IE1zZ2hkcg0KPiA+ID4gPiBMRkJzZWxlY3QNCj4gPiA+ ID4gTEZCQ2xhc3NJRA0KPiA+ID4gPiBWaXJ0dWFsIElEMQ0KPiA+ID4gPiBQYXJhbWV0ZXIxDQo+ ID4gPiA+IFZpcnR1YWwgSUQyDQo+ID4gPiA+IFBhcmFtZXRlcjINCj4gPiA+ID4gNC4gc2VuZCBh IG1lc3NhZ2UgdG8gcmVsZWFzZSB2aXJ0dWFsIElEMQ0KPiA+ID4gPiA1LiBzZW5kIGEgbWVzc2Fn ZSB0byByZWxlYXNlIHZpcnR1YWwgSUQyDQo+ID4gPiA+IA0KPiA+ID4gPiBJIGNhbiBzZWUgdGhl IGFkdmF0YWdlIG9mIGFib3ZlIGV4cGxpY2l0IG11bHRpcHVsIGFkZHJlc3Npbmcgc2NoZW1lIHZl cnkNCj4gPiA+ID4gY2xlYXJseS4NCj4gPiA+ID4gDQo+ID4gPiA+ID4gVGhlIHNpbXBsZXN0IGNh c2UgdG8gdW5kZXJzdGFuZCB3aGVuIG9uZSB3b3VsZCBuZWVkIHRvIHNldHVwIGFsbCB0aG9zZSBM RkJzDQo+ID4gPiA+ID4gYXQgb25jZSBpcyBpbiBhIHBvd2VyIHJlY292ZXJ5IHNpdHVhdGlvbiAg KHRoZSBGRSBsb3N0IHBvd2VyLCB0aGVuDQo+ID4gPiA+ID4gcmVjb3ZlcmVkIHRvIGFuIGVtcHR5 IHN0YXRlLikgIFRoZSBDRSBuZWVkcyB0byBzZW5kIHRoZSBjb25maWd1cmF0aW9uDQo+ID4gPiA+ ID4gaW5mb3JtYXRpb24gdG8gdGhlIEZFLg0KPiA+ID4gPiBbV2VpbWluZ11ZZXMsIHRoYXQncyB0 aGUgb25lIGNhc2UgYnV0IG5vdCB0aGUgb25seS4NCj4gPiA+ID4gDQo+ID4gPiA+ID4gU2Vjb25k bHksIEkgYmVsaWV2ZSB0aGF0IHRyYW5zYWN0aW9uIGNvdW50IGlzIG11Y2ggbW9yZSBpbXBvcnRh bnQgdGhhbiBkYXRhDQo+ID4gPiA+ID4gdm9sdW1lLiAgVGhlIEZFIGlzIGdvaW5nIHRvIGhhdmUg dG8gc2V0IGV2ZXJ5IGZpZWxkIGluIGV2ZXJ5IExGQi4gIEVuY29kaW5nDQo+ID4gPiA+ID4gaXMg bm90IGdvaW5nIHRvIGNoYW5nZSB0aGF0Lg0KPiA+ID4gPiBbV2VpbWluZ11JJ20gbm90IHN1cmUg aWYgeW91IG1lYW4gZm9yIGV2ZXJ5IG9wZXJhdGlvbiwgd2Ugc2hvdWxkIG1haW50YWluIGENCj4g PiA+ID4gdHJhbnNhY3Rpb24gY291bnQuIElmIGlzLCB0aGVuIEkgaGF2ZSB0byBzYXkgb3VyIGN1 cnJlbnQgb25lIG1lc3NhZ2Ugd2l0aA0KPiA+ID4gPiBtdWx0aXBsZSBPcGVyYXRpb24gZGVmaW5p dGlvbnMgaGFzIGFscmVhZHkgYmUgYWdhaW5zdCB0aGUgcmVxdWlyZW1lbnQuIE15DQo+ID4gPiA+ IG9waW5pb24gaXMgdHJhbnNhY3Rpb24gbWFpbnRlbmFuY2UgaXMgbW9kZXJhdGUsIHdoaWxlIG11 bHRpY2FzdCBhbmQgbXVsdGlwbGUNCj4gPiA+ID4gb3BlcmF0aW9uIGFyZSBtb3JlIGltcG9ydGFu dC4NCj4gPiA+ID4gDQo+ID4gPiA+ID4gR2l2ZW4gdGhhdCB0aGVyZSBhcmUgZGlzdGluY3QgdmFs dWVzIGluIGVhY2ggTEZCIGluc3RhbmNlLCB0aGVyZSBtdXN0IGJlIGFuDQo+ID4gPiA+ID4gb3Bl cmF0aW9uIGFnYWluc3QgZWFjaCBMRkIgaW5zdGFuY2UuDQo+ID4gPiA+IEkgZG9uJ3QgdGhpbmsg bXVsdGljYXN0IHdpbGwgbG9vc2Ugb3BlcmF0aW9uIGluZGl2aWR1YWxpdHkuDQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiBUaGUgbWFyZ2luYWwgZ2FpbiBmcm9tIGhhdmluZyBhIHNpbmdsZSB0cmFuc2Fj dGlvbiB0byB1cGRhdGUgdGhlIGlkZW50aWNhbA0KPiA+ID4gPiA+IGZpZWxkcywgYW5kIHRoZW4g aW5kaXZpZHVhbCB0cmFuc2FjdGlvbnMgZm9yIHRoZSBkaXN0aW5jdCBmaWVsZHMgaXMgdmVyeQ0K PiA+ID4gPiA+IHNtYWxsLiAgSXQgZG9lcyBub3QgcmVkdWNlIHRoZSBudW1iZXIgb2YgSU9zIG9y IHRoZSBjb3JlIHRyYW5zYWN0aW9uIHJhdGUuDQo+ID4gPiA+IFtXZWltaW5nXUF0IGxlYXN0IGl0 IHNhdmVzIGJpdHMgZ3JlYXRseSBhbmQgbWFrZXMgcHJvdG9jb2wgcHJhY3RpY2FsLiBSZW1lbWJl cg0KPiA+ID4gPiB0aGUgY2FwYWJpbGl0eSBiZXR3ZWVuIENFIGFuZCBGRSBhcmUgcXVpdGUgbGlt aXRlZCwgZXNwZWNpYWxseSBpbiBtdWxpLWhvcA0KPiA+ID4gPiBGb3JDRVMgYXBwbGljYXRpb24u DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJZiBpdCBpcyBkZXNpcmVkIHRvIG9wdGltaXplIGZvciB0 aGlzIGNhc2UsIHdlIG1heSB3YW50IHRvIGludHJvZHVjZSAoaW4gYQ0KPiA+ID4gPiA+IGZ1dHVy ZSB2ZXJzaW9uIG9mIHRoZSBwcm90b2NvbCkgc29tZSBraW5kIG9mIGJsb2NrIGNoZWNrcG9pbnQg LyByZXN0YXJ0DQo+ID4gPiA+ID4gbWVjaGFuaXNtLiAgVGhlIENFIHdvdWxkIHJlY29yZCBpdHMg ZnVsbCBzdGF0ZSBhYm91dCB0aGUgRkUsIGFuZCB0aGVuIGFzaw0KPiA+ID4gPiA+IHRoZSBGRSBm b3IgYSBkdW1wIHN1aXRhYmxlIGZvciByZXN0b3JhbCBvZiB0aGUgRkUgc3RhdGUuICBVcG9uIHJl c3RhcnQsIHRoZQ0KPiA+ID4gPiA+IENFIHdvdWxkIHJlYnVpbGQgaXRzIHN0YXRlIGZyb20gaXRz IHN0b3JlZCByZXByZXNlbnRhdGlvbiwgYW5kIHdvdWxkIHNoaXANCj4gPiA+ID4gPiB0aGUgZHVt cCBiYWNrIHRvIHRoZSBGRSB0byBlbmFibGUgZWZmaWNpZW50IHJlYnVpbGRpbmcgdGhlcmUuICBJ IGNhbiBzZWUNCj4gPiA+ID4gPiBzaWduaWZpY2FudCB2YWx1ZSBpbiBzdWNoIGEgbWVjaGFuaXNt LiAgSSBkbyBub3QgaG93ZXZlciBzZWUgYSBuZWVkIHRvDQo+ID4gPiA+ID4gaW5jbHVkZSB0aGlz IGluIHRoZSBmaXJzdCBkZWxpdmVyYWJsZSBvZiB0aGUgcHJvdG9jb2wuDQo+ID4gPiA+IFtXZWlt aW5nXUkgc3VwcG9zZSB0aGlzIGlzIG9ubHkgZm9yIHJlc3RhcnQgY2FzZSwgSSBjYW4gc2VlIG1h bnkgY2FzZXMgd2hlcmUNCj4gPiA+ID4gbXVsdGlwbGUgYWRkcmVzc2luZyBjYW4gYXBwbHksIHN1 Y2ggYXMgZGVsZXRlLCBjaGFuZ2Ugb2YgTEZCIHBhcmFtZXRlciwgbG9hZCBhbmQNCj4gPiA+ID4g dW5sb2FkIG9mIExGQnMsIGV0Yy4gQW5kIGFsc28gSSB0aGluayB0aGUgc2NoZW1lIGFib3ZlIGlz IG11Y2ggbW9yZSBjb21wbGV4IHRoYW4NCj4gPiA+ID4gbXVsdGlwbGUgYWRkcmVzc2luZy4gU28s IG15IGNvbmNsdXNpb24gaXMsIHdpdGggYSBsaXR0bGUgYml0IGV4cGFuc2lvbiwgd2UgY2FuDQo+ ID4gPiA+IGdhaW4gbXVjaCwgdGhlbiB3aHkgbm90IHdlIGFkcG90IGl0Pw0KPiA+ID4gPiANCj4g PiA+ID4gQmVzdCByZWdhcmRzLA0KPiA+ID4gPiBXZWltaW5nDQo+ID4gPiA+ID4NCj4gPiA+ID4g PiBZb3VycywNCj4gPiA+ID4gPiBKb2VsIE0uIEhhbHBlcm4NCj4gPiA+ID4gDQo+ID4gPiAtLSAN Cj4gPiA+IFpzb2x0IEhhcmFzenRpICAgICAgICAgICAgICAgIFBob25lOiAgKzEgOTE5LTc2NS0w MDI3LzIwMTcNCj4gPiA+IE1vZHVsYXIgTmV0d29ya3MgICAgICAgICAgICAgIE1vYmlsZTogICAg ICArMSA5MTktNTIyLTIzMzcNCj4gPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVt YWlsOiAgenNvbHRAbW9kdWxhcm5ldC5jb20NCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gRm9yY2VzLXBy b3RvY29sIG1haWxpbmcgbGlzdA0KPiA+ID4gRm9yY2VzLXByb3RvY29sQGlldGYub3JnDQo+ID4g PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXMtcHJvdG9jb2wN Cj4gPiA+IA0KPiA= --===============1856779557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============1856779557==-- From forces-protocol-bounces@ietf.org Mon Oct 25 07:59:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18574 for ; Mon, 25 Oct 2004 07:59:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM3in-00050t-QC for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 08:13:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM3Se-0006b5-Fh; Mon, 25 Oct 2004 07:56:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM3RI-0006SZ-8I for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 07:55:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17965 for ; Mon, 25 Oct 2004 07:55:02 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM3ei-0004t8-Jw for forces-protocol@ietf.org; Mon, 25 Oct 2004 08:08:58 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9PBq1PJ143432; Mon, 25 Oct 2004 07:52:01 -0400 Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9PBpodh041296; Mon, 25 Oct 2004 07:51:55 -0400 Received: from [9.4.69.18] (dhcp69-18.zurich.ibm.com [9.4.69.18]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA27338; Mon, 25 Oct 2004 13:51:45 +0200 Message-ID: <417CE8C7.2050701@zurich.ibm.com> Date: Mon, 25 Oct 2004 13:51:35 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: avri@psg.com References: <468F3FDA28AA87429AD807992E22D07E02579228@orsmsx408> <572328E8-265E-11D9-9DB1-000393CC2112@psg.com> In-Reply-To: <572328E8-265E-11D9-9DB1-000393CC2112@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e3.ny.us.ibm.com id i9PBq1PJ143432 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: Hormuzd M Khosravi , "\(\(Ram Gopal \)\)" , Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , Weiming Wang Subject: [Forces-protocol] Re: draft-ietf-forces-protocol-01.txt X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Avri, Looks good. I have a few corrections, although not essential for now,=20 unless you can't sleep after all the excitment on the list ... - In the Config Response Msg section, the draft says Type (16 bits): The operations are same as those defined for Config messages. whereas the other messages (Query, Event Notif) have now explicitely=20 defined a "*-Response" operation type. The table should therefore now=20 look like: +-------------------+-------+------------+--------+-------------+ | Operation | Query | Query-Resp | Config | Config-Resp | +-------------------+-------+------------+--------+-------------+ | Set | | | X | | Set-Response X | | | | | | | Delete | | | X | | Delete-Response X | | | | | | | Update | | | X | | Update-Response X=20 | | | | | | | Get | X | | | | Get-Response X=20 | | | | | | | Event subscribe | | | X | | | Ev.Sub.-Response | | | | X | | | | | | | | Event unsubscribe | | | X | | | Ev.Unsub.-Response| | | | X | +-------------------+-------+------------+--------+-------------+ +-----------+--------------+-------------+------------------+ | Operation | Packet-Redir | Event-Notif | Event-Notif-Resp | +-----------+--------------+-------------+------------------+ | Payload | X | | | | | | | | | Report | | X | | |Report-Resp| | | X | +-----------+--------------+-------------+------------------+ Note that Operation "Event" was changed to "Report" And the text I quoted above in the Config-Resp section 6.3.2 should be=20 changed accordingly to : Type (16 bits): The operations include, ADD-Resp, DEL-Resp, UPDATE/REPLACE-Resp, D= EL ALL-Resp, EVENT SUBSCRIBE-Resp, EVENT UNSUBSCRIBE-Resp, PACKET SUBSCRIBE, CANCEL-R= esp. I would drop in 6.3.1 and 6.3.2 the operation types PACKET *SUBSCRIBE.=20 Note that all the messages above don't appear in the summary table, but=20 maybe we should not overload the table with all of them. - add an Editorial's note after the text below (search for MIID): * MIID table: a list of virtual LFB Instance IDs that map to a list of Instance IDs of LFBs in that FE Editoral's note: it remains to be decided whether such an MIID table=20 should be used. - search and correct typo "GET_RESPOSE" - add a newline between Inter-FE topology and Intra-FE topology (sec 6.1.= 2): Note: The attributes below were previously under Query message. * Inter-FE topology Intra-FE topology - you should appear as "Editor", not "co-editor". At least that's my=20 understanding. Also, the ETRI name appears on the first page. I thought=20 you said you didn't want that ? I personally don't care. - I like the name "Core ForCES LFBs" Thanks, -Robert avri@psg.com wrote: > I have submitted the following draft: > > http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-11.txt > > hope it is ok. > > a. > > > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 07:59:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18603 for ; Mon, 25 Oct 2004 07:59:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM3jT-00051Y-GW for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 08:13:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM3Sg-0006bt-JY; Mon, 25 Oct 2004 07:56:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM3Rc-0006TT-2H for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 07:55:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17998 for ; Mon, 25 Oct 2004 07:55:22 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM3f0-0004tk-WD for forces-protocol@ietf.org; Mon, 25 Oct 2004 08:09:17 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9PBsmEx600574 for ; Mon, 25 Oct 2004 07:54:48 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9PBslLV156772 for ; Mon, 25 Oct 2004 05:54:47 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9PBskDx009422 for ; Mon, 25 Oct 2004 05:54:46 -0600 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9PBsiuL009274; Mon, 25 Oct 2004 05:54:44 -0600 Received: from [9.4.69.18] (dhcp69-18.zurich.ibm.com [9.4.69.18]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA14814; Mon, 25 Oct 2004 13:54:43 +0200 Message-ID: <417CE979.4010606@zurich.ibm.com> Date: Mon, 25 Oct 2004 13:54:33 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E02579227@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579227@orsmsx408> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id i9PBsmEx600574 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, avri@psg.com, Jamal Hadi Salim , Ligang Dong Subject: [Forces-protocol] Meaning of PACKET *SUBSCRIBE operation type unclear X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Hormuzd, Could you please explain again the use of PACKET *SUBSCRIBE in the=20 Config msg ? Can we use another existing operation type and/or LFB for this ? Thanks, --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 13:03:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14260 for ; Mon, 25 Oct 2004 13:03:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8TH-0002zE-JD for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 13:17:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM87c-0003by-4j; Mon, 25 Oct 2004 12:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM82k-00005j-Fc for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 12:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13186 for ; Mon, 25 Oct 2004 12:49:59 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM8GE-0002fp-FB for forces-protocol@ietf.org; Mon, 25 Oct 2004 13:03:58 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102509522762:40879 ; Mon, 25 Oct 2004 09:52:27 -0700 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: Ligang Dong In-Reply-To: <00c601c4ba72$241599d0$8401a8c0@dlg> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> <1098383190.2883.386.camel@localhost.localdomain> <00dd01c4b803$806bd620$8401a8c0@dlg> <1098442868.1112.38.camel@jzny.localdomain> <00c601c4ba72$241599d0$8401a8c0@dlg> Organization: Znyx Networks Message-Id: <1098722995.1034.67.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Oct 2004 12:49:56 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/25/2004 09:52:27 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/25/2004 09:52:31 AM, Serialize complete at 10/25/2004 09:52:31 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Steven Blake \(petri-meat\)" , Zsolt Haraszti , "Joel M. Halpern" , forces-protocol@ietf.org, "Wang, Weiming" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hi Ligang, On Mon, 2004-10-25 at 05:08, Ligang Dong wrote: > hi, Jamal, > Sorry for the delay because of my holiday. > I like your example although I have not used ASIC in my implementation prototype. > My current experiences tell me that multicast addressing can make the message simpler and have better transmission efficiency. > > In your design about the multicast, I notice that you use "LFBInstanceMask". It means that you use multicast address. It is obviously an approach. Another approach is to use a list of included LFB instance addresses. I realized after i responded to you that the approach you posted is slightly different, but end goals the same. So far i think there are three approaches being talked about. 1) Yours 2) Steve/Robert with MIID (whcih unfortunately made it into the draft before consensus was reached) 3) What i posted Maybe someone needs to present at the meeting. Clearly this issue needs revisiting and we may have to make mods to the LFBSelect TLV. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 15:43:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27507 for ; Mon, 25 Oct 2004 15:43:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMAxj-0005uL-JE for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 15:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMAhs-0005Aw-B6; Mon, 25 Oct 2004 15:40:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMAdk-0003T1-Mi for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 15:36:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26988 for ; Mon, 25 Oct 2004 15:36:22 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMArC-0005lo-Mr for forces-protocol@ietf.org; Mon, 25 Oct 2004 15:50:22 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9PJBUep002380; Mon, 25 Oct 2004 21:11:31 +0200 In-Reply-To: <417CE8C7.2050701@zurich.ibm.com> References: <468F3FDA28AA87429AD807992E22D07E02579228@orsmsx408> <572328E8-265E-11D9-9DB1-000393CC2112@psg.com> <417CE8C7.2050701@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1F9AD305-26BD-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Re: draft-ietf-forces-protocol-01.txt Date: Mon, 25 Oct 2004 15:36:10 -0400 To: Robert Haas X-Mailer: Apple Mail (2.619) X-Spam-Score: 1.4 (+) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Cc: Hormuzd M Khosravi , "\(\(Ram Gopal \)\)" , Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , Weiming Wang X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: 7bit On 25 okt 2004, at 07.51, Robert Haas wrote: > Avri, > Looks good. I have a few corrections, although not essential for now, > unless you can't sleep after all the excitment on the list ... Too late. I went to sleep after submitting at 4:30 AM. Not that I could have changed anything after submitting. I submitted before going to sleep because I did not want to risk missing the deadline and was not sure that i would be able to do any useful editing after 2-3 sleep anyway. so these edits will go in -02 http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-02-1.txt > > - In the Config Response Msg section, the draft says > > Type (16 bits): > The operations are same as those defined for Config messages. > > whereas the other messages (Query, Event Notif) have now explicitely > defined a "*-Response" operation type. The table should therefore now > look like: > > +-------------------+-------+------------+--------+-------------+ > | Operation | Query | Query-Resp | Config | Config-Resp | > +-------------------+-------+------------+--------+-------------+ > | Set | | | X | | > Set-Response X > | | | | | | > | Delete | | | X | | > Delete-Response X > | | | | | | > | Update | | | X | | > Update-Response X | > | | | | | > | Get | X | | | | > Get-Response X | | | > | | | > | Event subscribe | | | X | | > | Ev.Sub.-Response | | | | X | > | | | | | | > | Event unsubscribe | | | X | | > | Ev.Unsub.-Response| | | | X | > +-------------------+-------+------------+--------+-------------+ > done > > +-----------+--------------+-------------+------------------+ > | Operation | Packet-Redir | Event-Notif | Event-Notif-Resp | > +-----------+--------------+-------------+------------------+ > | Payload | X | | | > | | | | | > | Report | | X | | > |Report-Resp| | | X | > +-----------+--------------+-------------+------------------+ > Note that Operation "Event" was changed to "Report" > done > > And the text I quoted above in the Config-Resp section 6.3.2 should be > changed accordingly to : > > Type (16 bits): > The operations include, ADD-Resp, DEL-Resp, UPDATE/REPLACE-Resp, > DEL ALL-Resp, EVENT > SUBSCRIBE-Resp, EVENT UNSUBSCRIBE-Resp, PACKET SUBSCRIBE, > CANCEL-Resp. done > > I would drop in 6.3.1 and 6.3.2 the operation types PACKET *SUBSCRIBE. I did not understand what you wanted here. i notice you include PACKET SUBSCRIBE in your change, but not UNSUBSCIBE. While 6.3.1 current has both. I am not sure what change you are suggesting. I have left them alone for the moment. > Note that all the messages above don't appear in the summary table, > but maybe we should not overload the table with all of them. don't mind adding them. what do folks think? i do need to find a way to adjust the table cell sizes so that it looks a little better. speaking of aesthetics, as the draft gets closer to being finished. i will work on getting pictures to stay on a single page. not worth the effort before then. that is assuming i stay in the (co) editor role. otherwise someone else can do it. > > - add an Editorial's note after the text below (search for MIID): > > * MIID table: a list of virtual LFB Instance IDs that map to a > list of Instance IDs of LFBs in that FE > > Editoral's note: it remains to be decided whether such an MIID table > should be used. done. I should have noticed this was still an open issue. Actually i did notice, i just forgot to note it in the draft. > > - search and correct typo "GET_RESPOSE" > found one instance. fixed. > - add a newline between Inter-FE topology and Intra-FE topology (sec > 6.1.2): > > Note: The attributes below were previously under Query > message. > * Inter-FE topology Intra-FE topology > done > > - you should appear as "Editor", not "co-editor". I have never been sure of that. and therefore listed myself as co-editor, since i was pretty sure i was functioning as at least that. > At least that's my understanding. Also, the ETRI name appears on the > first page. I thought you said you didn't want that ? I personally > don't care. i had removed it, but in the exercise to put all the names in the header, i reinserted and forgot to remove it. removed it now. > > - I like the name "Core ForCES LFBs" yeah, me too. > > Thanks, thank you. a. ps. i put repositories for -01 on the web site psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01.[txt, zip, tar, tsg] _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 19:43:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18344 for ; Mon, 25 Oct 2004 19:43:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEiH-0004Fr-Hx for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 19:57:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMDRr-0006JT-V8; Mon, 25 Oct 2004 18:36:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBSj-0002Fb-Ha for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 16:29:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04808 for ; Mon, 25 Oct 2004 16:29:02 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBgE-0007yA-W1 for forces-protocol@ietf.org; Mon, 25 Oct 2004 16:43:03 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9PKSRNX151308 for ; Mon, 25 Oct 2004 16:28:27 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9PKSQqo434062 for ; Mon, 25 Oct 2004 14:28:27 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9PKSQPC021317 for ; Mon, 25 Oct 2004 14:28:26 -0600 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9PKSNEm021134; Mon, 25 Oct 2004 14:28:24 -0600 Received: from [9.145.134.80] (sig-9-145-134-80.de.ibm.com [9.145.134.80]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA41746; Mon, 25 Oct 2004 22:28:16 +0200 Message-ID: <417D61D4.6000909@zurich.ibm.com> Date: Mon, 25 Oct 2004 22:28:04 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hadi@znyx.com Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> <1098383190.2883.386.camel@localhost.localdomain> <00dd01c4b803$806bd620$8401a8c0@dlg> <1098442868.1112.38.camel@jzny.localdomain> <00c601c4ba72$241599d0$8401a8c0@dlg> <1098722995.1034.67.camel@jzny.localdomain> In-Reply-To: <1098722995.1034.67.camel@jzny.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id i9PKSRNX151308 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Wang, Weiming" , "Joel M. Halpern" , Zsolt Haraszti , "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, Ligang Dong X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Jamal, Jamal Hadi Salim wrote: >I realized after i responded to you that the approach you posted is >slightly different, but end goals the same. So far i think there are >three approaches being talked about. >1) Yours >2) Steve/Robert with MIID (whcih unfortunately made it into the draft >before consensus was reached) > =20 > Sorry, that was not my intent. My understanding was that there was no=20 other proposal addressing this issue in particular. >3) What i posted=20 > =20 > I must have missed that. >Maybe someone needs to present at the meeting. > > =20 > Definitely. A short presentation summarizing all the options. I could=20 take care of that (probably need 30 min with the discussion). --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 19:49:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19509 for ; Mon, 25 Oct 2004 19:49:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEoN-0004ez-Ir for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:03:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEL4-00059J-6a; Mon, 25 Oct 2004 19:33:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBXe-0000nw-Bk for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 16:34:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05829 for ; Mon, 25 Oct 2004 16:34:07 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBl6-0008KK-W7 for forces-protocol@ietf.org; Mon, 25 Oct 2004 16:48:08 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9PKYEQm024740; Mon, 25 Oct 2004 20:34:14 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9PKQZJc019433; Mon, 25 Oct 2004 20:26:54 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102513332722625 ; Mon, 25 Oct 2004 13:33:27 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 13:33:27 -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 Subject: RE: [Forces-protocol] RE: 01-8 Date: Mon, 25 Oct 2004 13:33:26 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0302DC3C@orsmsx408> Thread-Topic: [Forces-protocol] RE: 01-8 Thread-Index: AcS6ZRUR240nrv45Rl2DphwkdcQeAwAbGw8Q From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 25 Oct 2004 20:33:27.0140 (UTC) FILETIME=[E1BCE240:01C4BAD1] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , "Wang, Weiming" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Avri, This is fine for now but I would prefer the Authors Addresses being a separate section rather than part of the Appendix cause that is how I have seen it in most RFCs including All the ForCES RFCs. I hope its not very difficult to make this change, Regards Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 > Yes, this is exactly what I requested. > > Thanks a lot, I am glad we resolved this misunderstanding! > > by moving it to an appendix, i think it looks a little better. as it=20 then comes at the right place in the document. do you still approve? http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-11.txt _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 19:49:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19539 for ; Mon, 25 Oct 2004 19:49:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEoQ-0004fK-GD for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:03:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMELd-0005NQ-Mg; Mon, 25 Oct 2004 19:33:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBZB-0003c5-DX for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 16:35:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06011 for ; Mon, 25 Oct 2004 16:35:42 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBmh-0008NM-7F for forces-protocol@ietf.org; Mon, 25 Oct 2004 16:49:43 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9PKZsQm025678; Mon, 25 Oct 2004 20:35:55 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9PKQwKM019775; Mon, 25 Oct 2004 20:28:37 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102513351022982 ; Mon, 25 Oct 2004 13:35:10 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 13:35:10 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Oct 2004 13:35:08 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0302DC49@orsmsx408> Thread-Topic: draft-ietf-forces-protocol-01.txt Thread-Index: AcS6iTMyo20TNpE/SVOipDhic+KjEQASL1kw From: "Khosravi, Hormuzd M" To: "Robert Haas" , X-OriginalArrivalTime: 25 Oct 2004 20:35:10.0515 (UTC) FILETIME=[1F5AA830:01C4BAD2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: "\(\(Ram Gopal \)\)" , Jamal Hadi Salim , Weiming Wang , Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] RE: draft-ietf-forces-protocol-01.txt X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable Robert,=20 It seems to me like some of the changes below need to be discussed = before they are made in the draft. Most are editorial though, Regards Hormuzd -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Monday, October 25, 2004 4:52 AM To: avri@psg.com Cc: forces-protocol@ietf.org; Khosravi, Hormuzd M; Jamal Hadi Salim; = ((Ram Gopal )); Ligang Dong; Weiming Wang Subject: Re: draft-ietf-forces-protocol-01.txt Avri, Looks good. I have a few corrections, although not essential for now,=20 unless you can't sleep after all the excitment on the list ... - In the Config Response Msg section, the draft says Type (16 bits): The operations are same as those defined for Config messages. whereas the other messages (Query, Event Notif) have now explicitely=20 defined a "*-Response" operation type. The table should therefore now=20 look like: +-------------------+-------+------------+--------+-------------+ | Operation | Query | Query-Resp | Config | Config-Resp | +-------------------+-------+------------+--------+-------------+ | Set | | | X | | Set-Response X | | | | | | | Delete | | | X | | Delete-Response X | | | | | | | Update | | | X | | Update-Response X=20 | | | | | | | Get | X | | | | Get-Response X=20 | | | | | | | Event subscribe | | | X | | | Ev.Sub.-Response | | | | X | | | | | | | | Event unsubscribe | | | X | | | Ev.Unsub.-Response| | | | X | +-------------------+-------+------------+--------+-------------+ +-----------+--------------+-------------+------------------+ | Operation | Packet-Redir | Event-Notif | Event-Notif-Resp | +-----------+--------------+-------------+------------------+ | Payload | X | | | | | | | | | Report | | X | | |Report-Resp| | | X | +-----------+--------------+-------------+------------------+ Note that Operation "Event" was changed to "Report" And the text I quoted above in the Config-Resp section 6.3.2 should be=20 changed accordingly to : Type (16 bits): The operations include, ADD-Resp, DEL-Resp, UPDATE/REPLACE-Resp, = DEL ALL-Resp, EVENT SUBSCRIBE-Resp, EVENT UNSUBSCRIBE-Resp, PACKET SUBSCRIBE, = CANCEL-Resp. I would drop in 6.3.1 and 6.3.2 the operation types PACKET *SUBSCRIBE.=20 Note that all the messages above don't appear in the summary table, but=20 maybe we should not overload the table with all of them. - add an Editorial's note after the text below (search for MIID): * MIID table: a list of virtual LFB Instance IDs that map to a list of Instance IDs of LFBs in that FE Editoral's note: it remains to be decided whether such an MIID table=20 should be used. - search and correct typo "GET_RESPOSE" - add a newline between Inter-FE topology and Intra-FE topology (sec = 6.1.2): Note: The attributes below were previously under Query message. * Inter-FE topology Intra-FE topology - you should appear as "Editor", not "co-editor". At least that's my=20 understanding. Also, the ETRI name appears on the first page. I thought=20 you said you didn't want that ? I personally don't care. - I like the name "Core ForCES LFBs" Thanks, -Robert avri@psg.com wrote: > I have submitted the following draft: > > http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-11.txt > > hope it is ok. > > a. > > > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 19:49:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19627 for ; Mon, 25 Oct 2004 19:49:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEok-0004gK-8c for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:04:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMENl-0006iE-5h; Mon, 25 Oct 2004 19:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBdh-0004ea-3R for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 16:40:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06677 for ; Mon, 25 Oct 2004 16:40:21 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBr8-0000AI-Ql for forces-protocol@ietf.org; Mon, 25 Oct 2004 16:54:22 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9PKdRr8013536; Mon, 25 Oct 2004 20:39:27 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9PKXCJU024730; Mon, 25 Oct 2004 20:33:14 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102513394523987 ; Mon, 25 Oct 2004 13:39:45 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 13:39:45 -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 Date: Mon, 25 Oct 2004 13:39:44 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0302DC76@orsmsx408> Thread-Topic: Meaning of PACKET *SUBSCRIBE operation type unclear Thread-Index: AcS6iW8omijdpPo4TRKDWk8zmxIcHwASLpbQ From: "Khosravi, Hormuzd M" To: "Robert Haas" X-OriginalArrivalTime: 25 Oct 2004 20:39:45.0804 (UTC) FILETIME=[C3706CC0:01C4BAD2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, avri@psg.com, Jamal Hadi Salim , Ligang Dong Subject: [Forces-protocol] RE: Meaning of PACKET *SUBSCRIBE operation type unclear X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Robert, I tried to explain this in my response to Jamal, not sure if you saw that ?=20 This has been added to support the Requirements RFC section6 #9... 9) Packet Redirection/Mirroring a) The ForCES protocol MUST define a way to redirect packets from the FE to the CE and vice-versa. Packet redirection terminates any further processing of the redirected packet at the FE. b) The ForCES protocol MUST define a way to mirror packets from the FE to the CE. Mirroring allows the packet duplicated by the FE at the mirroring point to be sent to the CE while the original packet continues to be processed by the FE. Examples of packets that may be redirected or mirrored include control packets (such as RIP, OSPF messages) addressed to the interfaces or any other relevant packets (such as those with Router Alert Option set). The ForCES protocol MUST also define a way for the CE to configure the behavior of a) and b) (above), to specify which packets are affected by each. If there is a cleaner/faster way to do this, pls propose and I am happy to discuss. But lets not make changes to the draft before discussing these issues. Regards Hormuzd P.s. I first had this as part of Event Type, but based on your comments I made this change, I thought this was cleaner... -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Hormuzd, Could you please explain again the use of PACKET *SUBSCRIBE in the=20 Config msg ? Can we use another existing operation type and/or LFB for this ? Thanks, _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 19:51:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19766 for ; Mon, 25 Oct 2004 19:51:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEqR-0004io-2i for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:05:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEO0-00078l-V1; Mon, 25 Oct 2004 19:36:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBiB-0004q5-Vo for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 16:45:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07328 for ; Mon, 25 Oct 2004 16:44:58 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMBvd-0000KO-W2 for forces-protocol@ietf.org; Mon, 25 Oct 2004 16:58:59 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9PKj5Qm031209; Mon, 25 Oct 2004 20:45:06 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9PKl4sg003125; Mon, 25 Oct 2004 20:48:03 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102513441531422 ; Mon, 25 Oct 2004 13:44:15 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 13:44:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Forces-protocol] Re: protocol draft editing? Date: Mon, 25 Oct 2004 13:44:14 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0302DC90@orsmsx408> Thread-Topic: [Forces-protocol] Re: protocol draft editing? Thread-Index: AcS4BmEe3omyni8gRZudyCVyscrG7QCzL/yQ From: "Khosravi, Hormuzd M" To: "Ligang Dong" , "Weiming Wang" , "Robert Haas" , X-OriginalArrivalTime: 25 Oct 2004 20:44:15.0419 (UTC) FILETIME=[642468B0:01C4BAD3] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.3 (/) X-Scan-Signature: c343632e7d969f32683dd165d9d1aa55 Cc: "\(\(Ram Gopal \)\)" , Jamal Hadi Salim , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0295846301==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: eb4c5242518af073df6fe45f0d1cde3e This is a multi-part message in MIME format. --===============0295846301== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BAD3.6377A4BC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BAD3.6377A4BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ligang, =20 Are you working on this ? I haven't seen any text from you yet. I will start working on this if I don't see anything by tomorrow morning my time (PST). =20 regards Hormuzd ________________________________ From: Ligang Dong [mailto:donglg@mail.hzic.edu.cn]=20 Sent: Friday, October 22, 2004 12:10 AM To: Khosravi, Hormuzd M Subject: Re: [Forces-protocol] Re: protocol draft editing? hi, Hormuzd,=20 According to your understanding, what section will "state machine for protocol" be inserted in. best regards Ligang ----- Original Message -----=20 From: Khosravi, Hormuzd M To: Ligang Dong ; Robert Haas =20 Cc: ram.gopal@nokia.com ; forces-protocol@ietf.org ; avri@psg.com ; hadi@znyx.com ; Weiming Wang =20 Sent: Friday, October 22, 2004 10:30 AM Subject: RE: [Forces-protocol] Re: protocol draft editing? Go ahead, pls try to send us something by tonight or tomorrow morning. =20 Thanks for volunteering, =20 Hormuzd =20 =09 ________________________________ From: Ligang Dong [mailto:donglg@mail.hzic.edu.cn]=20 Sent: Thursday, October 21, 2004 7:17 PM To: Khosravi, Hormuzd M; Robert Haas Cc: ram.gopal@nokia.com; forces-protocol@ietf.org; avri@psg.com; hadi@znyx.com; Weiming Wang Subject: Re: [Forces-protocol] Re: protocol draft editing? =20 hi,=20 I can edit the "state machine for protocol". ligang ----- Original Message -----=20 From: Khosravi, Hormuzd M =20 To: Robert Haas =20 Cc: ram.gopal@nokia.com ; Ligang Dong ; forces-protocol@ietf.org ; avri@psg.com ; hadi@znyx.com ; Weiming Wang =20 Sent: Friday, October 22, 2004 5:43 AM Subject: RE: [Forces-protocol] Re: protocol draft editing? =20 Dear Robert (co-author :)), All =20 Here is a list of major todos... =20 Header Section - Jamal/Robert/Weiming? Protocol LFB - Robert/Others? FE LFB - Robert/Others? State Machine for Protocol - ?? Messages Section - working (Hormuzd, Weiming) HA Section - done (Hormuzd) Protocol Scenarios - Ram/H =20 Minor todos... Security section - any updates needed Ram ? Updates to Overview (Furquan had sent comments regarding inconsistencies) -done Jamal ? =20 =20 I think if we get all this done before the deadline, it will be a big accomplishment! =20 regards Hormuzd p.s. Robert, I will respond to your previous note in my next email, it mostly looked fine I think... =20 =09 ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Robert, =20 Weiming and myself are already working on this section...I will send out what I have shortly. Some of the changes are pretty straightforward, e.g. remove section 6.6 :-) =20 Anyways we could definitely use help in the draft, there is lots of stuff that needs to be done You bet. I suppose I can help as a co-author of this draft ;-) =09 =09 I will send out a list of other todo items shortly.. =20 I'll start from your input tomorrow morning Europe time. Please take a look at my previous note and review the pending issues I listed. This way we avoid changing the text back and forth. =09 Thanks, -Robert =09 =09 =20 =09 ________________________________ _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol ------_=_NextPart_001_01C4BAD3.6377A4BC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ligang,
 
Are you working on this ? I haven't seen any = text from=20 you yet.
I will start working on this if I don't see = anything by=20 tomorrow morning my time (PST).
 
regards
Hormuzd

From: Ligang Dong=20 [mailto:donglg@mail.hzic.edu.cn]
Sent: Friday, October 22, = 2004 12:10=20 AM
To: Khosravi, Hormuzd M
Subject: Re: = [Forces-protocol]=20 Re: protocol draft editing?

hi, Hormuzd,
According to your understanding, what section = will "state=20 machine for protocol" be inserted in.
best regards
Ligang
----- Original Message ----- =
To: Ligang Dong ; Robert = Haas=20
Cc: ram.gopal@nokia.com ; forces-protocol@ietf.org = ; avri@psg.com ; = hadi@znyx.com = ; Weiming=20 Wang
Sent: Friday, October = 22, 2004 10:30 AM
Subject: RE: = [Forces-protocol] Re: protocol=20 draft editing?

Go ahead, = pls try to=20 send us something by tonight or tomorrow morning.

 

Thanks for=20 volunteering,

 

Hormuzd

 

From: = Ligang Dong=20 [mailto:donglg@mail.hzic.edu.cn]
Sent: Thursday, October 21, = 2004 7:17=20 PM
To: Khosravi, = Hormuzd M;=20 Robert Haas
Cc: ram.gopal@nokia.com; forces-protocol@ietf.org; = avri@psg.com; hadi@znyx.com; Weiming = Wang
Subject: Re: [Forces-protocol] = Re:=20 protocol draft editing?

 

hi,

I can edit the "state machine for=20 protocol".

ligang

----- Original Message = -----=20

From: Khosravi, Hormuzd M =

To: Robert = Haas=20

Cc: ram.gopal@nokia.com ; Ligang=20 Dong ; forces-protocol@ietf.org ; = avri@psg.com ; = hadi@znyx.com ; Weiming=20 Wang

Sent:=20 Friday, October 22, 2004 5:43 AM

Subject: RE:=20 [Forces-protocol] Re: protocol draft = editing?

 

Dear = Robert=20 (co-author :)), All

 

Here is a = list of=20 major todos...

 

Header = Section -=20 Jamal/Robert/Weiming?

Protocol = LFB -=20 Robert/Others?

FE LFB -=20 Robert/Others?

State Machine for Protocol - ??

Messages = Section=20 - working (Hormuzd, Weiming)
HA = Section - done=20 (Hormuzd)

Protocol = Scenarios=20 - Ram/H

 

Minor=20 todos...

Security = section -=20 any updates needed Ram ?

Updates = to Overview=20 (Furquan had sent comments regarding inconsistencies) -done Jamal=20 ?

 

 

I think = if we get=20 all this done before the deadline, it will be a big=20 accomplishment!

 

regards

Hormuzd

p.s. = Robert, I will=20 respond to your previous note in my next email, it mostly looked = fine I=20 think...

 

From:=20 Robert Haas [mailto:rha@zurich.ibm.com]

Robert,

 

Weiming = and=20 myself are already working on this section…I will send out = what I have=20 shortly.

Some of = the=20 changes are pretty straightforward, e.g. remove section 6.6=20 J

 

Anyways = we could=20 definitely use help in the draft, there is lots of stuff that = needs to be=20 done

You bet. I suppose I can help as a = co-author of this=20 draft ;-)

I will = send out a=20 list of other todo items shortly..

 

I'll start from your input tomorrow = morning Europe=20 time. Please take a look at my previous note and review the pending = issues I=20 listed. This way we avoid changing the text back and=20 forth.

Thanks,
-Robert

 

_______________________________________________
Forces-protocol = mailing=20 = list
Forces-protocol@ietf.org
https://www1.ietf.org/mailman/listinf= o/forces-protocol

------_=_NextPart_001_01C4BAD3.6377A4BC-- --===============0295846301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0295846301==-- From forces-protocol-bounces@ietf.org Mon Oct 25 19:53:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19867 for ; Mon, 25 Oct 2004 19:53:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMErn-0004kK-Q0 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:07:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEO1-0007AR-T4; Mon, 25 Oct 2004 19:36:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBo8-0007Sd-MZ for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 16:51:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08105 for ; Mon, 25 Oct 2004 16:51:08 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMC1c-0000ZX-SS for forces-protocol@ietf.org; Mon, 25 Oct 2004 17:05:09 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9PKoHr8019346; Mon, 25 Oct 2004 20:50:17 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9PKsIsE008910; Mon, 25 Oct 2004 20:54:19 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102513502732464 ; Mon, 25 Oct 2004 13:50:28 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 13:50:21 -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 Date: Mon, 25 Oct 2004 13:50:20 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0302DCB8@orsmsx408> Thread-Topic: Conference Call this Week ? Thread-Index: AcS6ZRUR240nrv45Rl2DphwkdcQeAwAbGw8QAAB/YxA= From: "Khosravi, Hormuzd M" To: , "Ligang Dong" , , "Wang,Weiming" , "Robert Haas" , "Jamal Hadi Salim" , X-OriginalArrivalTime: 25 Oct 2004 20:50:21.0620 (UTC) FILETIME=[3E6A3F40:01C4BAD4] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: "Putzolu, David" Subject: [Forces-protocol] Conference Call this Week ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Hi Team, I would propose we have a conference call this week to close on some of the outstanding issues. I think this is a good time since most of the issues are fresh in our minds and not all of us will be able to make it to the IETF meeting. For one, I will be unable to attend, so will Ram and Weiming I believe. Once we resolve these issues, we can submit another draft update by early next week. Let me know what day/time works for you. I would suggest Wed, Thu, or Friday early morning call my time i.e. 8 AM PST, but I will be happy to accommodate your times so that we can get everyone.=20 Pls let us know soon ? Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 19:53:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19969 for ; Mon, 25 Oct 2004 19:53:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEsK-0004l6-Jr for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:07:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEO7-0007GQ-0u; Mon, 25 Oct 2004 19:36:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMBxR-0003uC-6q for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 17:00:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08946 for ; Mon, 25 Oct 2004 17:00:34 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMCAk-0000ry-NO for forces-protocol@ietf.org; Mon, 25 Oct 2004 17:14:36 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9PKZnep002541; Mon, 25 Oct 2004 22:35:49 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0302DCB8@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0302DCB8@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Date: Mon, 25 Oct 2004 17:00:30 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , "Putzolu, David" , "Wang, Weiming" , Robert Haas Subject: [Forces-protocol] Re: Conference Call this Week ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit On 25 okt 2004, at 16.50, Khosravi, Hormuzd M wrote: > Hi Team, > > I would propose we have a conference call this week to close on some of > the outstanding issues. I agree a conference call is a good idea. unfortunately i cannot make it this week, except for Tuesday and Wednesday morning, as I will be traveling on Wednesday afternoon and Friday all day and presenting etc on Thursday. > I think this is a good time since most of the issues are fresh in our > minds and not all of us will be able to make it to the IETF meeting. > For > one, I will be unable to attend, so will Ram and Weiming I believe. sad so few can attend > Once > we resolve these issues, we can submit another draft update by early > next week. While we can put one up on a web site, we can't actually submit another draft until after the IETF meeting. > > Let me know what day/time works for you. I would suggest Wed, Thu, or > Friday early morning call my time i.e. 8 AM PST, but I will be happy to > accommodate your times so that we can get everyone. i can make Wednesday am, the earlier the better. i have to leave for the airport around noon eastern time. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 19:53:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20018 for ; Mon, 25 Oct 2004 19:53:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEsV-0004lT-TY for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:07:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEO8-0007J0-KV; Mon, 25 Oct 2004 19:36:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMC1h-0008Le-DF for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 17:05:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09340 for ; Mon, 25 Oct 2004 17:04:40 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMCEi-0000x2-2n for forces-protocol@ietf.org; Mon, 25 Oct 2004 17:18:41 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9PL86rk024548; Mon, 25 Oct 2004 21:08:06 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9PL7msE019535; Mon, 25 Oct 2004 21:07:50 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102514040602358 ; Mon, 25 Oct 2004 14:04: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.0); Mon, 25 Oct 2004 14:04:04 -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 Date: Mon, 25 Oct 2004 14:04:03 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0302DD1B@orsmsx408> Thread-Topic: Conference Call this Week ? Thread-Index: AcS61bGTPeiaN58HTaSRCS25MLd7QwAAENJw From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 25 Oct 2004 21:04:04.0920 (UTC) FILETIME=[2923DB80:01C4BAD6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , "Putzolu, David" , "Wang, Weiming" , Robert Haas Subject: [Forces-protocol] RE: Conference Call this Week ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable I am fine with starting at 7 AM PST on Wednesday, if that works for everyone...what say, Jamal, Weiming, Robert, Ram ?? =20 Thanks Hormuzd -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 > > Let me know what day/time works for you. I would suggest Wed, Thu, or > Friday early morning call my time i.e. 8 AM PST, but I will be happy to > accommodate your times so that we can get everyone. i can make Wednesday am, the earlier the better. i have to leave for=20 the airport around noon eastern time. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 19:54:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20045 for ; Mon, 25 Oct 2004 19:54:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEsc-0004lh-R9 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:08:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEO9-0007K8-7E; Mon, 25 Oct 2004 19:36:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMC4V-0000ni-2S for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 17:08:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09609 for ; Mon, 25 Oct 2004 17:08:04 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMCHw-00010h-Up for forces-protocol@ietf.org; Mon, 25 Oct 2004 17:22:04 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9PL7K1p626108 for ; Mon, 25 Oct 2004 17:07:20 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9PL7JjU159704 for ; Mon, 25 Oct 2004 15:07:19 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9PL7Jb7020779 for ; Mon, 25 Oct 2004 15:07:19 -0600 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9PL7G6O020703; Mon, 25 Oct 2004 15:07:17 -0600 Received: from [9.145.254.227] (sig-9-145-254-227.de.ibm.com [9.145.254.227]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA14516; Mon, 25 Oct 2004 23:07:12 +0200 Message-ID: <417D6AF3.1010502@zurich.ibm.com> Date: Mon, 25 Oct 2004 23:06:59 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E0302DCB8@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0302DCB8@orsmsx408> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id i9PL7K1p626108 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Jamal Hadi Salim , "Putzolu, David" , "Wang, Weiming" Subject: [Forces-protocol] Re: Conference Call this Week ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Yes, good idea. I am available Wednesday between 9am and 12am PST or=20 Thursday between 1pm and 2pm PST. -Robert Khosravi, Hormuzd M wrote: >Hi Team, > >I would propose we have a conference call this week to close on some of >the outstanding issues. >I think this is a good time since most of the issues are fresh in our >minds and not all of us will be able to make it to the IETF meeting. For >one, I will be unable to attend, so will Ram and Weiming I believe. Once >we resolve these issues, we can submit another draft update by early >next week. > >Let me know what day/time works for you. I would suggest Wed, Thu, or >Friday early morning call my time i.e. 8 AM PST, but I will be happy to >accommodate your times so that we can get everyone.=20 > >Pls let us know soon ? > > >Regards >Hormuzd > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 19:54:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20087 for ; Mon, 25 Oct 2004 19:54:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEsn-0004mB-Uq for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:08:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEOC-0007Qd-Mw; Mon, 25 Oct 2004 19:36:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMC8e-0001XI-OR for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 17:12:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10781 for ; Mon, 25 Oct 2004 17:12:21 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMCM9-0001D4-7k for forces-protocol@ietf.org; Mon, 25 Oct 2004 17:26:23 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9PLBnEx719386 for ; Mon, 25 Oct 2004 17:11:49 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9PLBmjU151466 for ; Mon, 25 Oct 2004 15:11:48 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9PLBm8o020815 for ; Mon, 25 Oct 2004 15:11:48 -0600 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9PLBksb020690; Mon, 25 Oct 2004 15:11:46 -0600 Received: from [9.145.254.227] (sig-9-145-254-227.de.ibm.com [9.145.254.227]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA28872; Mon, 25 Oct 2004 23:11:39 +0200 Message-ID: <417D6BFF.4080409@zurich.ibm.com> Date: Mon, 25 Oct 2004 23:11:27 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E0302DC76@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0302DC76@orsmsx408> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id i9PLBnEx719386 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, avri@psg.com, Jamal Hadi Salim , Ligang Dong Subject: [Forces-protocol] Re: Meaning of PACKET *SUBSCRIBE operation type unclear X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Hormuzd, Khosravi, Hormuzd M wrote: >Robert, > >I tried to explain this in my response to Jamal, not sure if you saw >that ?=20 > >This has been added to support the Requirements RFC section6 #9... > > 9) Packet Redirection/Mirroring > a) The ForCES protocol MUST define a way to redirect packets from > the FE to the CE and vice-versa. Packet redirection terminates > any further processing of the redirected packet at the FE. > b) The ForCES protocol MUST define a way to mirror packets from > the FE to the CE. Mirroring allows the packet duplicated by > the FE at the mirroring point to be sent to the CE while the > original packet continues to be processed by the FE. > > Examples of packets that may be redirected or mirrored include > control packets (such as RIP, OSPF messages) addressed to the > interfaces or any other relevant packets (such as those with Router > Alert Option set). The ForCES protocol MUST also define a way for > the CE to configure the behavior of a) and b) (above), to specify > which packets are affected by each. > > >If there is a cleaner/faster way to do this, pls propose and I am happy >to discuss. >But lets not make changes to the draft before discussing these issues. > >Regards >Hormuzd > >P.s. I first had this as part of Event Type, but based on your comments >I made this change, I thought this was cleaner... > =20 > My current thinking is that any LFB that generates PKT_REDIR messages=20 will provide attributes that can be configured to decide which packets=20 must be redirected or mirrored. A CONFIG msg to the appropriate=20 attribute(s) should suffice, no ? Regards, -Robert >-----Original Message----- >From: Robert Haas [mailto:rha@zurich.ibm.com]=20 > >Hormuzd, >Could you please explain again the use of PACKET *SUBSCRIBE in the=20 >Config msg ? >Can we use another existing operation type and/or LFB for this ? > >Thanks, > > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 19:54:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20130 for ; Mon, 25 Oct 2004 19:54:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEsy-0004mp-TD for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:08:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEOU-00080W-Ib; Mon, 25 Oct 2004 19:36:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMCEd-0003w1-J0 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 17:18:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11691 for ; Mon, 25 Oct 2004 17:18:32 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMCS9-0001Uk-5W for forces-protocol@ietf.org; Mon, 25 Oct 2004 17:32:34 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9PLHer8032731; Mon, 25 Oct 2004 21:17:40 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9PLLdsG029826; Mon, 25 Oct 2004 21:21:42 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102514175904823 ; Mon, 25 Oct 2004 14:17:59 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 14:17:59 -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 Date: Mon, 25 Oct 2004 14:17:58 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0302DD86@orsmsx408> Thread-Topic: Meaning of PACKET *SUBSCRIBE operation type unclear Thread-Index: AcS610FxLdBMIO0wQAeMOG0Y8hE+xgAACZ2Q From: "Khosravi, Hormuzd M" To: "Robert Haas" , "Jamal Hadi Salim" X-OriginalArrivalTime: 25 Oct 2004 21:17:59.0439 (UTC) FILETIME=[1A8D59F0:01C4BAD8] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: avri@psg.com, ram.gopal@nokia.com, Ligang Dong , "Wang, Weiming" , forces-protocol@ietf.org Subject: [Forces-protocol] RE: Meaning of PACKET *SUBSCRIBE operation type unclear X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Robert, I am not so sure about this, what kind of attributes would the LFB have to expose for this ? What do others think about this ? Jamal, you had a similar question...let us know what your experience has been in this regard. In our experience, we had such messages which would specify filters, e.g. Packet Subscribe for filters A, B, C, etc. But I am fine with doing this a different way as well...what is important is that this functionality needs to be supported by the protocol. Thanks Hormuzd=20 -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 My current thinking is that any LFB that generates PKT_REDIR messages=20 will provide attributes that can be configured to decide which packets=20 must be redirected or mirrored. A CONFIG msg to the appropriate=20 attribute(s) should suffice, no ? Regards, -Robert _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 19:54:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20165 for ; Mon, 25 Oct 2004 19:54:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEt5-0004n8-EH for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:08:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEOi-0008QA-3F; Mon, 25 Oct 2004 19:37:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMCII-0007el-FX for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 17:22:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12392 for ; Mon, 25 Oct 2004 17:22:19 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMCVn-0001kL-Kq for forces-protocol@ietf.org; Mon, 25 Oct 2004 17:36:21 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9PLLnEx836982 for ; Mon, 25 Oct 2004 17:21:49 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9PLLmjU142396 for ; Mon, 25 Oct 2004 15:21:48 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9PLLmmH013698 for ; Mon, 25 Oct 2004 15:21:48 -0600 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id i9PLLjNQ013588; Mon, 25 Oct 2004 15:21:46 -0600 Received: from [9.145.254.227] (sig-9-145-254-227.de.ibm.com [9.145.254.227]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA14108; Mon, 25 Oct 2004 23:21:40 +0200 Message-ID: <417D6E58.4030204@zurich.ibm.com> Date: Mon, 25 Oct 2004 23:21:28 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E0302DD1B@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0302DD1B@orsmsx408> X-Spam-Score: 1.0 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Jamal Hadi Salim , "Putzolu, David" , "Wang, Weiming" Subject: [Forces-protocol] Re: Conference Call this Week ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0376807756==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f This is a multi-part message in MIME format. --===============0376807756== Content-Type: multipart/alternative; boundary="------------090206030602000700040106" This is a multi-part message in MIME format. --------------090206030602000700040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id i9PLLnEx836982 Content-Transfer-Encoding: quoted-printable I can change some of my plans and be available starting at 7 AM PST on=20 Wednesday too (equals 4pm Zurich time) -Robert Khosravi, Hormuzd M wrote: >I am fine with starting at 7 AM PST on Wednesday, if that works for >everyone...what say, Jamal, Weiming, Robert, Ram ?? >=20 >Thanks >Hormuzd > >-----Original Message----- >From: avri@psg.com [mailto:avri@psg.com]=20 > > =20 > >>Let me know what day/time works for you. I would suggest Wed, Thu, or >>Friday early morning call my time i.e. 8 AM PST, but I will be happy >> =20 >> >to > =20 > >>accommodate your times so that we can get everyone. >> =20 >> > >i can make Wednesday am, the earlier the better. i have to leave for=20 >the airport around noon eastern time. > >a. > > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha --------------090206030602000700040106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I can change some of my plans and be available starting at 7 AM PST on Wednesday too (equals 4pm Zurich time)
-Robert

Khosravi, Hormuzd M wrote:
I am fine with starting at 7 AM PST on Wednesday, if that works for
everyone...what say, Jamal, Weiming, Robert, Ram ??
 
Thanks
Hormuzd

-----Original Message-----
From: avri@psg.com [mailto:avri@psg.com] 

  
Let me know what day/time works for you. I would suggest Wed, Thu, or
Friday early morning call my time i.e. 8 AM PST, but I will be happy
    
to
  
accommodate your times so that we can get everyone.
    

i can make Wednesday am, the earlier the better.  i have to leave for 
the airport around noon eastern time.

a.



  

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
--------------090206030602000700040106-- --===============0376807756== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0376807756==-- From forces-protocol-bounces@ietf.org Mon Oct 25 19:54:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20235 for ; Mon, 25 Oct 2004 19:54:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMEtW-0004oD-Rv for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:08:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMEPD-0000uA-RC; Mon, 25 Oct 2004 19:37:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMCO4-0005LT-6e for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 17:28:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13889 for ; Mon, 25 Oct 2004 17:28:17 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMCbZ-0002EE-Vr for forces-protocol@ietf.org; Mon, 25 Oct 2004 17:42:18 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9PLRPr8005290; Mon, 25 Oct 2004 21:27:25 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9PLV8sW004252; Mon, 25 Oct 2004 21:31:28 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102514274506577 ; Mon, 25 Oct 2004 14:27:45 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 14:27:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Oct 2004 14:27:44 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0302DDD0@orsmsx408> Thread-Topic: Conference Call this Week ? Thread-Index: AcS62KsONfJ9/WgbTw2u+riHOA89+QAALPHQ From: "Khosravi, Hormuzd M" To: "Robert Haas" X-OriginalArrivalTime: 25 Oct 2004 21:27:45.0624 (UTC) FILETIME=[77F21580:01C4BAD9] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 1.5 (+) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Jamal Hadi Salim , "Putzolu, David" , "Wang, Weiming" Subject: [Forces-protocol] RE: Conference Call this Week ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2139969968==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 This is a multi-part message in MIME format. --===============2139969968== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BAD9.777EEA8C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BAD9.777EEA8C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the sacrifice Robert! I hope All will be fine with this time. =20 regards Hormuzd ________________________________ From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Monday, October 25, 2004 2:21 PM To: Khosravi, Hormuzd M Cc: avri@psg.com; Ligang Dong; forces-protocol@ietf.org; Wang,Weiming; = Putzolu, David; Jamal Hadi Salim; ram.gopal@nokia.com Subject: Re: Conference Call this Week ? I can change some of my plans and be available starting at 7 AM PST on = Wednesday too (equals 4pm Zurich time) -Robert Khosravi, Hormuzd M wrote: I am fine with starting at 7 AM PST on Wednesday, if that works for everyone...what say, Jamal, Weiming, Robert, Ram ?? =20 Thanks Hormuzd =09 -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 =09 =20 Let me know what day/time works for you. I would suggest Wed, Thu, or Friday early morning call my time i.e. 8 AM PST, but I will be happy =20 to =20 accommodate your times so that we can get everyone. =20 =09 i can make Wednesday am, the earlier the better. i have to leave for=20 the airport around noon eastern time. =09 a. =09 =09 =09 =20 --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha ------_=_NextPart_001_01C4BAD9.777EEA8C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks for the sacrifice Robert! I hope All = will be fine=20 with this time.
 
regards
Hormuzd

From: Robert Haas = [mailto:rha@zurich.ibm.com]=20
Sent: Monday, October 25, 2004 2:21 PM
To: = Khosravi,=20 Hormuzd M
Cc: avri@psg.com; Ligang Dong; = forces-protocol@ietf.org;=20 Wang,Weiming; Putzolu, David; Jamal Hadi Salim;=20 ram.gopal@nokia.com
Subject: Re: Conference Call this Week=20 ?

I can change some of my plans and be available starting at 7 = AM PST=20 on Wednesday too (equals 4pm Zurich time)
-Robert

Khosravi, = Hormuzd M=20 wrote:
I am fine with starting at 7 AM PST on =
Wednesday, if that works for
everyone...what say, Jamal, Weiming, Robert, Ram ??
=20
Thanks
Hormuzd

-----Original Message-----
From: avri@psg.com [mailto:avri@psg.com]=20

  
Let me know what day/time =
works for you. I would suggest Wed, Thu, or
Friday early morning call my time i.e. 8 AM PST, but I will be happy
    
to
  
accommodate your times so =
that we can get everyone.
    

i can make Wednesday am, the earlier the better.  i have to leave for=20
the airport around noon eastern time.

a.



  

--=20
Robert Haas
IBM Zurich Research Laboratory
S=E4umerstrasse 4
CH-8803 R=FCschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha
------_=_NextPart_001_01C4BAD9.777EEA8C-- --===============2139969968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============2139969968==-- From forces-protocol-bounces@ietf.org Mon Oct 25 20:22:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23821 for ; Mon, 25 Oct 2004 20:22:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMFKc-0005af-W1 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 20:36:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMF1X-0004km-Jx; Mon, 25 Oct 2004 20:17:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMExX-0002m8-ST for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 20:13:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23004 for ; Mon, 25 Oct 2004 20:13:06 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMFB5-0005OR-U0 for forces-protocol@ietf.org; Mon, 25 Oct 2004 20:27:08 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9PNmJep002920; Tue, 26 Oct 2004 01:48:20 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0302DC3C@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0302DC3C@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] RE: 01-8 Date: Mon, 25 Oct 2004 20:13:02 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , "Wang, Weiming" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit On 25 okt 2004, at 16.33, Khosravi, Hormuzd M wrote: > This is fine for now but I would prefer the Authors Addresses being a > separate section rather than part of the Appendix cause that is how I > have seen it in most RFCs including All the ForCES RFCs. the problem with what is currently possible is that it came before the references when the regular authors section came after. i would probably have to hack at xml2rfc to make it work. but i still think it is against the rules proper - even if you got away with it on the requirements. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 21:26:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28265 for ; Mon, 25 Oct 2004 21:26:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMGKS-0006cS-OK for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 21:40:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMG5s-0006jc-Dt; Mon, 25 Oct 2004 21:25:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMFy9-0004P8-4n for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 21:17:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27744 for ; Mon, 25 Oct 2004 21:17:46 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMGBh-0006T4-Mc for forces-protocol@ietf.org; Mon, 25 Oct 2004 21:31:50 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102518201246:41644 ; Mon, 25 Oct 2004 18:20:12 -0700 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0302DD86@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0302DD86@orsmsx408> Organization: ZNYX Networks Message-Id: <1098753460.1041.29.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Oct 2004 21:17:40 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/25/2004 06:20:12 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/25/2004 06:20:18 PM, Serialize complete at 10/25/2004 06:20:18 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, avri@psg.com, Ligang Dong , Robert Haas Subject: [Forces-protocol] RE: Meaning of PACKET *SUBSCRIBE operation type unclear X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Seems to me this would probably be difficult to do per LFB. Yes, the LFB will request for certain packets to be sent to it. However _who_ does it send this request to is the question. Lets put it on the agenda for wednesday meeting (Which i plan to attend) cheers, jamal On Mon, 2004-10-25 at 17:17, Khosravi, Hormuzd M wrote: > Robert, > > I am not so sure about this, what kind of attributes would the LFB have > to expose for this ? > What do others think about this ? Jamal, you had a similar > question...let us know what your experience has been in this regard. > > In our experience, we had such messages which would specify filters, > e.g. Packet Subscribe for filters A, B, C, etc. But I am fine with doing > this a different way as well...what is important is that this > functionality needs to be supported by the protocol. > > Thanks > Hormuzd > > -----Original Message----- > From: Robert Haas [mailto:rha@zurich.ibm.com] > > My current thinking is that any LFB that generates PKT_REDIR messages > will provide attributes that can be configured to decide which packets > must be redirected or mirrored. A CONFIG msg to the appropriate > attribute(s) should suffice, no ? > > Regards, > -Robert _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 21:27:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28324 for ; Mon, 25 Oct 2004 21:27:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMGKw-0006dA-Hk for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 21:41:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMG68-0006wt-MI; Mon, 25 Oct 2004 21:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMFzT-0005c8-D9 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 21:19:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27800 for ; Mon, 25 Oct 2004 21:19:09 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMGD2-0006UT-3r for forces-protocol@ietf.org; Mon, 25 Oct 2004 21:33:12 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102518213867:41646 ; Mon, 25 Oct 2004 18:21:38 -0700 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0302DCB8@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0302DCB8@orsmsx408> Organization: ZNYX Networks Message-Id: <1098753546.1045.31.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Oct 2004 21:19:07 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/25/2004 06:21:39 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/25/2004 06:21:40 PM, Serialize complete at 10/25/2004 06:21:40 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, "Putzolu, David" , "Wang, Weiming" , Robert Haas Subject: [Forces-protocol] Re: Conference Call this Week ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Hormuzd, I will be there. An agenda would be nice to have. Lets start with section 6 ;-> Weiming I hope you can make this! cheers, jamal On Mon, 2004-10-25 at 16:50, Khosravi, Hormuzd M wrote: > Hi Team, > > I would propose we have a conference call this week to close on some of > the outstanding issues. > I think this is a good time since most of the issues are fresh in our > minds and not all of us will be able to make it to the IETF meeting. For > one, I will be unable to attend, so will Ram and Weiming I believe. Once > we resolve these issues, we can submit another draft update by early > next week. > > Let me know what day/time works for you. I would suggest Wed, Thu, or > Friday early morning call my time i.e. 8 AM PST, but I will be happy to > accommodate your times so that we can get everyone. > > Pls let us know soon ? > > > Regards > Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 21:31:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28631 for ; Mon, 25 Oct 2004 21:31:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMGPC-0006iC-R4 for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 21:45:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMGAh-0000Yi-Fw; Mon, 25 Oct 2004 21:30:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMGA1-0000L0-2H for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 21:30:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28537 for ; Mon, 25 Oct 2004 21:30:02 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMGNF-0006es-Ro for forces-protocol@ietf.org; Mon, 25 Oct 2004 21:44:06 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Tue, 26 Oct 2004 09:49:07 +0800 (CST) Received: from dlg (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with SMTP id ; Tue, 26 Oct 2004 09:24:38 +0800 Message-ID: <002001c4bafa$df86cbc0$8401a8c0@dlg> From: "Ligang Dong" To: "Robert Haas" , References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> <1098383190.2883.386.camel@localhost.localdomain> <00dd01c4b803$806bd620$8401a8c0@dlg> <1098442868.1112.38.camel@jzny.localdomain> <00c601c4ba72$241599d0$8401a8c0@dlg> <1098722995.1034.67.camel@jzny.localdomain> <417D61D4.6000909@zurich.ibm.com> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? Date: Tue, 26 Oct 2004 09:26:52 +0800 MIME-Version: 1.0 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 X-Spam-Score: 2.5 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Joel M. Halpern" , Zsolt Haraszti , forces-protocol@ietf.org, "Steven Blake \(petri-meat\)" , "Wang, Weiming" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0383545370==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 2.5 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca --===============0383545370== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 aGksIA0KSmFtYWwsIHRoYW5rIHlvdSBmb3IgdGhlIHN1bW1hcml6YXRpb24gYWJvdXQgdGhpcyBp c3N1ZS4NClJvYmVydCwgdGhhbmsgeW91IGZvciB0aGUgcHJlc2VudGF0aW9uIGFib3V0IHRoaXMg aXNzdWUuIA0KV2UgaGF2ZSB0aGUgc2FtZSBvYmplY3RpdmUgb2YgbWFraW5nIHRoZSBwcm90b2Nv bCBzaW1wbGUgYW5kIGVmZmljaWVudC4NCmJlc3QgcmVnYXJkcw0KTGlnYW5nDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlJvYmVydCBIYWFzIiA8cmhhQHp1cmljaC5pYm0u Y29tPg0KVG86IDxoYWRpQHpueXguY29tPg0KQ2M6ICJMaWdhbmcgRG9uZyIgPGRvbmdsZ0BtYWls Lmh6aWMuZWR1LmNuPjsgIktob3NyYXZpLCBIb3JtdXpkIE0iIDxob3JtdXpkLm0ua2hvc3JhdmlA aW50ZWwuY29tPjsgPHJhbS5nb3BhbEBub2tpYS5jb20+OyAiU3RldmVuIEJsYWtlIChwZXRyaS1t ZWF0KSIgPHNsYmxha2VAcGV0cmktbWVhdC5jb20+OyAiWnNvbHQgSGFyYXN6dGkiIDx6c29sdEBt b2R1bGFybmV0LmNvbT47ICJKb2VsIE0uIEhhbHBlcm4iIDxqaGFscGVybkBtZWdpc3RvLmNvbT47 IDxmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc+OyAiV2FuZywgV2VpbWluZyIgPHdtd2FuZ0BtYWls Lmh6aWMuZWR1LmNuPg0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyNiwgMjAwNCA0OjI4IEFNDQpT dWJqZWN0OiBSZTogW0ZvcmNlcy1wcm90b2NvbF0gUkU6IEdFVC9TRVQgaW4gb25lIG1zZyA/DQoN Cg0KPiBKYW1hbCwNCj4gDQo+IEphbWFsIEhhZGkgU2FsaW0gd3JvdGU6DQo+IA0KPiA+SSByZWFs aXplZCBhZnRlciBpIHJlc3BvbmRlZCB0byB5b3UgdGhhdCB0aGUgYXBwcm9hY2ggeW91IHBvc3Rl ZCBpcw0KPiA+c2xpZ2h0bHkgZGlmZmVyZW50LCBidXQgZW5kIGdvYWxzIHRoZSBzYW1lLiBTbyBm YXIgaSB0aGluayB0aGVyZSBhcmUNCj4gPnRocmVlIGFwcHJvYWNoZXMgYmVpbmcgdGFsa2VkIGFi b3V0Lg0KPiA+MSkgWW91cnMNCj4gPjIpIFN0ZXZlL1JvYmVydCB3aXRoIE1JSUQgKHdoY2loIHVu Zm9ydHVuYXRlbHkgbWFkZSBpdCBpbnRvIHRoZSBkcmFmdA0KPiA+YmVmb3JlIGNvbnNlbnN1cyB3 YXMgcmVhY2hlZCkNCj4gPiAgDQo+ID4NCj4gU29ycnksIHRoYXQgd2FzIG5vdCBteSBpbnRlbnQu IE15IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgdGhlcmUgd2FzIG5vIA0KPiBvdGhlciBwcm9wb3Nh bCBhZGRyZXNzaW5nIHRoaXMgaXNzdWUgaW4gcGFydGljdWxhci4NCj4gDQo+ID4zKSBXaGF0IGkg cG9zdGVkIA0KPiA+ICANCj4gPg0KPiBJIG11c3QgaGF2ZSBtaXNzZWQgdGhhdC4NCj4gDQo+ID5N YXliZSBzb21lb25lIG5lZWRzIHRvIHByZXNlbnQgYXQgdGhlIG1lZXRpbmcuDQo+ID4NCj4gPiAg DQo+ID4NCj4gRGVmaW5pdGVseS4gQSBzaG9ydCBwcmVzZW50YXRpb24gc3VtbWFyaXppbmcgYWxs IHRoZSBvcHRpb25zLiBJIGNvdWxkIA0KPiB0YWtlIGNhcmUgb2YgdGhhdCAocHJvYmFibHkgbmVl ZCAzMCBtaW4gd2l0aCB0aGUgZGlzY3Vzc2lvbikuDQo+IA0KPiAtLSANCj4gUm9iZXJ0IEhhYXMN Cj4gSUJNIFp1cmljaCBSZXNlYXJjaCBMYWJvcmF0b3J5DQo+IFPkdW1lcnN0cmFzc2UgNA0KPiBD SC04ODAzIFL8c2NobGlrb24vU3dpdHplcmxhbmQNCj4gcGhvbmUgKzQxLTEtNzI0LTg2OTggIGZh eCArNDEtMS03MjQtODU3OCAgaHR0cDovL3d3dy56dXJpY2guaWJtLmNvbS9+cmhhDQo+IA== --===============0383545370== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0383545370==-- From forces-protocol-bounces@ietf.org Mon Oct 25 21:41:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29166 for ; Mon, 25 Oct 2004 21:41:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMGYw-0006rg-Ep for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 21:55:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMGKa-0003K9-UT; Mon, 25 Oct 2004 21:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMGGQ-00021n-6i for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 21:36:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28926 for ; Mon, 25 Oct 2004 21:36:39 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMGSv-0006kq-Ry for forces-protocol@ietf.org; Mon, 25 Oct 2004 21:50:43 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Tue, 26 Oct 2004 09:55:35 +0800 (CST) Received: from dlg (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with SMTP id ; Tue, 26 Oct 2004 09:31:06 +0800 Message-ID: <009201c4bafb$c6e2da90$8401a8c0@dlg> From: "Ligang Dong" To: "Khosravi, Hormuzd M" , "Weiming Wang" , "Robert Haas" , References: <468F3FDA28AA87429AD807992E22D07E0302DC90@orsmsx408> Subject: Re: [Forces-protocol] Re: protocol draft editing? Date: Tue, 26 Oct 2004 09:33:20 +0800 MIME-Version: 1.0 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 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 Cc: Jamal Hadi Salim , "\(\(Ram Gopal \)\)" , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0807800335==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 3.6 (+++) X-Scan-Signature: af2aae76ea468dc53420d9ba52ca6045 This is a multi-part message in MIME format. --===============0807800335== Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01C4BB3E.D4EE25C0" This is a multi-part message in MIME format. ------=_NextPart_000_008F_01C4BB3E.D4EE25C0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 aGksIEhvcm11emQsDQpJdCBzZWVtcyB0aGF0IHRoZXJlIGlzIG5vdCBhbnkgZGlzY3Vzc2lvbiBh bmQgY29uc2Vuc3VzIGFib3V0ICJzdGF0ZSBtYWNoaW5lIGZvciBwcm90b2NvbCIuDQpBbnl3YXks IHlvdSBjYW4gd29yayBvbiBpdCBhdCBmaXJzdC4gVGhhbmsgeW91Lg0KYmVzdCByZWdhcmRzDQpM aWdhbmcNCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogS2hvc3Jhdmks IEhvcm11emQgTSANCiAgVG86IExpZ2FuZyBEb25nIDsgV2VpbWluZyBXYW5nIDsgUm9iZXJ0IEhh YXMgOyBhdnJpQHBzZy5jb20gDQogIENjOiAoKFJhbSBHb3BhbCApKSA7IEphbWFsIEhhZGkgU2Fs aW0gOyBmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcgDQogIFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIg MjYsIDIwMDQgNDo0NCBBTQ0KICBTdWJqZWN0OiBSRTogW0ZvcmNlcy1wcm90b2NvbF0gUmU6IHBy b3RvY29sIGRyYWZ0IGVkaXRpbmc/DQoNCg0KICBIaSBMaWdhbmcsDQoNCiAgQXJlIHlvdSB3b3Jr aW5nIG9uIHRoaXMgPyBJIGhhdmVuJ3Qgc2VlbiBhbnkgdGV4dCBmcm9tIHlvdSB5ZXQuDQogIEkg d2lsbCBzdGFydCB3b3JraW5nIG9uIHRoaXMgaWYgSSBkb24ndCBzZWUgYW55dGhpbmcgYnkgdG9t b3Jyb3cgbW9ybmluZyBteSB0aW1lIChQU1QpLg0KDQogIHJlZ2FyZHMNCiAgSG9ybXV6ZA0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogIEZyb206IExpZ2FuZyBEb25nIFttYWlsdG86ZG9u Z2xnQG1haWwuaHppYy5lZHUuY25dIA0KICBTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMDQg MTI6MTAgQU0NCiAgVG86IEtob3NyYXZpLCBIb3JtdXpkIE0NCiAgU3ViamVjdDogUmU6IFtGb3Jj ZXMtcHJvdG9jb2xdIFJlOiBwcm90b2NvbCBkcmFmdCBlZGl0aW5nPw0KDQoNCiAgaGksIEhvcm11 emQsIA0KICBBY2NvcmRpbmcgdG8geW91ciB1bmRlcnN0YW5kaW5nLCB3aGF0IHNlY3Rpb24gd2ls bCAic3RhdGUgbWFjaGluZSBmb3IgcHJvdG9jb2wiIGJlIGluc2VydGVkIGluLg0KICBiZXN0IHJl Z2FyZHMNCiAgTGlnYW5nDQogICAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgICBG cm9tOiBLaG9zcmF2aSwgSG9ybXV6ZCBNIA0KICAgIFRvOiBMaWdhbmcgRG9uZyA7IFJvYmVydCBI YWFzIA0KICAgIENjOiByYW0uZ29wYWxAbm9raWEuY29tIDsgZm9yY2VzLXByb3RvY29sQGlldGYu b3JnIDsgYXZyaUBwc2cuY29tIDsgaGFkaUB6bnl4LmNvbSA7IFdlaW1pbmcgV2FuZyANCiAgICBT ZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMDQgMTA6MzAgQU0NCiAgICBTdWJqZWN0OiBSRTog W0ZvcmNlcy1wcm90b2NvbF0gUmU6IHByb3RvY29sIGRyYWZ0IGVkaXRpbmc/DQoNCg0KICAgIEdv IGFoZWFkLCBwbHMgdHJ5IHRvIHNlbmQgdXMgc29tZXRoaW5nIGJ5IHRvbmlnaHQgb3IgdG9tb3Jy b3cgbW9ybmluZy4NCg0KDQoNCiAgICBUaGFua3MgZm9yIHZvbHVudGVlcmluZywNCg0KDQoNCiAg ICBIb3JtdXpkDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgIEZyb206IExpZ2Fu ZyBEb25nIFttYWlsdG86ZG9uZ2xnQG1haWwuaHppYy5lZHUuY25dIA0KICAgIFNlbnQ6IFRodXJz ZGF5LCBPY3RvYmVyIDIxLCAyMDA0IDc6MTcgUE0NCiAgICBUbzogS2hvc3JhdmksIEhvcm11emQg TTsgUm9iZXJ0IEhhYXMNCiAgICBDYzogcmFtLmdvcGFsQG5va2lhLmNvbTsgZm9yY2VzLXByb3Rv Y29sQGlldGYub3JnOyBhdnJpQHBzZy5jb207IGhhZGlAem55eC5jb207IFdlaW1pbmcgV2FuZw0K ICAgIFN1YmplY3Q6IFJlOiBbRm9yY2VzLXByb3RvY29sXSBSZTogcHJvdG9jb2wgZHJhZnQgZWRp dGluZz8NCg0KDQoNCiAgICBoaSwgDQoNCiAgICBJIGNhbiBlZGl0IHRoZSAic3RhdGUgbWFjaGlu ZSBmb3IgcHJvdG9jb2wiLg0KDQogICAgbGlnYW5nDQoNCiAgICAgIC0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0gDQoNCiAgICAgIEZyb206IEtob3NyYXZpLCBIb3JtdXpkIE0gDQoNCiAgICAg IFRvOiBSb2JlcnQgSGFhcyANCg0KICAgICAgQ2M6IHJhbS5nb3BhbEBub2tpYS5jb20gOyBMaWdh bmcgRG9uZyA7IGZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyA7IGF2cmlAcHNnLmNvbSA7IGhhZGlA em55eC5jb20gOyBXZWltaW5nIFdhbmcgDQoNCiAgICAgIFNlbnQ6IEZyaWRheSwgT2N0b2JlciAy MiwgMjAwNCA1OjQzIEFNDQoNCiAgICAgIFN1YmplY3Q6IFJFOiBbRm9yY2VzLXByb3RvY29sXSBS ZTogcHJvdG9jb2wgZHJhZnQgZWRpdGluZz8NCg0KDQoNCiAgICAgIERlYXIgUm9iZXJ0IChjby1h dXRob3IgOikpLCBBbGwNCg0KDQoNCiAgICAgIEhlcmUgaXMgYSBsaXN0IG9mIG1ham9yIHRvZG9z Li4uDQoNCg0KDQogICAgICBIZWFkZXIgU2VjdGlvbiAtIEphbWFsL1JvYmVydC9XZWltaW5nPw0K DQogICAgICBQcm90b2NvbCBMRkIgLSBSb2JlcnQvT3RoZXJzPw0KDQogICAgICBGRSBMRkIgLSBS b2JlcnQvT3RoZXJzPw0KDQogICAgICBTdGF0ZSBNYWNoaW5lIGZvciBQcm90b2NvbCAtID8/DQoN CiAgICAgIE1lc3NhZ2VzIFNlY3Rpb24gLSB3b3JraW5nIChIb3JtdXpkLCBXZWltaW5nKQ0KICAg ICAgSEEgU2VjdGlvbiAtIGRvbmUgKEhvcm11emQpDQoNCiAgICAgIFByb3RvY29sIFNjZW5hcmlv cyAtIFJhbS9IDQoNCg0KDQogICAgICBNaW5vciB0b2Rvcy4uLg0KDQogICAgICBTZWN1cml0eSBz ZWN0aW9uIC0gYW55IHVwZGF0ZXMgbmVlZGVkIFJhbSA/DQoNCiAgICAgIFVwZGF0ZXMgdG8gT3Zl cnZpZXcgKEZ1cnF1YW4gaGFkIHNlbnQgY29tbWVudHMgcmVnYXJkaW5nIGluY29uc2lzdGVuY2ll cykgLWRvbmUgSmFtYWwgPw0KDQoNCg0KDQoNCiAgICAgIEkgdGhpbmsgaWYgd2UgZ2V0IGFsbCB0 aGlzIGRvbmUgYmVmb3JlIHRoZSBkZWFkbGluZSwgaXQgd2lsbCBiZSBhIGJpZyBhY2NvbXBsaXNo bWVudCENCg0KDQoNCiAgICAgIHJlZ2FyZHMNCg0KICAgICAgSG9ybXV6ZA0KDQogICAgICBwLnMu IFJvYmVydCwgSSB3aWxsIHJlc3BvbmQgdG8geW91ciBwcmV2aW91cyBub3RlIGluIG15IG5leHQg ZW1haWwsIGl0IG1vc3RseSBsb29rZWQgZmluZSBJIHRoaW5rLi4uDQoNCg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCiAgICAgIEZyb206IFJvYmVydCBIYWFzIFttYWlsdG86cmhhQHp1cmljaC5p Ym0uY29tXSANCg0KICAgICAgICBSb2JlcnQsDQoNCg0KDQogICAgICAgIFdlaW1pbmcgYW5kIG15 c2VsZiBhcmUgYWxyZWFkeSB3b3JraW5nIG9uIHRoaXMgc2VjdGlvbi5JIHdpbGwgc2VuZCBvdXQg d2hhdCBJIGhhdmUgc2hvcnRseS4NCg0KICAgICAgICBTb21lIG9mIHRoZSBjaGFuZ2VzIGFyZSBw cmV0dHkgc3RyYWlnaHRmb3J3YXJkLCBlLmcuIHJlbW92ZSBzZWN0aW9uIDYuNiBKDQoNCg0KDQog ICAgICAgIEFueXdheXMgd2UgY291bGQgZGVmaW5pdGVseSB1c2UgaGVscCBpbiB0aGUgZHJhZnQs IHRoZXJlIGlzIGxvdHMgb2Ygc3R1ZmYgdGhhdCBuZWVkcyB0byBiZSBkb25lDQoNCiAgICAgIFlv dSBiZXQuIEkgc3VwcG9zZSBJIGNhbiBoZWxwIGFzIGEgY28tYXV0aG9yIG9mIHRoaXMgZHJhZnQg Oy0pDQoNCg0KDQogICAgICBJIHdpbGwgc2VuZCBvdXQgYSBsaXN0IG9mIG90aGVyIHRvZG8gaXRl bXMgc2hvcnRseS4uDQoNCg0KDQogICAgICBJJ2xsIHN0YXJ0IGZyb20geW91ciBpbnB1dCB0b21v cnJvdyBtb3JuaW5nIEV1cm9wZSB0aW1lLiBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgbXkgcHJldmlv dXMgbm90ZSBhbmQgcmV2aWV3IHRoZSBwZW5kaW5nIGlzc3VlcyBJIGxpc3RlZC4gVGhpcyB3YXkg d2UgYXZvaWQgY2hhbmdpbmcgdGhlIHRleHQgYmFjayBhbmQgZm9ydGguDQoNCiAgICAgIFRoYW5r cywNCiAgICAgIC1Sb2JlcnQNCg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICBG b3JjZXMtcHJvdG9jb2wgbWFpbGluZyBsaXN0DQogICAgICBGb3JjZXMtcHJvdG9jb2xAaWV0Zi5v cmcNCiAgICAgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZvcmNlcy1w cm90b2NvbA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICBGb3JjZXMtcHJvdG9jb2wgbWFp bGluZyBsaXN0DQogIEZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZw0KICBodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9mb3JjZXMtcHJvdG9jb2wNCg== ------=_NextPart_000_008F_01C4BB3E.D4EE25C0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjgwMC4xMTA2IiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglm b250LWZhbWlseTogV2luZ2RpbmdzOw0KfQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IFNp bVN1bjsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBUYWhvbWE7DQp9DQpAZm9udC1m YWNlIHsNCglmb250LWZhbWlseTogQFNpbVN1bjsNCn0NCkBwYWdlIFNlY3Rpb24xIHtzaXplOiA4 LjVpbiAxMS4waW47IG1hcmdpbjogMS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjsgfQ0KUC5Nc29O b3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgQ09MT1I6IGJs YWNrOyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiINCn0NCkxJLk1zb05vcm1hbCB7DQoJ Rk9OVC1TSVpFOiAxMnB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQt RkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIg0KfQ0KRElWLk1zb05vcm1hbCB7DQoJRk9OVC1TSVpF OiAxMnB0OyBNQVJHSU46IDBpbiAwaW4gMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiAi VGltZXMgTmV3IFJvbWFuIg0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFU SU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVY VC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IGJsdWU7IFRF WFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsN CglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClAgew0KCUZPTlQt U0laRTogMTJwdDsgTUFSR0lOLUxFRlQ6IDBpbjsgQ09MT1I6IGJsYWNrOyBNQVJHSU4tUklHSFQ6 IDBpbjsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpQUkUgew0KCUZPTlQtU0la RTogMTBwdDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTog IkNvdXJpZXIgTmV3Ig0KfQ0KU1BBTi5lbWFpbHN0eWxlMTggew0KCUNPTE9SOiBuYXZ5OyBGT05U LUZBTUlMWTogQXJpYWwNCn0NClNQQU4uRW1haWxTdHlsZTIwIHsNCglDT0xPUjogbmF2eTsgRk9O VC1GQU1JTFk6IEFyaWFsDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24xDQp9DQo8 L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFkgbGFuZz1FTi1VUyB2TGluaz1ibHVlIGxpbms9Ymx1ZSBi Z0NvbG9yPXdoaXRlPg0KPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5oaSwgSG9ybXV6ZCw8QlI+ SXQgDQpzZWVtcyB0aGF0IHRoZXJlIGlzIG5vdCBhbnkgZGlzY3Vzc2lvbiBhbmQgY29uc2Vuc3Vz IGFib3V0ICJzdGF0ZSBtYWNoaW5lIGZvciANCnByb3RvY29sIi48QlI+QW55d2F5LCB5b3UgY2Fu IHdvcmsgb24gaXQgYXQgZmlyc3QuIFRoYW5rIHlvdS48QlI+YmVzdCANCnJlZ2FyZHM8QlI+TGln YW5nPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IlBBRERJTkctUklH SFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZU OiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJG T05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8 L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzs7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxl PWhvcm11emQubS5raG9zcmF2aUBpbnRlbC5jb20gDQogIGhyZWY9Im1haWx0bzpob3JtdXpkLm0u a2hvc3JhdmlAaW50ZWwuY29tIj5LaG9zcmF2aSwgSG9ybXV6ZCBNPC9BPiA8L0RJVj4NCiAgPERJ ViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlRvOjwvQj4gPEEgdGl0bGU9 ZG9uZ2xnQG1haWwuaHppYy5lZHUuY24gDQogIGhyZWY9Im1haWx0bzpkb25nbGdAbWFpbC5oemlj LmVkdS5jbiI+TGlnYW5nIERvbmc8L0E+IDsgPEEgDQogIHRpdGxlPXdtd2FuZ0BtYWlsLmh6aWMu ZWR1LmNuIGhyZWY9Im1haWx0bzp3bXdhbmdAbWFpbC5oemljLmVkdS5jbiI+V2VpbWluZyANCiAg V2FuZzwvQT4gOyA8QSB0aXRsZT1yaGFAenVyaWNoLmlibS5jb20gaHJlZj0ibWFpbHRvOnJoYUB6 dXJpY2guaWJtLmNvbSI+Um9iZXJ0IA0KICBIYWFzPC9BPiA7IDxBIHRpdGxlPWF2cmlAcHNnLmNv bSBocmVmPSJtYWlsdG86YXZyaUBwc2cuY29tIj5hdnJpQHBzZy5jb208L0E+IA0KICA8L0RJVj4N CiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEg dGl0bGU9cmFtLmdvcGFsQG5va2lhLmNvbSANCiAgaHJlZj0ibWFpbHRvOnJhbS5nb3BhbEBub2tp YS5jb20iPigoUmFtIEdvcGFsICkpPC9BPiA7IDxBIHRpdGxlPWhhZGlAem55eC5jb20gDQogIGhy ZWY9Im1haWx0bzpoYWRpQHpueXguY29tIj5KYW1hbCBIYWRpIFNhbGltPC9BPiA7IDxBIA0KICB0 aXRsZT1mb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpmb3JjZXMtcHJv dG9jb2xAaWV0Zi5vcmciPmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZzwvQT4gPC9ESVY+DQogIDxE SVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50OjwvQj4gVHVlc2Rh eSwgT2N0b2JlciAyNiwgMjAwNCA0OjQ0IEFNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlw dCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUkU6IFtGb3JjZXMtcHJvdG9jb2xd IFJlOiBwcm90b2NvbCANCiAgZHJhZnQgZWRpdGluZz88L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+ DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBm ZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTg4MzIyNDIyMC0yNTEwMjAwND5IaSBMaWdhbmcsPC9T UEFOPjwvRk9OVD48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9ODgzMjI0MjIwLTI1MTAy MDA0PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0 PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTg4 MzIyNDIyMC0yNTEwMjAwND5BcmUgeW91IHdvcmtpbmcgb24gdGhpcyA/IEkgaGF2ZW4ndCBzZWVu IGFueSB0ZXh0IA0KICBmcm9tIHlvdSB5ZXQuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJViBk aXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48 U1BBTiANCiAgY2xhc3M9ODgzMjI0MjIwLTI1MTAyMDA0Pkkgd2lsbCBzdGFydCB3b3JraW5nIG9u IHRoaXMgaWYgSSBkb24ndCBzZWUgYW55dGhpbmcgDQogIGJ5IHRvbW9ycm93IG1vcm5pbmcgbXkg dGltZSAoUFNUKS48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVm dD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz04 ODMyMjQyMjAtMjUxMDIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9 bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiANCiAgY2xhc3M9ODgzMjI0MjIwLTI1MTAyMDA0PnJlZ2FyZHM8L1NQQU4+PC9GT05UPjwvRElW Pg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz04ODMyMjQyMjAtMjUxMDIwMDQ+SG9ybXV6ZDwvU1BB Tj48L0ZPTlQ+PC9ESVY+PEJSPg0KICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxh bmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KICA8SFIgdGFiSW5kZXg9LTE+DQogIDxGT05U IGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9tOjwvQj4gTGlnYW5nIERvbmcgDQogIFttYWlsdG86 ZG9uZ2xnQG1haWwuaHppYy5lZHUuY25dIDxCUj48Qj5TZW50OjwvQj4gRnJpZGF5LCBPY3RvYmVy IDIyLCAyMDA0IA0KICAxMjoxMCBBTTxCUj48Qj5Ubzo8L0I+IEtob3NyYXZpLCBIb3JtdXpkIE08 QlI+PEI+U3ViamVjdDo8L0I+IFJlOiANCiAgW0ZvcmNlcy1wcm90b2NvbF0gUmU6IHByb3RvY29s IGRyYWZ0IGVkaXRpbmc/PEJSPjwvRk9OVD48QlI+PC9ESVY+DQogIDxESVY+PC9ESVY+DQogIDxE SVY+PEZPTlQgc2l6ZT0yPmhpLCBIb3JtdXpkLCA8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQg c2l6ZT0yPkFjY29yZGluZyB0byB5b3VyIHVuZGVyc3RhbmRpbmcsJm5ic3A7d2hhdCBzZWN0aW9u IHdpbGwgDQogICJzdGF0ZSBtYWNoaW5lIGZvciBwcm90b2NvbCIgYmUgaW5zZXJ0ZWQgaW4uPC9G T05UPjwvRElWPg0KICA8RElWPjxGT05UIHNpemU9Mj5iZXN0IHJlZ2FyZHM8L0ZPTlQ+PC9ESVY+ DQogIDxESVY+PEZPTlQgc2l6ZT0yPkxpZ2FuZzwvRk9OVD48L0RJVj4NCiAgPEJMT0NLUVVPVEUg ZGlyPWx0ciANCiAgc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7 IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lO LVJJR0hUOiAwcHgiPg0KICAgIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7 Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICAgIDxESVYgDQogICAgc3R5 bGU9IkJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IEZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7OyBmb250 LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IDxBIA0KICAgIHRpdGxlPWhvcm11emQubS5raG9z cmF2aUBpbnRlbC5jb20gDQogICAgaHJlZj0ibWFpbHRvOmhvcm11emQubS5raG9zcmF2aUBpbnRl bC5jb20iPktob3NyYXZpLCBIb3JtdXpkIE08L0E+IDwvRElWPg0KICAgIDxESVYgc3R5bGU9IkZP TlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPWRvbmdsZ0BtYWls Lmh6aWMuZWR1LmNuIA0KICAgIGhyZWY9Im1haWx0bzpkb25nbGdAbWFpbC5oemljLmVkdS5jbiI+ TGlnYW5nIERvbmc8L0E+IDsgPEEgDQogICAgdGl0bGU9cmhhQHp1cmljaC5pYm0uY29tIGhyZWY9 Im1haWx0bzpyaGFAenVyaWNoLmlibS5jb20iPlJvYmVydCBIYWFzPC9BPiANCiAgICA8L0RJVj4N CiAgICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+Q2M6PC9CPiA8 QSB0aXRsZT1yYW0uZ29wYWxAbm9raWEuY29tIA0KICAgIGhyZWY9Im1haWx0bzpyYW0uZ29wYWxA bm9raWEuY29tIj5yYW0uZ29wYWxAbm9raWEuY29tPC9BPiA7IDxBIA0KICAgIHRpdGxlPWZvcmNl cy1wcm90b2NvbEBpZXRmLm9yZyANCiAgICBocmVmPSJtYWlsdG86Zm9yY2VzLXByb3RvY29sQGll dGYub3JnIj5mb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc8L0E+IDsgPEEgDQogICAgdGl0bGU9YXZy aUBwc2cuY29tIGhyZWY9Im1haWx0bzphdnJpQHBzZy5jb20iPmF2cmlAcHNnLmNvbTwvQT4gOyA8 QSANCiAgICB0aXRsZT1oYWRpQHpueXguY29tIGhyZWY9Im1haWx0bzpoYWRpQHpueXguY29tIj5o YWRpQHpueXguY29tPC9BPiA7IDxBIA0KICAgIHRpdGxlPXdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNu IGhyZWY9Im1haWx0bzp3bXdhbmdAbWFpbC5oemljLmVkdS5jbiI+V2VpbWluZyANCiAgICBXYW5n PC9BPiA8L0RJVj4NCiAgICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+ PEI+U2VudDo8L0I+IEZyaWRheSwgT2N0b2JlciAyMiwgMjAwNCAxMDozMCANCiAgICBBTTwvRElW Pg0KICAgIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0 OjwvQj4gUkU6IFtGb3JjZXMtcHJvdG9jb2xdIFJlOiBwcm90b2NvbCANCiAgICBkcmFmdCBlZGl0 aW5nPzwvRElWPg0KICAgIDxESVY+PEJSPjwvRElWPg0KICAgIDxESVYgY2xhc3M9U2VjdGlvbjE+ DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXpl PTI+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQt RkFNSUxZOiBBcmlhbCI+R28gYWhlYWQsIHBscyB0cnkgDQogICAgdG8gc2VuZCB1cyBzb21ldGhp bmcgYnkgdG9uaWdodCBvciB0b21vcnJvdyBtb3JuaW5nLjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAg IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxT UEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlM WTogQXJpYWwiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1h bD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPlRoYW5rcyBm b3IgDQogICAgdm9sdW50ZWVyaW5nLDwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICAgIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjwv U1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPkhvcm11emQ8L1NQQU4+PC9GT05U PjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5 IHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsg Rk9OVC1GQU1JTFk6IEFyaWFsIj48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgICA8RElWPg0K ICAgIDxESVYgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUFMSUdOOiBjZW50ZXIiIGFsaWdu PWNlbnRlcj48Rk9OVCANCiAgICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPWJsYWNrIHNp emU9Mz48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBDT0xPUjogd2luZG93dGV4 dCI+DQogICAgPEhSIHRhYkluZGV4PS0xIGFsaWduPWNlbnRlciB3aWR0aD0iMTAwJSIgU0laRT0y Pg0KICAgIDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxG T05UIGZhY2U9VGFob21hIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9O VC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQt RkFNSUxZOiBUYWhvbWEiPkZyb206PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogICAgZmFjZT1U YWhvbWEgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULUZBTUlMWTogVGFob21hIj4gTGlnYW5nIERvbmcg DQogICAgW21haWx0bzpkb25nbGdAbWFpbC5oemljLmVkdS5jbl0gPEJSPjxCPjxTUEFOIA0KICAg IHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U2VudDo8L1NQQU4+PC9CPiBUaHVyc2RheSwgT2N0 b2JlciAyMSwgMjAwNCA3OjE3IA0KICAgIFBNPEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdI VDogYm9sZCI+VG86PC9TUEFOPjwvQj4gS2hvc3JhdmksIEhvcm11emQgTTsgDQogICAgUm9iZXJ0 IEhhYXM8QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5DYzo8L1NQQU4+PC9C PiA8QSANCiAgICBocmVmPSJtYWlsdG86cmFtLmdvcGFsQG5va2lhLmNvbSI+cmFtLmdvcGFsQG5v a2lhLmNvbTwvQT47IDxBIA0KICAgIGhyZWY9Im1haWx0bzpmb3JjZXMtcHJvdG9jb2xAaWV0Zi5v cmciPmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZzwvQT47IDxBIA0KICAgIGhyZWY9Im1haWx0bzph dnJpQHBzZy5jb20iPmF2cmlAcHNnLmNvbTwvQT47IDxBIA0KICAgIGhyZWY9Im1haWx0bzpoYWRp QHpueXguY29tIj5oYWRpQHpueXguY29tPC9BPjsgV2VpbWluZyBXYW5nPEJSPjxCPjxTUEFOIA0K ICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+U3ViamVjdDo8L1NQQU4+PC9CPiBSZTogW0Zv cmNlcy1wcm90b2NvbF0gUmU6IA0KICAgIHByb3RvY29sIGRyYWZ0IGVkaXRpbmc/PC9TUEFOPjwv Rk9OVD48L1A+PC9ESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgY29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJ WkU6IDEycHQiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPg0KICAgIDxESVY+DQogICAgPFAgY2xh c3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9YmxhY2sgc2l6 ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPmhpLCA8L1NQQU4+PC9GT05U PjwvUD48L0RJVj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0Ij5JIGNhbiBlZGl0IHRoZSAic3RhdGUgbWFjaGluZSBmb3IgDQogICAg cHJvdG9jb2wiLjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgIDxESVY+DQogICAgPFAgY2xh c3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9YmxhY2sgc2l6 ZT0yPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQiPmxpZ2FuZzwvU1BBTj48L0ZP TlQ+PC9QPjwvRElWPg0KICAgIDxCTE9DS1FVT1RFIA0KICAgIHN0eWxlPSJCT1JERVItUklHSFQ6 IG1lZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6IG1lZGl1bSBub25l OyBQQURESU5HLUxFRlQ6IDRwdDsgUEFERElORy1CT1RUT006IDBpbjsgTUFSR0lOOiA1cHQgMGlu IDVwdCAzLjc1cHQ7IEJPUkRFUi1MRUZUOiBibGFjayAxLjVwdCBzb2xpZDsgUEFERElORy1UT1A6 IDBpbjsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICAgICAgPERJVj4NCiAgICAgIDxQ IGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPVNpbVN1biBjb2xvcj1ibGFjayBzaXplPTE+PFNQ QU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW4iPi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogICAgICA8L1NQQU4+PC9GT05UPjwvUD48L0RJ Vj4NCiAgICAgIDxESVYgc3R5bGU9ImZvbnQtY29sb3I6IGJsYWNrIj4NCiAgICAgIDxQIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNCI+PEI+PEZPTlQgZmFjZT1TaW1T dW4gDQogICAgICBjb2xvcj1ibGFjayBzaXplPTE+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1X RUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTogU2ltU3VuIj5Gcm9tOjwv U1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICAgICAgZmFjZT1TaW1TdW4gc2l6ZT0xPjxTUEFOIHN0 eWxlPSJGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IFNpbVN1biI+IDxBIA0KICAgICAgdGl0 bGU9aG9ybXV6ZC5tLmtob3NyYXZpQGludGVsLmNvbSANCiAgICAgIGhyZWY9Im1haWx0bzpob3Jt dXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tIj5LaG9zcmF2aSwgSG9ybXV6ZCBNPC9BPiANCiAgICAg IDwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgPERJVj4NCiAgICAgIDxQIGNsYXNzPU1z b05vcm1hbD48Qj48Rk9OVCBmYWNlPVNpbVN1biBjb2xvcj1ibGFjayBzaXplPTE+PFNQQU4gDQog ICAgICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlM WTogU2ltU3VuIj5Ubzo8L1NQQU4+PC9GT05UPjwvQj48Rk9OVCANCiAgICAgIGZhY2U9U2ltU3Vu IHNpemU9MT48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW4i PiA8QSANCiAgICAgIHRpdGxlPXJoYUB6dXJpY2guaWJtLmNvbSBocmVmPSJtYWlsdG86cmhhQHp1 cmljaC5pYm0uY29tIj5Sb2JlcnQgSGFhczwvQT4gDQogICAgICA8L1NQQU4+PC9GT05UPjwvUD48 L0RJVj4NCiAgICAgIDxESVY+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PEZPTlQgZmFj ZT1TaW1TdW4gY29sb3I9YmxhY2sgc2l6ZT0xPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtV0VJ R0hUOiBib2xkOyBGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IFNpbVN1biI+Q2M6PC9TUEFO PjwvRk9OVD48L0I+PEZPTlQgDQogICAgICBmYWNlPVNpbVN1biBzaXplPTE+PFNQQU4gc3R5bGU9 IkZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlMWTogU2ltU3VuIj4gPEEgDQogICAgICB0aXRsZT1y YW0uZ29wYWxAbm9raWEuY29tIA0KICAgICAgaHJlZj0ibWFpbHRvOnJhbS5nb3BhbEBub2tpYS5j b20iPnJhbS5nb3BhbEBub2tpYS5jb208L0E+IDsgPEEgDQogICAgICB0aXRsZT1kb25nbGdAbWFp bC5oemljLmVkdS5jbiBocmVmPSJtYWlsdG86ZG9uZ2xnQG1haWwuaHppYy5lZHUuY24iPkxpZ2Fu ZyANCiAgICAgIERvbmc8L0E+IDsgPEEgdGl0bGU9Zm9yY2VzLXByb3RvY29sQGlldGYub3JnIA0K ICAgICAgaHJlZj0ibWFpbHRvOmZvcmNlcy1wcm90b2NvbEBpZXRmLm9yZyI+Zm9yY2VzLXByb3Rv Y29sQGlldGYub3JnPC9BPiA7IDxBIA0KICAgICAgdGl0bGU9YXZyaUBwc2cuY29tIGhyZWY9Im1h aWx0bzphdnJpQHBzZy5jb20iPmF2cmlAcHNnLmNvbTwvQT4gOyA8QSANCiAgICAgIHRpdGxlPWhh ZGlAem55eC5jb20gaHJlZj0ibWFpbHRvOmhhZGlAem55eC5jb20iPmhhZGlAem55eC5jb208L0E+ IDsgPEEgDQogICAgICB0aXRsZT13bXdhbmdAbWFpbC5oemljLmVkdS5jbiANCiAgICAgIGhyZWY9 Im1haWx0bzp3bXdhbmdAbWFpbC5oemljLmVkdS5jbiI+V2VpbWluZyBXYW5nPC9BPiANCiAgICAg IDwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgPERJVj4NCiAgICAgIDxQIGNsYXNzPU1z b05vcm1hbD48Qj48Rk9OVCBmYWNlPVNpbVN1biBjb2xvcj1ibGFjayBzaXplPTE+PFNQQU4gDQog ICAgICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogOXB0OyBGT05ULUZBTUlM WTogU2ltU3VuIj5TZW50OjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICAgICAgZmFjZT1TaW1T dW4gc2l6ZT0xPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IFNpbVN1 biI+IA0KICAgICAgRnJpZGF5LCBPY3RvYmVyIDIyLCAyMDA0IDU6NDMgQU08L1NQQU4+PC9GT05U PjwvUD48L0RJVj4NCiAgICAgIDxESVY+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PEZP TlQgZmFjZT1TaW1TdW4gY29sb3I9YmxhY2sgc2l6ZT0xPjxTUEFOIA0KICAgICAgc3R5bGU9IkZP TlQtV0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDlwdDsgRk9OVC1GQU1JTFk6IFNpbVN1biI+U3Vi amVjdDo8L1NQQU4+PC9GT05UPjwvQj48Rk9OVCANCiAgICAgIGZhY2U9U2ltU3VuIHNpemU9MT48 U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW4iPiBSRTogDQog ICAgICBbRm9yY2VzLXByb3RvY29sXSBSZTogcHJvdG9jb2wgZHJhZnQgZWRpdGluZz88L1NQQU4+ PC9GT05UPjwvUD48L0RJVj4NCiAgICAgIDxESVY+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibGFjayBzaXplPTM+PFNQQU4gDQog ICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD48L0RJ Vj4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUg c2l6ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7 IEZPTlQtRkFNSUxZOiBBcmlhbCI+RGVhciBSb2JlcnQgDQogICAgICAoY28tYXV0aG9yIDopKSwg QWxsPC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibGFjayBzaXplPTM+PFNQQU4gDQogICAgICBzdHls ZT0iRk9OVC1TSVpFOiAxMnB0Ij48L1NQQU4+PC9GT05UPiZuYnNwOzwvUD4NCiAgICAgIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0K ICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBB cmlhbCI+SGVyZSBpcyBhIGxpc3Qgb2YgDQogICAgICBtYWpvciB0b2Rvcy4uLjwvU1BBTj48L0ZP TlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBS b21hbiIgY29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTog MTJwdCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPkhlYWRlciBT ZWN0aW9uIC0gDQogICAgICBKYW1hbC9Sb2JlcnQvV2VpbWluZz88L1NQQU4+PC9GT05UPjwvUD4N CiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6 ZT0yPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZP TlQtRkFNSUxZOiBBcmlhbCI+UHJvdG9jb2wgTEZCIC0gDQogICAgICBSb2JlcnQvT3RoZXJzPzwv U1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5GRSBMRkIgLSANCiAgICAgIFJvYmVy dC9PdGhlcnM/PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAg ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFs Ij5TdGF0ZSZuYnNwO01hY2hpbmUmbmJzcDtmb3ImbmJzcDtQcm90b2NvbCZuYnNwOy0mbmJzcDs/ PzwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAgICAgPERJVj4NCiAgICAgIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICAgICAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+ TWVzc2FnZXMgU2VjdGlvbiANCiAgICAgIC0mbmJzcDt3b3JraW5nIChIb3JtdXpkLCBXZWltaW5n KTwvU1BBTj48L0ZPTlQ+PEJSPjxGT05UIGZhY2U9QXJpYWwgDQogICAgICBjb2xvcj1ibHVlIHNp emU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBG T05ULUZBTUlMWTogQXJpYWwiPkhBIFNlY3Rpb24gLSBkb25lIA0KICAgICAgKEhvcm11emQpPC9T UEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5Qcm90 b2NvbCANCiAgICAgIFNjZW5hcmlvcyAtIFJhbS9IPC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQog ICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgY29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0la RTogMTJwdCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+PC9ESVY+DQogICAgICA8RElWPg0KICAg ICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+ PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1G QU1JTFk6IEFyaWFsIj5NaW5vciANCiAgICAgIHRvZG9zLi4uPC9TUEFOPjwvRk9OVD48L1A+PC9E SVY+DQogICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJp YWwgY29sb3I9Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5TZWN1cml0eSBzZWN0aW9uIA0KICAg ICAgLSBhbnkgdXBkYXRlcyBuZWVkZWQgUmFtID88L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAg ICAgIDxESVY+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9S OiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPlVwZGF0ZXMgdG8gDQogICAgICBPdmVydmlldyAo RnVycXVhbiBoYWQgc2VudCBjb21tZW50cyByZWdhcmRpbmcgaW5jb25zaXN0ZW5jaWVzKSAtZG9u ZSBKYW1hbCANCiAgICAgID88L1NQQU4+PC9GT05UPjwvUD48L0RJVj4NCiAgICAgIDxESVY+DQog ICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xv cj1ibGFjayBzaXplPTM+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48L1NQ QU4+PC9GT05UPiZuYnNwOzwvUD48L0RJVj4NCiAgICAgIDxESVY+DQogICAgICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibGFjayBzaXplPTM+ PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij48L1NQQU4+PC9GT05UPiZuYnNw OzwvUD48L0RJVj4NCiAgICAgIDxESVY+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlMWTogQXJpYWwiPkkgdGhpbmsgaWYgd2Ug Z2V0IA0KICAgICAgYWxsIHRoaXMgZG9uZSBiZWZvcmUgdGhlIGRlYWRsaW5lLCBpdCB3aWxsIGJl IGEgYmlnIA0KICAgICAgYWNjb21wbGlzaG1lbnQhPC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQog ICAgICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiIgY29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0la RTogMTJwdCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+PC9ESVY+DQogICAgICA8RElWPg0KICAg ICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+ PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1G QU1JTFk6IEFyaWFsIj5yZWdhcmRzPC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAgICA8RElW Pg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBz aXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsg Rk9OVC1GQU1JTFk6IEFyaWFsIj5Ib3JtdXpkPC9TUEFOPjwvRk9OVD48L1A+PC9ESVY+DQogICAg ICA8RElWPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 Ymx1ZSBzaXplPTI+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog Ymx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5wLnMuIFJvYmVydCwgSSANCiAgICAgIHdpbGwgcmVz cG9uZCB0byB5b3VyIHByZXZpb3VzIG5vdGUgaW4gbXkgbmV4dCBlbWFpbCwgaXQgbW9zdGx5IGxv b2tlZCBmaW5lIA0KICAgICAgSSB0aGluay4uLjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICAg ICAgPERJVj4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iIGNvbG9yPWJsYWNrIHNpemU9Mz48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPjwvRElWPg0KICAgICAgPERJViBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046IGNlbnRlciIgYWxpZ249Y2VudGVyPjxGT05UIA0K ICAgICAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibGFjayBzaXplPTM+PFNQQU4gc3R5 bGU9IkZPTlQtU0laRTogMTJwdCI+DQogICAgICA8SFIgdGFiSW5kZXg9LTEgYWxpZ249Y2VudGVy IHdpZHRoPSIxMDAlIiBTSVpFPTI+DQogICAgICA8L1NQQU4+PC9GT05UPjwvRElWPg0KICAgICAg PFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxGT05UIGZhY2U9VGFob21hIGNvbG9yPWJsYWNrIHNpemU9 Mj48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZDsgRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogVGFob21hIj5Gcm9tOjwvU1BBTj48L0ZPTlQ+PC9CPjxGT05UIA0KICAg ICAgZmFjZT1UYWhvbWEgc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBUYWhvbWEiPiANCiAgICAgIFJvYmVydCBIYWFzIFttYWlsdG86cmhhQHp1cmljaC5p Ym0uY29tXSA8L1NQQU4+PC9GT05UPjwvUD4NCiAgICAgIDxCTE9DS1FVT1RFIHN0eWxlPSJNQVJH SU4tVE9QOiA1cHQ7IE1BUkdJTi1CT1RUT006IDVwdCIgDQogICAgICBjaXRlPW1pZDQ2OEYzRkRB MjhBQTg3NDI5QUQ4MDc5OTJFMjJEMDdFMDI1NzkyMDBAb3JzbXN4NDA4IHR5cGU9ImNpdGUiPg0K ICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNp emU9Mj48U1BBTiANCiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7 IEZPTlQtRkFNSUxZOiBBcmlhbCI+Um9iZXJ0LDwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibGFj ayBzaXplPTM+PFNQQU4gDQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjwvU1BBTj48 L0ZPTlQ+Jm5ic3A7PC9QPg0KICAgICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+V2VpbWluZyBhbmQgDQogICAg ICAgIG15c2VsZiBhcmUgYWxyZWFkeSB3b3JraW5nIG9uIHRoaXMgc2VjdGlvboVJIHdpbGwgc2Vu ZCBvdXQgd2hhdCBJIGhhdmUgDQogICAgICAgIHNob3J0bHkuPC9TUEFOPjwvRk9OVD48L1A+DQog ICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6 ZT0yPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsg Rk9OVC1GQU1JTFk6IEFyaWFsIj5Tb21lIG9mIHRoZSANCiAgICAgICAgY2hhbmdlcyBhcmUgcHJl dHR5IHN0cmFpZ2h0Zm9yd2FyZCwgZS5nLiByZW1vdmUgc2VjdGlvbiA2LjYgDQogICAgICAgIDwv U1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT1XaW5nZGluZ3MgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4g DQogICAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlM WTogV2luZ2RpbmdzIj5KPC9TUEFOPjwvRk9OVD48L1A+DQogICAgICAgIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPWJsYWNrIHNpemU9Mz48U1BB TiANCiAgICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8 L1A+DQogICAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5h dnkgc2l6ZT0yPjxTUEFOIA0KICAgICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog bmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5Bbnl3YXlzIHdlIA0KICAgICAgICBjb3VsZCBkZWZp bml0ZWx5IHVzZSBoZWxwIGluIHRoZSBkcmFmdCwgdGhlcmUgaXMgbG90cyBvZiBzdHVmZiB0aGF0 IA0KICAgICAgICBuZWVkcyB0byBiZSBkb25lPC9TUEFOPjwvRk9OVD48L1A+PC9CTE9DS1FVT1RF Pg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIg Y29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ WW91IGJldC4gSSBzdXBwb3NlIEkgY2FuIGhlbHAgYXMgYSBjby1hdXRob3Igb2YgDQogICAgICB0 aGlzIGRyYWZ0IDstKTxCUj48QlI+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgICAg IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwi Pkkgd2lsbCBzZW5kIG91dCBhIA0KICAgICAgbGlzdCBvZiBvdGhlciB0b2RvIGl0ZW1zIHNob3J0 bHkuLjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5 bGU9IkZPTlQtU0laRTogMTJwdCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogICAgICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibGFjayBz aXplPTM+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5JJ2xsIHN0YXJ0IGZy b20geW91ciBpbnB1dCB0b21vcnJvdyBtb3JuaW5nIEV1cm9wZSANCiAgICAgIHRpbWUuIFBsZWFz ZSB0YWtlIGEgbG9vayBhdCBteSBwcmV2aW91cyBub3RlIGFuZCByZXZpZXcgdGhlIHBlbmRpbmcg aXNzdWVzIA0KICAgICAgSSBsaXN0ZWQuIFRoaXMgd2F5IHdlIGF2b2lkIGNoYW5naW5nIHRoZSB0 ZXh0IGJhY2sgYW5kIA0KICAgICAgZm9ydGguPEJSPjxCUj5UaGFua3MsPEJSPi1Sb2JlcnQ8QlI+ PEJSPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiIgY29sb3I9YmxhY2sgc2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5 bGU9IkZPTlQtU0laRTogMTJwdCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+DQogICAgICA8RElW IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1BTElHTjogY2VudGVyIiBhbGlnbj1jZW50ZXI+ PEZPTlQgDQogICAgICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIGNvbG9yPWJsYWNrIHNpemU9Mz48 U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4NCiAgICAgIDxIUiBhbGlnbj1jZW50ZXIgd2lk dGg9IjEwMCUiIFNJWkU9Mj4NCiAgICAgIDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBjb2xvcj1ibGFjayBz aXplPTM+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5Gb3JjZXMtcHJvdG9jb2wgDQog ICAgICBtYWlsaW5nIA0KICAgICAgbGlzdDxCUj5Gb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc8QlI+ aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZm9yY2VzLXByb3RvY29sPC9T UEFOPjwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPjwvRElWPjwvQkxPQ0tRVU9URT4NCiAgPFA+DQog IDxIUj4NCg0KICA8UD48L1A+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188QlI+Rm9yY2VzLXByb3RvY29sIA0KICBtYWlsaW5nIA0KICBsaXN0PEJSPkZvcmNl cy1wcm90b2NvbEBpZXRmLm9yZzxCUj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9mb3JjZXMtcHJvdG9jb2w8QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_008F_01C4BB3E.D4EE25C0-- --===============0807800335== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0807800335==-- From forces-protocol-bounces@ietf.org Mon Oct 25 22:31:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02256 for ; Mon, 25 Oct 2004 22:31:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMHKp-0007ly-Nu for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 22:45:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMH4P-0005wD-Sh; Mon, 25 Oct 2004 22:28:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMH27-0004vl-5m for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 22:25:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01996 for ; Mon, 25 Oct 2004 22:25:56 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMHFb-0007fk-5f for forces-protocol@ietf.org; Mon, 25 Oct 2004 22:40:00 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Tue, 26 Oct 2004 10:45:47 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Tue, 26 Oct 2004 10:21:18 +0800 Message-ID: <04e701c4bb02$c371cb80$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E0302DCB8@orsmsx408> <1098753546.1045.31.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Re: Conference Call this Week ? Date: Tue, 26 Oct 2004 10:23:21 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Putzolu, David" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 ----- Original Message ----- From: "Jamal Hadi Salim" Subject: [Forces-protocol] Re: Conference Call this Week ? > Hormuzd, > I will be there. > An agenda would be nice to have. Lets start with section 6 ;-> > Weiming I hope you can make this! I'm very busy from the day before yesterday, till nov. 29, to meet a deadline of a long report, but I'l still try to atend the meeting. One thing I have to mention is, I think we should still rely more on the list for consencus rather than conference. Obviously, I have some difficulty to catch all, and even worse is the phone voice is rather week. Thank you. Weiming > > cheers, > jamal > > On Mon, 2004-10-25 at 16:50, Khosravi, Hormuzd M wrote: > > Hi Team, > > > > I would propose we have a conference call this week to close on some of > > the outstanding issues. > > I think this is a good time since most of the issues are fresh in our > > minds and not all of us will be able to make it to the IETF meeting. For > > one, I will be unable to attend, so will Ram and Weiming I believe. Once > > we resolve these issues, we can submit another draft update by early > > next week. > > > > Let me know what day/time works for you. I would suggest Wed, Thu, or > > Friday early morning call my time i.e. 8 AM PST, but I will be happy to > > accommodate your times so that we can get everyone. > > > > Pls let us know soon ? > > > > > > Regards > > Hormuzd > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 22:45:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03220 for ; Mon, 25 Oct 2004 22:45:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMHY9-0007yn-OC for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 22:59:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMHJd-00048Z-4t; Mon, 25 Oct 2004 22:44:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMHFU-00087F-RX for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 22:39:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02920 for ; Mon, 25 Oct 2004 22:39:46 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMHT3-0007tK-CC for forces-protocol@ietf.org; Mon, 25 Oct 2004 22:53:50 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102519421441:41767 ; Mon, 25 Oct 2004 19:42:14 -0700 Subject: Re: [Forces-protocol] Re: Conference Call this Week ? From: Jamal Hadi Salim To: "Wang,Weiming" In-Reply-To: <04e701c4bb02$c371cb80$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E0302DCB8@orsmsx408> <1098753546.1045.31.camel@jzny.localdomain> <04e701c4bb02$c371cb80$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1098758382.1042.34.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Oct 2004 22:39:42 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/25/2004 07:42:14 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/25/2004 07:42:17 PM, Serialize complete at 10/25/2004 07:42:17 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Putzolu, David" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit On Mon, 2004-10-25 at 22:23, Wang,Weiming wrote: > ----- Original Message ----- > From: "Jamal Hadi Salim" > Subject: [Forces-protocol] Re: Conference Call this Week ? > > > > Hormuzd, > > I will be there. > > An agenda would be nice to have. Lets start with section 6 ;-> > > Weiming I hope you can make this! > I'm very busy from the day before yesterday, till nov. 29, to meet a deadline of > a long report, but I'l still try to atend the meeting. One thing I have to > mention is, I think we should still rely more on the list for consencus rather > than conference. Obviously, I have some difficulty to catch all, and even worse > is the phone voice is rather week. The one issue i would like to clarify with you is that of the path. After my previous posting(s) - does it make sense? Do we have a disagreement? etc. I think in my list this is the biggest unresolved issue. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 22:59:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03835 for ; Mon, 25 Oct 2004 22:59:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMHmL-0008CQ-LY for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 23:13:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMHXm-0000Bp-Tn; Mon, 25 Oct 2004 22:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMHXX-0008T2-36 for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 22:58:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03802 for ; Mon, 25 Oct 2004 22:58:24 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMHl3-00087L-6l for forces-protocol@ietf.org; Mon, 25 Oct 2004 23:12:29 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Tue, 26 Oct 2004 11:12:20 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Tue, 26 Oct 2004 10:47:50 +0800 Message-ID: <04f701c4bb06$78dcca30$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E0302DCB8@orsmsx408><1098753546.1045.31.camel@jzny.localdomain><04e701c4bb02$c371cb80$845c21d2@Necom.hzic.edu.cn> <1098758382.1042.34.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Re: Conference Call this Week ? Date: Tue, 26 Oct 2004 10:49:54 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Putzolu, David" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Jamal, that is also exactly what I want to discuss with you further. I'l response your earlier email very soon. cheers, weiming ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: [Forces-protocol] Re: Conference Call this Week ? > On Mon, 2004-10-25 at 22:23, Wang,Weiming wrote: > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > Subject: [Forces-protocol] Re: Conference Call this Week ? > > > > > > > Hormuzd, > > > I will be there. > > > An agenda would be nice to have. Lets start with section 6 ;-> > > > Weiming I hope you can make this! > > I'm very busy from the day before yesterday, till nov. 29, to meet a deadline of > > a long report, but I'l still try to atend the meeting. One thing I have to > > mention is, I think we should still rely more on the list for consencus rather > > than conference. Obviously, I have some difficulty to catch all, and even worse > > is the phone voice is rather week. > > The one issue i would like to clarify with you is that of the path. > After my previous posting(s) - does it make sense? Do we have a > disagreement? etc. I think in my list this is the biggest unresolved > issue. > > cheers, > jamal > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 23:22:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05144 for ; Mon, 25 Oct 2004 23:22:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMI8h-00006v-EJ for forces-protocol-web-archive@ietf.org; Mon, 25 Oct 2004 23:36:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMHug-0005kj-EW; Mon, 25 Oct 2004 23:22:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMHs0-0004w8-Iq for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 23:19:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04863 for ; Mon, 25 Oct 2004 23:19:33 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMI5U-0008SD-Rt for forces-protocol@ietf.org; Mon, 25 Oct 2004 23:33:38 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Tue, 26 Oct 2004 11:39:35 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Tue, 26 Oct 2004 11:15:05 +0800 Message-ID: <053c01c4bb0a$47497500$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <1098562959.1096.80.camel@jzny.localdomain> <1098564534.1098.106.camel@jzny.localdomain> <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn> <1098623794.1255.145.camel@jzny.localdomain> <007001c4ba44$fc908a50$845c21d2@Necom.hzic.edu.cn> <1098678563.1097.319.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Feedback: Section 6.4 Date: Tue, 26 Oct 2004 11:17:08 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, jhalpern@megisto.com, avri@psg.com, forces-protocol@ietf.org, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 ----- Original Message ----- From: "Jamal Hadi Salim" > On Sun, 2004-10-24 at 23:44, Wang,Weiming wrote: > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > Lets take an example of noop, since the xml for that is there and its a > very simple example. > > The class NOOP is 5. owned by IANA. > It has a simple table called datatable whose ID is 6. >Defined at xml creation. [Weiming] Let me call this ID an 'attribute ID'. Also in your XML, you'v called the table an attribute, right? > To point to first entry of datatable: 6,1 [Weiming]I'm glad to see this. It also means you'v agreed that the 'path' includes one subsection which is for attribute ID, right? Now the problem is, how many bits are you going to use for such ID, 8 bits or 16bits? I suppose you will not use a variable size for this ID. Whether the ID length is variable or not, we then can both reasonably think the 'path' as composed of follows: Path : = AttributeID Index that really matches my idea. I also think it mathces your idea too as presented in your example here as 6.1, 6.2.3, etc. To summarize, what I proposed actually include two thoughts: a) Attribute ID is necessary; b) the attribute ID should appear in the protocol layer. The followed Index can be included in Data field, becaue not all attributes need Index (they may only have one entry). I'm not sure if above helps or not. Cheers, Weiming > to point to foo1 within entry 2 of datatable: 6,2,3 > to point to foo2 of entry 3 of datatable: 6,3,4 > > I hope this clears it. I have attached two docs i worked on to > clarify this. > > As i said earlier, the path issue is resolved but not the data packing. > Of course if you disagree we could continue that discussion. > As you will notice in these docs, the text clearly states that the > data packing is not resolved. > > cheers, > jamal > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Mon Oct 25 23:52:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07892 for ; Mon, 25 Oct 2004 23:52:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMIb2-0000mk-Eh for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 00:06:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMIMC-0003Ig-CV; Mon, 25 Oct 2004 23:50:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMILF-00032r-MO for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 23:49:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07399 for ; Mon, 25 Oct 2004 23:49:46 -0400 (EDT) Received: from [64.254.114.117] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMIYc-0000gy-UY for forces-protocol@ietf.org; Tue, 26 Oct 2004 00:03:50 -0400 Received: from JLaptop.megisto.com ([192.168.20.235]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Oct 2004 23:48:39 -0400 Message-Id: <5.1.0.14.0.20041025234709.022f37b8@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Oct 2004 23:48:36 -0400 To: "Wang,Weiming" , From: "Joel M. Halpern" Subject: Re: [Forces-protocol] Feedback: Section 6.4 In-Reply-To: <053c01c4bb0a$47497500$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <1098562959.1096.80.camel@jzny.localdomain> <1098564534.1098.106.camel@jzny.localdomain> <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn> <1098623794.1255.145.camel@jzny.localdomain> <007001c4ba44$fc908a50$845c21d2@Necom.hzic.edu.cn> <1098678563.1097.319.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Oct 2004 03:48:39.0882 (UTC) FILETIME=[AE251AA0:01C4BB0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Remember that there may be structures inside structures, or arrays inside structures inside arrays inside structures, ... Hence, a path is a sequence of identifiers, each of which is either a subscript or an element identifier within the containing scope (initially the LFB classs definition, then progressive the structures selected by the earlier path elements. For simplicity, I suggest we make all the identifiers 32 bits. Yours, Joel At 11:17 AM 10/26/2004 +0800, Wang,Weiming wrote: > > To point to first entry of datatable: 6,1 >[Weiming]I'm glad to see this. It also means you'v agreed that the 'path' >includes one subsection which is for attribute ID, right? Now the problem is, >how many bits are you going to use for such ID, 8 bits or 16bits? I >suppose you >will not use a variable size for this ID. Whether the ID length is variable or >not, we then can both reasonably think the 'path' as composed of follows: > Path : = AttributeID Index > that really matches my idea. I also think it mathces your idea too as >presented in your example here as 6.1, 6.2.3, etc. > >To summarize, what I proposed actually include two thoughts: >a) Attribute ID is necessary; >b) the attribute ID should appear in the protocol layer. The followed >Index can >be included in Data field, becaue not all attributes need Index (they may only >have one entry). _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 00:00:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08514 for ; Tue, 26 Oct 2004 00:00:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMIjY-0000yH-IB for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 00:14:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMIRu-0004SD-NM; Mon, 25 Oct 2004 23:56:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMIQk-00049D-1l for forces-protocol@megatron.ietf.org; Mon, 25 Oct 2004 23:55:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08172 for ; Mon, 25 Oct 2004 23:55:26 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMIeI-0000qw-OE for forces-protocol@ietf.org; Tue, 26 Oct 2004 00:09:32 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9Q3Uaep003319; Tue, 26 Oct 2004 05:30:37 +0200 In-Reply-To: <5.1.0.14.0.20041025234709.022f37b8@mail.megisto.com> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <1098562959.1096.80.camel@jzny.localdomain> <1098564534.1098.106.camel@jzny.localdomain> <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn> <1098623794.1255.145.camel@jzny.localdomain> <007001c4ba44$fc908a50$845c21d2@Necom.hzic.edu.cn> <1098678563.1097.319.camel@jzny.localdomain> <5.1.0.14.0.20041025234709.022f37b8@mail.megisto.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] Feedback: Section 6.4 Date: Mon, 25 Oct 2004 23:55:20 -0400 To: "Joel M. Halpern" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, hadi@znyx.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit On 25 okt 2004, at 23.48, Joel M. Halpern wrote: > For simplicity, I suggest we make all the identifiers 32 bits. I certainly agree with this point. a. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 00:11:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09537 for ; Tue, 26 Oct 2004 00:11:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMIu9-0001FK-BE for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 00:25:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMIgG-0007h5-KA; Tue, 26 Oct 2004 00:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMIbB-0006BI-6D for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 00:06:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08924 for ; Tue, 26 Oct 2004 00:06:13 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMImW-000120-HR for forces-protocol@ietf.org; Tue, 26 Oct 2004 00:20:19 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Tue, 26 Oct 2004 12:23:48 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Tue, 26 Oct 2004 11:59:18 +0800 Message-ID: <055f01c4bb10$74623300$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , "Joel M. Halpern" References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <1098562959.1096.80.camel@jzny.localdomain> <1098564534.1098.106.camel@jzny.localdomain> <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn> <1098623794.1255.145.camel@jzny.localdomain> <007001c4ba44$fc908a50$845c21d2@Necom.hzic.edu.cn> <1098678563.1097.319.camel@jzny.localdomain> <5.1.0.14.0.20041025234709.022f37b8@mail.megisto.com> Subject: Re: [Forces-protocol] Feedback: Section 6.4 Date: Tue, 26 Oct 2004 12:01:21 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab ----- Original Message ----- From: "Joel M. Halpern" Subject: Re: [Forces-protocol] Feedback: Section 6.4 > Remember that there may be structures inside structures, or arrays inside > structures inside arrays inside structures, ... > > Hence, a path is a sequence of identifiers, I suppose you are proposing the 'path' is variable in length, which I think may be not the original idea of a path as a 32 bit index for table only. If it is, i think the idea mathces more to what I proposed. Definitely, I think the first ID appearing in the sequence is the attribute ID. >each of which is either a > subscript or an element identifier within the containing scope (initially > the LFB classs definition, then progressive the structures selected by the > earlier path elements. > For simplicity, I suggest we make all the identifiers 32 bits. I have no doubt to agree with this. Just need to calrify that a path is more than 32 bits long, or there will be not enough bits. Thank you. Weiming > > Yours, > Joel > > At 11:17 AM 10/26/2004 +0800, Wang,Weiming wrote: > > > To point to first entry of datatable: 6,1 > >[Weiming]I'm glad to see this. It also means you'v agreed that the 'path' > >includes one subsection which is for attribute ID, right? Now the problem is, > >how many bits are you going to use for such ID, 8 bits or 16bits? I > >suppose you > >will not use a variable size for this ID. Whether the ID length is variable or > >not, we then can both reasonably think the 'path' as composed of follows: > > Path : = AttributeID Index > > that really matches my idea. I also think it mathces your idea too as > >presented in your example here as 6.1, 6.2.3, etc. > > > >To summarize, what I proposed actually include two thoughts: > >a) Attribute ID is necessary; > >b) the attribute ID should appear in the protocol layer. The followed > >Index can > >be included in Data field, becaue not all attributes need Index (they may only > >have one entry). > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 00:16:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09991 for ; Tue, 26 Oct 2004 00:16:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMIyx-0001Nz-FA for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 00:30:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMIkR-00019u-OL; Tue, 26 Oct 2004 00:15:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMIhm-0008TG-L8 for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 00:13:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09610 for ; Tue, 26 Oct 2004 00:13:03 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMIvM-0001GH-Qv for forces-protocol@ietf.org; Tue, 26 Oct 2004 00:27:09 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9Q4CBR5016554; Tue, 26 Oct 2004 04:12:12 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9Q4GBKv028529; Tue, 26 Oct 2004 04:16:15 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102521123200566 ; Mon, 25 Oct 2004 21:12:32 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 25 Oct 2004 21:12:31 -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 Subject: [Forces-protocol] Conference Call this Week ?- time change (8:15 AM PST) Date: Mon, 25 Oct 2004 21:12:19 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0257922E@orsmsx408> Thread-Topic: [Forces-protocol] Conference Call this Week ?- time change (8:15 AM PST) Thread-Index: AcS7Awy/iCA3a36ETySIJYmqIh4T8wADkEkg From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 26 Oct 2004 04:12:31.0955 (UTC) FILETIME=[03BA1A30:01C4BB12] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Putzolu, David" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Hi Team, I am very sorry about this but I had a prior commitment (which did not show up on my calendar). So I will be unable to make it for the call before 8:15 AM. You guys can start the call by 8 AM, if you like and I will join in a bit later, or we can start at 8:15 AM. Very sorry about this, I should not have committed to 7 AM without making sure. Hopefully this will work for most of you, Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 00:46:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11742 for ; Tue, 26 Oct 2004 00:46:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMJRZ-0001sY-DW for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 01:00:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMJ6d-0006AR-Ov; Tue, 26 Oct 2004 00:38:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMJ5N-0005pF-Vl for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 00:37:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11396 for ; Tue, 26 Oct 2004 00:37:26 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMJIj-0001kG-Rw for forces-protocol@ietf.org; Tue, 26 Oct 2004 00:51:32 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Tue, 26 Oct 2004 12:57:20 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Tue, 26 Oct 2004 12:32:50 +0800 Message-ID: <058f01c4bb15$232c4e30$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E0302DCB8@orsmsx408> <1098753546.1045.31.camel@jzny.localdomain> <04e701c4bb02$c371cb80$845c21d2@Necom.hzic.edu.cn> <1098758382.1042.34.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Re: Conference Call this Week ? Date: Tue, 26 Oct 2004 12:34:52 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Putzolu, David" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 ----- Original Message ----- From: "Jamal Hadi Salim" > > Subject: [Forces-protocol] Re: Conference Call this Week ? > > > > > > > Hormuzd, > > > I will be there. > > > An agenda would be nice to have. Lets start with section 6 ;-> > > > Weiming I hope you can make this! > > I'm very busy from the day before yesterday, till nov. 29, to meet a deadline of > > a long report, but I'l still try to atend the meeting. One thing I have to > > mention is, I think we should still rely more on the list for consencus rather > > than conference. Obviously, I have some difficulty to catch all, and even worse > > is the phone voice is rather week. > > The one issue i would like to clarify with you is that of the path. > After my previous posting(s) - does it make sense? Do we have a > disagreement? etc. I think in my list this is the biggest unresolved > issue. [Weiming]Jamal, pls see my another post to see the difference between us on the idea of path. I think the path as you use is composed of two part: the attribute ID and the Index for table. The former will appear in the protocol definition, while the latter will only appear in the Data definition, and is OPTIONAL, because not all attributes are tables. That's all what I want express. In the current scheme of 'path-data' mode, If the path is specifically for the attributeID, then I will say I agree current scheme. Thanks. weiming > > cheers, > jamal > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 07:02:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23171 for ; Tue, 26 Oct 2004 07:02:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPJr-0000MT-3z for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 07:16:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMP61-0003Ff-L7; Tue, 26 Oct 2004 07:02:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMP4e-0002o7-6D for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 07:01:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23088 for ; Tue, 26 Oct 2004 07:01:05 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPIH-0000Kl-Vs for forces-protocol@ietf.org; Tue, 26 Oct 2004 07:15:14 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102604013955:42126 ; Tue, 26 Oct 2004 04:01:39 -0700 Subject: Re: [Forces-protocol] Feedback: Section 6.4 From: Jamal Hadi Salim To: "Wang,Weiming" In-Reply-To: <055f01c4bb10$74623300$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <1098562959.1096.80.camel@jzny.localdomain> <1098564534.1098.106.camel@jzny.localdomain> <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn> <1098623794.1255.145.camel@jzny.localdomain> <007001c4ba44$fc908a50$845c21d2@Necom.hzic.edu.cn> <1098678563.1097.319.camel@jzny.localdomain> <5.1.0.14.0.20041025234709.022f37b8@mail.megisto.com> <055f01c4bb10$74623300$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1098788345.1045.48.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Oct 2004 06:59:06 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/26/2004 04:01:40 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/26/2004 04:03:36 AM, Serialize complete at 10/26/2004 04:03:36 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Joel M. Halpern" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit On Tue, 2004-10-26 at 00:01, Wang,Weiming wrote: > I have no doubt to agree with this. Just need to calrify that a path is more > than 32 bits long, or there will be not enough bits. > Aha! I think i see where the misunderstanding is;-> Weiming sees either a path like 6 or 1,2,3,4 as represented by _one_ _fixed_ sized element. In which case you have to find a way to pack both representations into that fixed size element. The suggested "path" representation is in fact _variable_. >From the notes i sent earlier to you, the suggestion is: ---- A possible path-data layout. ---------------------------- OPER_TLV : = PATH-DATA := flags IDcount [BLOCK_OR_KEY_NOTATION] [DATA] The operational TLV contains an opcode in the T part. Its V contains the PATH-DATA. Opcodes discussed so far: * SET (create, modify or both depending on PATH-DATA flags} * DEL (remove an existing entity specified by PATH-DATA } * GET (Access a entity specified in PATH-DATA } * EV_S (subscribe to an event defined in PATH-DATA } * EV_U (unsubscribe to an event defined in PATH-DATA } -> IDs := a series of 32bit IDs (whose size is given by IDcount) defining the path. -> flags are used to further refine the operation to be applied on the ID_TLV. -> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension defined in section 4.2 and 4.3 of [1] -> DATA : = Optional variable sized data dependent on PATH and applied operations (eg GET will not have DATA). ------- Well read the rest of the doc; and for completion the notes posted by Steve/Zsolt. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 07:04:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23425 for ; Tue, 26 Oct 2004 07:04:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPLo-0000P9-1L for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 07:18:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMP6D-0003Os-Qa; Tue, 26 Oct 2004 07:02:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMP5i-00036z-V4 for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 07:02:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23136 for ; Tue, 26 Oct 2004 07:02:11 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPJM-0000Lr-UD for forces-protocol@ietf.org; Tue, 26 Oct 2004 07:16:21 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102604044254:42128 ; Tue, 26 Oct 2004 04:04:42 -0700 Subject: Re: [Forces-protocol] Re: Conference Call this Week ? From: Jamal Hadi Salim To: "Wang,Weiming" In-Reply-To: <058f01c4bb15$232c4e30$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E0302DCB8@orsmsx408> <1098753546.1045.31.camel@jzny.localdomain> <04e701c4bb02$c371cb80$845c21d2@Necom.hzic.edu.cn> <1098758382.1042.34.camel@jzny.localdomain> <058f01c4bb15$232c4e30$845c21d2@Necom.hzic.edu.cn> Organization: ZNYX Networks Message-Id: <1098788530.1045.52.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Oct 2004 07:02:11 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/26/2004 04:04:42 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/26/2004 04:04:43 AM, Serialize complete at 10/26/2004 04:04:43 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Putzolu, David" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit On Tue, 2004-10-26 at 00:34, Wang,Weiming wrote: > In the current scheme of 'path-data' mode, If the path is specifically for the > attributeID, then I will say I agree current scheme. > Yes, it is (if yopu want to call a table index also an attribute ID). Look at my other posting. Note as well that how data is packed is still under discussion and undecided. Theres a scheme posted by Zsolt which tries to pack the way Java would serialize for example which has so far proven insufficient. So please look at that and contribute to the discussion. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 07:19:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24565 for ; Tue, 26 Oct 2004 07:19:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPaI-0000ek-8j for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 07:33:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPLj-0006Md-Gl; Tue, 26 Oct 2004 07:18:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPFO-0004uX-Vd for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 07:12:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24062 for ; Tue, 26 Oct 2004 07:12:11 -0400 (EDT) Received: from [64.254.114.117] (helo=megisto-e2k.megisto.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPSr-0000WX-Sd for forces-protocol@ietf.org; Tue, 26 Oct 2004 07:26:21 -0400 Received: from JLaptop.megisto.com ([192.168.20.230]) by megisto-e2k.megisto.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 26 Oct 2004 07:11:06 -0400 Message-Id: <5.1.0.14.0.20041026070458.0239e560@mail.megisto.com> X-Sender: jhalpern@mail.megisto.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Oct 2004 07:05:03 -0400 To: "Wang,Weiming" , From: "Joel M. Halpern" Subject: Re: [Forces-protocol] Feedback: Section 6.4 In-Reply-To: <055f01c4bb10$74623300$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <1098562959.1096.80.camel@jzny.localdomain> <1098564534.1098.106.camel@jzny.localdomain> <130801c4b9c3$ac205d60$845c21d2@Necom.hzic.edu.cn> <1098623794.1255.145.camel@jzny.localdomain> <007001c4ba44$fc908a50$845c21d2@Necom.hzic.edu.cn> <1098678563.1097.319.camel@jzny.localdomain> <5.1.0.14.0.20041025234709.022f37b8@mail.megisto.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 26 Oct 2004 11:11:06.0362 (UTC) FILETIME=[7D147DA0:01C4BB4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 The path from the LFB instance to the element being targeted (by the SET or GET) is variable in length. (I was going to write "must be variable in length". One could craft a very complex mechanism to assign ids from a flat space to every such multi-step path. But it does not seem a good idea.) Yours, Joel At 12:01 PM 10/26/2004 +0800, Wang,Weiming wrote: > > Remember that there may be structures inside structures, or arrays inside > > structures inside arrays inside structures, ... > > > > Hence, a path is a sequence of identifiers, >I suppose you are proposing the 'path' is variable in length, which I >think may >be not the original idea of a path as a 32 bit index for table only. >If it is, i think the idea mathces more to what I proposed. Definitely, I >think >the first ID appearing in the sequence is the attribute ID. > > >each of which is either a > > subscript or an element identifier within the containing scope (initially > > the LFB classs definition, then progressive the structures selected by the > > earlier path elements. > > For simplicity, I suggest we make all the identifiers 32 bits. >I have no doubt to agree with this. Just need to calrify that a path is more >than 32 bits long, or there will be not enough bits. > >Thank you. >Weiming _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 07:21:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24913 for ; Tue, 26 Oct 2004 07:21:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPcI-0000j1-H6 for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 07:35:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPLl-0006NX-G5; Tue, 26 Oct 2004 07:18:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPJO-0005jR-H5 for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 07:16:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24252 for ; Tue, 26 Oct 2004 07:16:19 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPX2-0000bS-KO for forces-protocol@ietf.org; Tue, 26 Oct 2004 07:30:28 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102604184990:42137 ; Tue, 26 Oct 2004 04:18:49 -0700 Subject: Re: [Forces-protocol] Conference Call this Week ?- time change (8:15 AM PST) From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0257922E@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0257922E@orsmsx408> Organization: ZNYX Networks Message-Id: <1098789378.1041.55.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Oct 2004 07:16:18 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/26/2004 04:18:50 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/26/2004 04:18:51 AM, Serialize complete at 10/26/2004 04:18:51 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, avri@psg.com, "Putzolu, David" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit To let everybody know: I am open to whatever time that is decided. I have no scheduled meetings. cheers, jamal On Tue, 2004-10-26 at 00:12, Khosravi, Hormuzd M wrote: > Hi Team, > > I am very sorry about this but I had a prior commitment (which did not > show up on my calendar). So I will be unable to make it for the call > before 8:15 AM. You guys can start the call by 8 AM, if you like and I > will join in a bit later, or we can start at 8:15 AM. Very sorry about > this, I should not have committed to 7 AM without making sure. > > Hopefully this will work for most of you, > > Thanks > Hormuzd > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 07:22:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25040 for ; Tue, 26 Oct 2004 07:22:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPdG-0000kd-Ul for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 07:36:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPLl-0006Ng-Td; Tue, 26 Oct 2004 07:18:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPKc-0005x4-DY for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 07:17:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24325 for ; Tue, 26 Oct 2004 07:17:35 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMPYG-0000cS-CO for forces-protocol@ietf.org; Tue, 26 Oct 2004 07:31:44 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102604200482:42138 ; Tue, 26 Oct 2004 04:20:04 -0700 Subject: Re: [Forces-protocol] RE: GET/SET in one msg ? From: Jamal Hadi Salim To: Ligang Dong In-Reply-To: <002001c4bafa$df86cbc0$8401a8c0@dlg> References: <468F3FDA28AA87429AD807992E22D07E025791E5@orsmsx408> <002d01c4b50b$1ecc9c10$020aa8c0@wwm1> <1098102734.1042.134.camel@jzny.localdomain> <013101c4b51d$a50761e0$020aa8c0@wwm1> <1098134060.1077.446.camel@jzny.localdomain> <5.1.0.14.0.20041019093826.0232d418@mail.megisto.com> <055401c4b669$97a1c840$845c21d2@Necom.hzic.edu.cn> <1098383190.2883.386.camel@localhost.localdomain> <00dd01c4b803$806bd620$8401a8c0@dlg> <1098442868.1112.38.camel@jzny.localdomain> <00c601c4ba72$241599d0$8401a8c0@dlg> <1098722995.1034.67.camel@jzny.localdomain> <417D61D4.6000909@zurich.ibm.com> <002001c4bafa$df86cbc0$8401a8c0@dlg> Organization: ZNYX Networks Message-Id: <1098789452.1044.57.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Oct 2004 07:17:33 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/26/2004 04:20:05 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/26/2004 04:20:07 AM X-Spam-Score: 2.2 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, "Joel M. Halpern" , Zsolt Haraszti , "Steven Blake \(petri-meat\)" , forces-protocol@ietf.org, "Wang, Weiming" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0566263264==" Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 --===============0566263264== Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 DQoNCkkgY29uY3VyIHdpdGggTGlnYW5nLiBSb2JlcnQgaWYgeW91IGNhbiBhc2sgZm9yIGEgc2xv dCwgSSB0aGluayB0aGlzDQppc3N1ZSBuZWVkcyB0byBiZSByZXNvbHZlZC4NCg0KY2hlZXJzLA0K amFtYWwNCg0KT24gTW9uLCAyMDA0LTEwLTI1IGF0IDIxOjI2LCBMaWdhbmcgRG9uZyB3cm90ZToN Cj4gaGksIA0KPiBKYW1hbCwgdGhhbmsgeW91IGZvciB0aGUgc3VtbWFyaXphdGlvbiBhYm91dCB0 aGlzIGlzc3VlLg0KPiBSb2JlcnQsIHRoYW5rIHlvdSBmb3IgdGhlIHByZXNlbnRhdGlvbiBhYm91 dCB0aGlzIGlzc3VlLiANCj4gV2UgaGF2ZSB0aGUgc2FtZSBvYmplY3RpdmUgb2YgbWFraW5nIHRo ZSBwcm90b2NvbCBzaW1wbGUgYW5kIGVmZmljaWVudC4NCj4gYmVzdCByZWdhcmRzDQo+IExpZ2Fu Zw0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPiBGcm9tOiAiUm9iZXJ0IEhhYXMi IDxyaGFAenVyaWNoLmlibS5jb20+DQo+IFRvOiA8aGFkaUB6bnl4LmNvbT4NCj4gQ2M6ICJMaWdh bmcgRG9uZyIgPGRvbmdsZ0BtYWlsLmh6aWMuZWR1LmNuPjsgIktob3NyYXZpLCBIb3JtdXpkIE0i IDxob3JtdXpkLm0ua2hvc3JhdmlAaW50ZWwuY29tPjsgPHJhbS5nb3BhbEBub2tpYS5jb20+OyAi U3RldmVuIEJsYWtlIChwZXRyaS1tZWF0KSIgPHNsYmxha2VAcGV0cmktbWVhdC5jb20+OyAiWnNv bHQgSGFyYXN6dGkiIDx6c29sdEBtb2R1bGFybmV0LmNvbT47ICJKb2VsIE0uIEhhbHBlcm4iIDxq aGFscGVybkBtZWdpc3RvLmNvbT47IDxmb3JjZXMtcHJvdG9jb2xAaWV0Zi5vcmc+OyAiV2FuZywg V2VpbWluZyIgPHdtd2FuZ0BtYWlsLmh6aWMuZWR1LmNuPg0KPiBTZW50OiBUdWVzZGF5LCBPY3Rv YmVyIDI2LCAyMDA0IDQ6MjggQU0NCj4gU3ViamVjdDogUmU6IFtGb3JjZXMtcHJvdG9jb2xdIFJF OiBHRVQvU0VUIGluIG9uZSBtc2cgPw0KPiANCj4gDQo+ID4gSmFtYWwsDQo+ID4gDQo+ID4gSmFt YWwgSGFkaSBTYWxpbSB3cm90ZToNCj4gPiANCj4gPiA+SSByZWFsaXplZCBhZnRlciBpIHJlc3Bv bmRlZCB0byB5b3UgdGhhdCB0aGUgYXBwcm9hY2ggeW91IHBvc3RlZCBpcw0KPiA+ID5zbGlnaHRs eSBkaWZmZXJlbnQsIGJ1dCBlbmQgZ29hbHMgdGhlIHNhbWUuIFNvIGZhciBpIHRoaW5rIHRoZXJl IGFyZQ0KPiA+ID50aHJlZSBhcHByb2FjaGVzIGJlaW5nIHRhbGtlZCBhYm91dC4NCj4gPiA+MSkg WW91cnMNCj4gPiA+MikgU3RldmUvUm9iZXJ0IHdpdGggTUlJRCAod2hjaWggdW5mb3J0dW5hdGVs eSBtYWRlIGl0IGludG8gdGhlIGRyYWZ0DQo+ID4gPmJlZm9yZSBjb25zZW5zdXMgd2FzIHJlYWNo ZWQpDQo+ID4gPiAgDQo+ID4gPg0KPiA+IFNvcnJ5LCB0aGF0IHdhcyBub3QgbXkgaW50ZW50LiBN eSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IHRoZXJlIHdhcyBubyANCj4gPiBvdGhlciBwcm9wb3Nh bCBhZGRyZXNzaW5nIHRoaXMgaXNzdWUgaW4gcGFydGljdWxhci4NCj4gPiANCj4gPiA+MykgV2hh dCBpIHBvc3RlZCANCj4gPiA+ICANCj4gPiA+DQo+ID4gSSBtdXN0IGhhdmUgbWlzc2VkIHRoYXQu DQo+ID4gDQo+ID4gPk1heWJlIHNvbWVvbmUgbmVlZHMgdG8gcHJlc2VudCBhdCB0aGUgbWVldGlu Zy4NCj4gPiA+DQo+ID4gPiAgDQo+ID4gPg0KPiA+IERlZmluaXRlbHkuIEEgc2hvcnQgcHJlc2Vu dGF0aW9uIHN1bW1hcml6aW5nIGFsbCB0aGUgb3B0aW9ucy4gSSBjb3VsZCANCj4gPiB0YWtlIGNh cmUgb2YgdGhhdCAocHJvYmFibHkgbmVlZCAzMCBtaW4gd2l0aCB0aGUgZGlzY3Vzc2lvbikuDQo+ ID4gDQo+ID4gLS0gDQo+ID4gUm9iZXJ0IEhhYXMNCj4gPiBJQk0gWnVyaWNoIFJlc2VhcmNoIExh Ym9yYXRvcnkNCj4gPiBT5HVtZXJzdHJhc3NlIDQNCj4gPiBDSC04ODAzIFL8c2NobGlrb24vU3dp dHplcmxhbmQNCj4gPiBwaG9uZSArNDEtMS03MjQtODY5OCAgZmF4ICs0MS0xLTcyNC04NTc4ICBo dHRwOi8vd3d3Lnp1cmljaC5pYm0uY29tL35yaGENCj4gPiANCg0K --===============0566263264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol --===============0566263264==-- From forces-protocol-bounces@ietf.org Tue Oct 26 07:50:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28253 for ; Tue, 26 Oct 2004 07:50:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMQ4H-0001RW-Fs for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 08:04:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPpg-0003yh-Vd; Tue, 26 Oct 2004 07:49:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMPng-0003Sy-HS for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 07:47:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28117 for ; Tue, 26 Oct 2004 07:47:39 -0400 (EDT) From: ram.gopal@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMQ1J-0001OI-MY for forces-protocol@ietf.org; Tue, 26 Oct 2004 08:01:47 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9QBlJl11545; Tue, 26 Oct 2004 14:47:20 +0300 (EET DST) X-Scanned: Tue, 26 Oct 2004 14:43:24 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9QBhO6B014053; Tue, 26 Oct 2004 14:43:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00C6xoOA; Tue, 26 Oct 2004 14:43:23 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9QBhGa22596; Tue, 26 Oct 2004 14:43:16 +0300 (EET DST) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 26 Oct 2004 06:43:16 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 26 Oct 2004 07:43:12 -0400 Message-ID: Thread-Topic: Conference Call this Week ? Thread-Index: AcS6ZRUR240nrv45Rl2DphwkdcQeAwAbGw8QAAB/YxAAH1OgsA== To: , , , , , , X-OriginalArrivalTime: 26 Oct 2004 11:43:16.0348 (UTC) FILETIME=[FB70FBC0:01C4BB50] X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: david.putzolu@intel.com Subject: [Forces-protocol] RE: Conference Call this Week ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable I will not be attending this IETF due to travel restrictions etc.=20 Regarding the conference call it you can start at 8:30 AM your time that = would be good. I have other meetings. Regards Ramg -----Original Message----- From: ext Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] Sent: Monday, October 25, 2004 4:50 PM To: avri@psg.com; Ligang Dong; forces-protocol@ietf.org; Wang,Weiming; Robert Haas; Jamal Hadi Salim; Gopal Ram (Nokia-NRC/Boston) Cc: Putzolu, David Subject: Conference Call this Week ? Hi Team, I would propose we have a conference call this week to close on some of the outstanding issues. I think this is a good time since most of the issues are fresh in our minds and not all of us will be able to make it to the IETF meeting. For one, I will be unable to attend, so will Ram and Weiming I believe. Once we resolve these issues, we can submit another draft update by early next week. Let me know what day/time works for you. I would suggest Wed, Thu, or Friday early morning call my time i.e. 8 AM PST, but I will be happy to accommodate your times so that we can get everyone.=20 Pls let us know soon ? Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 12:34:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20943 for ; Tue, 26 Oct 2004 12:34:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUVB-0006ys-1E for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 12:48:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUGx-0000r9-Oa; Tue, 26 Oct 2004 12:34:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUBk-0008NP-0c for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 12:28:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20550 for ; Tue, 26 Oct 2004 12:28:45 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUPQ-0006rV-M2 for forces-protocol@ietf.org; Tue, 26 Oct 2004 12:42:57 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9QGSo7Z022421; Tue, 26 Oct 2004 16:28:50 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9QGLEUR030833; Tue, 26 Oct 2004 16:21:25 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102609280121178 ; Tue, 26 Oct 2004 09:28:01 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Oct 2004 09:28:01 -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 Date: Tue, 26 Oct 2004 09:27:49 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579239@orsmsx408> Thread-Topic: Conference Call this Week ? Thread-Index: AcS6ZRUR240nrv45Rl2DphwkdcQeAwAbGw8QAAB/YxAAH1OgsAAJ6/Ug From: "Khosravi, Hormuzd M" To: , , , , , , X-OriginalArrivalTime: 26 Oct 2004 16:28:01.0267 (UTC) FILETIME=[C2D8BC30:01C4BB78] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: "Putzolu, David" Subject: [Forces-protocol] RE: Conference Call this Week ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Ok, we can start at 8:30 AM. I guess Avri might have to leave early in this case. Avri, will it be possible for you to attend this meeting on your mobile from the airport ? Pls do let us know if you have any suggestions, Thanks Hormuzd -----Original Message----- From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]=20 Sent: Tuesday, October 26, 2004 4:43 AM To: Khosravi, Hormuzd M; avri@psg.com; donglg@mail.hzic.edu.cn; forces-protocol@ietf.org; wmwang@mail.hzic.edu.cn; rha@zurich.ibm.com; hadi@znyx.com Cc: Putzolu, David Subject: RE: Conference Call this Week ? I will not be attending this IETF due to travel restrictions etc.=20 Regarding the conference call it you can start at 8:30 AM your time that would be good. I have other meetings. Regards Ramg -----Original Message----- From: ext Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] Sent: Monday, October 25, 2004 4:50 PM To: avri@psg.com; Ligang Dong; forces-protocol@ietf.org; Wang,Weiming; Robert Haas; Jamal Hadi Salim; Gopal Ram (Nokia-NRC/Boston) Cc: Putzolu, David Subject: Conference Call this Week ? Hi Team, I would propose we have a conference call this week to close on some of the outstanding issues. I think this is a good time since most of the issues are fresh in our minds and not all of us will be able to make it to the IETF meeting. For one, I will be unable to attend, so will Ram and Weiming I believe. Once we resolve these issues, we can submit another draft update by early next week. Let me know what day/time works for you. I would suggest Wed, Thu, or Friday early morning call my time i.e. 8 AM PST, but I will be happy to accommodate your times so that we can get everyone.=20 Pls let us know soon ? Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 13:12:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24533 for ; Tue, 26 Oct 2004 13:12:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMV5Q-00085Y-71 for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 13:26:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUey-00085J-N0; Tue, 26 Oct 2004 12:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUZv-00074m-2Y for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 12:53:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22181 for ; Tue, 26 Oct 2004 12:53:44 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUnc-0007LB-9F for forces-protocol@ietf.org; Tue, 26 Oct 2004 13:07:56 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9QGSpep004539; Tue, 26 Oct 2004 18:28:52 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579239@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E02579239@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <964204F8-276F-11D9-9DB1-000393CC2112@psg.com> Content-Transfer-Encoding: 7bit Date: Tue, 26 Oct 2004 12:53:39 -0400 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, wmwang@mail.hzic.edu.cn, forces-protocol@ietf.org, hadi@znyx.com, "Putzolu, David" , donglg@mail.hzic.edu.cn, rha@zurich.ibm.com Subject: [Forces-protocol] Re: Conference Call this Week ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit i will stick with it as long as i can, probably can do about an hour. i also think we need to talk about the 'path' issue. i must admit that at the moment, i would be unable to clearly delineate the two, or is it more, positions. is there anyone on this list, preferably not one of the protagonists who tend to speak in their own terms, who can boil down the issue to a few sentences? a. On 26 okt 2004, at 12.27, Khosravi, Hormuzd M wrote: > Ok, we can start at 8:30 AM. I guess Avri might have to leave early in > this case. Avri, will it be possible for you to attend this meeting on > your mobile from the airport ? > > Pls do let us know if you have any suggestions, > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 13:35:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27286 for ; Tue, 26 Oct 2004 13:35:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVSJ-0000Qi-EJ for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 13:49:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVCZ-00027A-Rm; Tue, 26 Oct 2004 13:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUw4-0005Rk-1f for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 13:16:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25017 for ; Tue, 26 Oct 2004 13:16:36 -0400 (EDT) Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMV9j-0008B6-2e for forces-protocol@ietf.org; Tue, 26 Oct 2004 13:30:49 -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 i9QHFeDq336830; Tue, 26 Oct 2004 17:15:40 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9QHFYVb156636; Tue, 26 Oct 2004 18:15:34 +0100 Received: from [9.145.249.145] (sig-9-145-249-145.de.ibm.com [9.145.249.145]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA14822; Tue, 26 Oct 2004 19:15:32 +0200 Message-ID: <417E8626.4070701@zurich.ibm.com> Date: Tue, 26 Oct 2004 19:15:18 +0200 From: Robert Haas Organization: IBM Research Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E02579239@orsmsx408> In-Reply-To: <468F3FDA28AA87429AD807992E22D07E02579239@orsmsx408> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mtagate1.uk.ibm.com id i9QHFeDq336830 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, donglg@mail.hzic.edu.cn, forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, "Putzolu, David" , wmwang@mail.hzic.edu.cn Subject: [Forces-protocol] Re: Conference Call this Week ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Hormuzd, 8.30am is fine with me. But I won't be able to make it for more than an=20 hour. Could you please make sure that we have an agenda with time allocated=20 for each item, in order of importance if possible ? Who will take notes=20 ? As a general remark, it is more productive if for each item someone=20 presents a brief intro of the issue to get everyone in synch. Regards, -Robert Khosravi, Hormuzd M wrote: >Ok, we can start at 8:30 AM. I guess Avri might have to leave early in >this case. Avri, will it be possible for you to attend this meeting on >your mobile from the airport ? > >Pls do let us know if you have any suggestions, > >Thanks >Hormuzd > >-----Original Message----- >From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]=20 >Sent: Tuesday, October 26, 2004 4:43 AM >To: Khosravi, Hormuzd M; avri@psg.com; donglg@mail.hzic.edu.cn; >forces-protocol@ietf.org; wmwang@mail.hzic.edu.cn; rha@zurich.ibm.com; >hadi@znyx.com >Cc: Putzolu, David >Subject: RE: Conference Call this Week ? > >I will not be attending this IETF due to travel restrictions etc.=20 >Regarding the conference call it you can start at 8:30 AM your time that >would be good. I have other meetings. > >Regards >Ramg > >-----Original Message----- >From: ext Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] >Sent: Monday, October 25, 2004 4:50 PM >To: avri@psg.com; Ligang Dong; forces-protocol@ietf.org; Wang,Weiming; >Robert Haas; Jamal Hadi Salim; Gopal Ram (Nokia-NRC/Boston) >Cc: Putzolu, David >Subject: Conference Call this Week ? > > >Hi Team, > >I would propose we have a conference call this week to close on some of >the outstanding issues. >I think this is a good time since most of the issues are fresh in our >minds and not all of us will be able to make it to the IETF meeting. For >one, I will be unable to attend, so will Ram and Weiming I believe. Once >we resolve these issues, we can submit another draft update by early >next week. > >Let me know what day/time works for you. I would suggest Wed, Thu, or >Friday early morning call my time i.e. 8 AM PST, but I will be happy to >accommodate your times so that we can get everyone.=20 > >Pls let us know soon ? > > >Regards >Hormuzd > > > =20 > --=20 Robert Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-1-724-8698 fax +41-1-724-8578 http://www.zurich.ibm.com/~rha _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 13:39:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27621 for ; Tue, 26 Oct 2004 13:39:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVWB-0000VX-Uh for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 13:54:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVDm-0002d1-H3; Tue, 26 Oct 2004 13:34:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMV2Q-0007op-3U for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 13:23:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25978 for ; Tue, 26 Oct 2004 13:23:10 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVG7-0008Tp-9H for forces-protocol@ietf.org; Tue, 26 Oct 2004 13:37:23 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9QHMER5022916; Tue, 26 Oct 2004 17:22:19 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9QHNQLT012284; Tue, 26 Oct 2004 17:25:59 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102610214912637 ; Tue, 26 Oct 2004 10:21:55 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Oct 2004 10:21:37 -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 Date: Tue, 26 Oct 2004 10:21:36 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0306B008@orsmsx408> Thread-Topic: Conference Call this Week ? Thread-Index: AcS7f3o4ECQg9kCnTLeIyq3/bNK4MAAABfww From: "Khosravi, Hormuzd M" To: "Robert Haas" X-OriginalArrivalTime: 26 Oct 2004 17:21:37.0539 (UTC) FILETIME=[3FE4E530:01C4BB80] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, donglg@mail.hzic.edu.cn, forces-protocol@ietf.org, avri@psg.com, hadi@znyx.com, "Putzolu, David" , wmwang@mail.hzic.edu.cn Subject: [Forces-protocol] RE: Conference Call this Week ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Robert, Absolutely...I will send out an agenda shortly with time allocated and we should make sure to do what you suggest...present a brief intro, brainstorm and come to some resolution. I will reserve a 2 hour slot for this meeting starting from 8-10 AM, but we should be discussing the major issues between 8:30-9:30 so all can be present. Regards, Hormuzd -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 Sent: Tuesday, October 26, 2004 10:15 AM To: Khosravi, Hormuzd M Cc: ram.gopal@nokia.com; avri@psg.com; donglg@mail.hzic.edu.cn; forces-protocol@ietf.org; wmwang@mail.hzic.edu.cn; hadi@znyx.com; Putzolu, David Subject: Re: Conference Call this Week ? Hormuzd, 8.30am is fine with me. But I won't be able to make it for more than an=20 hour. Could you please make sure that we have an agenda with time allocated=20 for each item, in order of importance if possible ? Who will take notes=20 ? As a general remark, it is more productive if for each item someone=20 presents a brief intro of the issue to get everyone in synch. Regards, -Robert Khosravi, Hormuzd M wrote: >Ok, we can start at 8:30 AM. I guess Avri might have to leave early in >this case. Avri, will it be possible for you to attend this meeting on >your mobile from the airport ? > >Pls do let us know if you have any suggestions, > >Thanks >Hormuzd > >-----Original Message----- >From: ram.gopal@nokia.com [mailto:ram.gopal@nokia.com]=20 >Sent: Tuesday, October 26, 2004 4:43 AM >To: Khosravi, Hormuzd M; avri@psg.com; donglg@mail.hzic.edu.cn; >forces-protocol@ietf.org; wmwang@mail.hzic.edu.cn; rha@zurich.ibm.com; >hadi@znyx.com >Cc: Putzolu, David >Subject: RE: Conference Call this Week ? > >I will not be attending this IETF due to travel restrictions etc.=20 >Regarding the conference call it you can start at 8:30 AM your time that >would be good. I have other meetings. > >Regards >Ramg > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 13:41:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27700 for ; Tue, 26 Oct 2004 13:41:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVXU-0000X2-F4 for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 13:55:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVE0-0002k5-17; Tue, 26 Oct 2004 13:35:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMV9a-00018w-G8 for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 13:30:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26664 for ; Tue, 26 Oct 2004 13:30:35 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVNG-0000FP-Oc for forces-protocol@ietf.org; Tue, 26 Oct 2004 13:44:48 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9QHY4Da001994; Tue, 26 Oct 2004 17:34:04 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9QHWpL5021916; Tue, 26 Oct 2004 17:33:39 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102610291414850 ; Tue, 26 Oct 2004 10:29:14 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Oct 2004 10:29:14 -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 Date: Tue, 26 Oct 2004 10:29:13 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0306B03E@orsmsx408> Thread-Topic: Conference Call details Thread-Index: AcS7f3o4ECQg9kCnTLeIyq3/bNK4MAAAZoRg From: "Khosravi, Hormuzd M" To: "Robert Haas" , , , , , , X-OriginalArrivalTime: 26 Oct 2004 17:29:14.0939 (UTC) FILETIME=[508698B0:01C4BB81] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: "Putzolu, David" Subject: [Forces-protocol] Conference Call details X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Hi Team, Here are the details for the conference call... Wednesday, October 27, 2004 8:00 AM US Pacific Time =20 Where: 8-356-2663, 916-356-2663, Bridge: 2, Passcode: 4629154 =20 =20 The agenda to follow shortly, Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 13:42:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27831 for ; Tue, 26 Oct 2004 13:42:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVZ4-0000Yp-9S for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 13:56:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVJz-0004Kk-T1; Tue, 26 Oct 2004 13:41:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMVGr-0003gF-GB for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 13:38:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27392 for ; Tue, 26 Oct 2004 13:38:08 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVUX-0000SS-Tj for forces-protocol@ietf.org; Tue, 26 Oct 2004 13:52:19 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9QHcH7Z002946; Tue, 26 Oct 2004 17:38:17 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9QHeLL7029506; Tue, 26 Oct 2004 17:41:11 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102610365016718 ; Tue, 26 Oct 2004 10:36:56 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Oct 2004 10:36:43 -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 Date: Tue, 26 Oct 2004 10:36:42 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0306B070@orsmsx408> Thread-Topic: Conference Call details Thread-Index: AcS7f3o4ECQg9kCnTLeIyq3/bNK4MAAAZoRgAAAksGA= From: "Khosravi, Hormuzd M" To: "Robert Haas" , , , , , , X-OriginalArrivalTime: 26 Oct 2004 17:36:43.0743 (UTC) FILETIME=[5C08A6F0:01C4BB82] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: "Putzolu, David" Subject: [Forces-protocol] RE: Conference Call details X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable =20 Here is the local call info... China Beijing 8529-8800 and then extension 1112 Massachusetts Hudson 978-553-2663 =20 Netherlands Schiphol-Rijk +312 0659 1696 England Swindon +44 1793 402663=20 =20 I couldn't find a number for Switzerland or Canada. But hopefully you guys can dial in to US,=20 cause we have done this in the past couple of times. Regards Hormuzd -----Original Message----- From: Khosravi, Hormuzd M=20 Sent: Tuesday, October 26, 2004 10:29 AM To: 'Robert Haas'; ram.gopal@nokia.com; avri@psg.com; donglg@mail.hzic.edu.cn; forces-protocol@ietf.org; wmwang@mail.hzic.edu.cn; hadi@znyx.com Cc: Putzolu, David Subject: Conference Call details Hi Team, Here are the details for the conference call... Wednesday, October 27, 2004 8:00 AM US Pacific Time =20 Where: 8-356-2663, 916-356-2663, Bridge: 2, Passcode: 4629154 =20 =20 The agenda to follow shortly, Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 14:42:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02277 for ; Tue, 26 Oct 2004 14:42:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMWVJ-0001vR-0v for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 14:57:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMWFm-0001yB-3g; Tue, 26 Oct 2004 14:41:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMW9P-00011y-JL for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 14:34:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01830 for ; Tue, 26 Oct 2004 14:34:29 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMWN7-0001nw-4p for forces-protocol@ietf.org; Tue, 26 Oct 2004 14:48:41 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9QIYf7Z005907; Tue, 26 Oct 2004 18:34:41 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9QIQcUd015750; Tue, 26 Oct 2004 18:27:17 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102611334919313 ; Tue, 26 Oct 2004 11:33:49 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Oct 2004 11:33:50 -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 Date: Tue, 26 Oct 2004 11:33:49 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0306B22B@orsmsx408> Thread-Topic: Conference Call (tomorrow 8:30 AM PST, join in earlier if possible) - Agenda Thread-Index: AcS7f3o4ECQg9kCnTLeIyq3/bNK4MAAAZoRgAAAksGAAAYJZ0A== From: "Khosravi, Hormuzd M" To: "Robert Haas" , , , , , , X-OriginalArrivalTime: 26 Oct 2004 18:33:50.0172 (UTC) FILETIME=[565839C0:01C4BB8A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Cc: "Putzolu, David" Subject: [Forces-protocol] Conference Call (tomorrow 8:30 AM PST, join in earlier if possible) - Agenda X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Here is the rough Agenda for the call tomorrow: PATH (context with Query msg) - 15 mins - Jamal to give brief intro Support for Multi LFB Addressing (multicast, etc) - 15 mins - Jamal/Weiming/Robert to give brief intro PACKET SUBSCRIBE - support for configuring packets to be redirected to the CE - 15 mins - Hormuzd to give brief intro *Any other outstanding issues with section 6 - 15 mins Let me know if I missed something, Thanks Hormuzd=20 -----Original Message----- From: Khosravi, Hormuzd M=20 =20 Here is the local call info... China Beijing 8529-8800 and then extension 1112 Massachusetts Hudson 978-553-2663 =20 Netherlands Schiphol-Rijk +312 0659 1696 England Swindon +44 1793 402663=20 =20 I couldn't find a number for Switzerland or Canada. But hopefully you guys can dial in to US,=20 cause we have done this in the past couple of times. Regards Hormuzd -----Original Message----- From: Khosravi, Hormuzd M=20 Hi Team, Here are the details for the conference call... Wednesday, October 27, 2004 8:00 AM US Pacific Time =20 Where: 8-356-2663, 916-356-2663, Bridge: 2, Passcode: 4629154 =20 =20 The agenda to follow shortly, Regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 14:53:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03000 for ; Tue, 26 Oct 2004 14:53:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMWfp-0002Bj-R7 for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 15:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMWQn-0004D5-6p; Tue, 26 Oct 2004 14:52:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMWLh-00035o-Nv for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 14:47:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02541 for ; Tue, 26 Oct 2004 14:47:11 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMWZO-00022B-HY for forces-protocol@ietf.org; Tue, 26 Oct 2004 15:01:24 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102611493882:42800 ; Tue, 26 Oct 2004 11:49:38 -0700 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0306B22B@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0306B22B@orsmsx408> Organization: Znyx Networks Message-Id: <1098816427.1029.63.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 26 Oct 2004 14:47:08 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/26/2004 11:49:39 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/26/2004 11:49:40 AM, Serialize complete at 10/26/2004 11:49:40 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, donglg@mail.hzic.edu.cn, forces-protocol@ietf.org, avri@psg.com, "Putzolu, David" , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] Re: Conference Call (tomorrow 8:30 AM PST, join in earlier if possible) - Agenda X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Hormuzd, Lets please spend a few minutes reviewing _all_ section six comments i posted. Preferably in the begining. The resolving of running over those issues will be easier over voice than email. cheers, jamal On Tue, 2004-10-26 at 14:33, Khosravi, Hormuzd M wrote: > Here is the rough Agenda for the call tomorrow: > > PATH (context with Query msg) - 15 mins - Jamal to give brief intro > > Support for Multi LFB Addressing (multicast, etc) - 15 mins - > Jamal/Weiming/Robert to give brief intro > > PACKET SUBSCRIBE - support for configuring packets to be redirected to > the CE - 15 mins - Hormuzd to give brief intro > > *Any other outstanding issues with section 6 - 15 mins > > > Let me know if I missed something, > > Thanks > Hormuzd > > -----Original Message----- > From: Khosravi, Hormuzd M > > Here is the local call info... > > China Beijing 8529-8800 and then extension 1112 > > Massachusetts Hudson 978-553-2663 > > Netherlands Schiphol-Rijk +312 0659 1696 > > England Swindon +44 1793 402663 > > > I couldn't find a number for Switzerland or Canada. > > But hopefully you guys can dial in to US, > cause we have done this in the past couple of times. > > Regards > Hormuzd > > -----Original Message----- > From: Khosravi, Hormuzd M > > Hi Team, > > Here are the details for the conference call... > > > Wednesday, October 27, 2004 8:00 AM US Pacific Time > > Where: 8-356-2663, 916-356-2663, Bridge: 2, Passcode: 4629154 > > > The agenda to follow shortly, > > Regards > Hormuzd > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Tue Oct 26 15:08:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04419 for ; Tue, 26 Oct 2004 15:08:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMWu8-0002ZT-Ct for forces-protocol-web-archive@ietf.org; Tue, 26 Oct 2004 15:22:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMWXo-0005P4-HO; Tue, 26 Oct 2004 14:59:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMWR9-0004Py-67 for forces-protocol@megatron.ietf.org; Tue, 26 Oct 2004 14:52:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02927 for ; Tue, 26 Oct 2004 14:52:49 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMWeq-0002AE-4E for forces-protocol@ietf.org; Tue, 26 Oct 2004 15:07:01 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9QIpvR5009352; Tue, 26 Oct 2004 18:51:57 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9QIjaUJ030470; Tue, 26 Oct 2004 18:45:37 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102611521223111 ; Tue, 26 Oct 2004 11:52:12 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Oct 2004 11:52:12 -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 Date: Tue, 26 Oct 2004 11:52:10 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0306B2A1@orsmsx408> Thread-Topic: Conference Call (tomorrow 8:30 AM PST, join in earlier ifpossible) - Agenda Thread-Index: AcS7jDVKiD1BMlBHQU67Zzx+AgHLbQAABr9Q From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 26 Oct 2004 18:52:12.0609 (UTC) FILETIME=[E772C310:01C4BB8C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, donglg@mail.hzic.edu.cn, forces-protocol@ietf.org, avri@psg.com, "Putzolu, David" , wmwang@mail.hzic.edu.cn, Robert Haas Subject: [Forces-protocol] RE: Conference Call (tomorrow 8:30 AM PST, join in earlier ifpossible) - Agenda X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Jamal, I am afraid, if we start with this we might not get to other topics. So I have kept sometime (15 mins) for it towards the end. I believe we will making faster progress addressing specific topics and most of your comments might be resolved, by the time we get to the end. BTW, did you look at my response on 6.3 ? There isn't much to discuss there expect the Packet Subscribe, which I have put on the agenda. Regards Hormuzd=20 -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Tuesday, October 26, 2004 11:47 AM To: Khosravi, Hormuzd M Cc: Robert Haas; ram.gopal@nokia.com; avri@psg.com; donglg@mail.hzic.edu.cn; forces-protocol@ietf.org; wmwang@mail.hzic.edu.cn; Putzolu, David Subject: Re: Conference Call (tomorrow 8:30 AM PST, join in earlier ifpossible) - Agenda Hormuzd, Lets please spend a few minutes reviewing _all_ section six comments i posted. Preferably in the begining. The resolving of running over those issues will be easier over voice than email. cheers, jamal On Tue, 2004-10-26 at 14:33, Khosravi, Hormuzd M wrote: > Here is the rough Agenda for the call tomorrow: >=20 > PATH (context with Query msg) - 15 mins - Jamal to give brief intro >=20 > Support for Multi LFB Addressing (multicast, etc) - 15 mins - > Jamal/Weiming/Robert to give brief intro >=20 > PACKET SUBSCRIBE - support for configuring packets to be redirected to > the CE - 15 mins - Hormuzd to give brief intro >=20 > *Any other outstanding issues with section 6 - 15 mins >=20 >=20 > Let me know if I missed something, >=20 > Thanks > Hormuzd=20 >=20 > -----Original Message----- > From: Khosravi, Hormuzd M=20 > =20 > Here is the local call info... >=20 > China Beijing 8529-8800 and then extension 1112 >=20 > Massachusetts Hudson 978-553-2663 > =20 > Netherlands Schiphol-Rijk +312 0659 1696 >=20 > England Swindon +44 1793 402663=20 > =20 >=20 > I couldn't find a number for Switzerland or Canada. >=20 > But hopefully you guys can dial in to US,=20 > cause we have done this in the past couple of times. >=20 > Regards > Hormuzd >=20 > -----Original Message----- > From: Khosravi, Hormuzd M=20 >=20 > Hi Team, >=20 > Here are the details for the conference call... >=20 >=20 > Wednesday, October 27, 2004 8:00 AM US Pacific Time =20 >=20 > Where: 8-356-2663, 916-356-2663, Bridge: 2, Passcode: 4629154 =20 > =20 >=20 > The agenda to follow shortly, >=20 > Regards > Hormuzd >=20 _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 27 03:24:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12476 for ; Wed, 27 Oct 2004 03:24:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMiOc-0007Le-Vu for forces-protocol-web-archive@ietf.org; Wed, 27 Oct 2004 03:39:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMi9t-0005e8-5H; Wed, 27 Oct 2004 03:23:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMi7h-00054Z-89 for forces-protocol@megatron.ietf.org; Wed, 27 Oct 2004 03:21:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12148 for ; Wed, 27 Oct 2004 03:21:31 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMiLV-0007GZ-MA for forces-protocol@ietf.org; Wed, 27 Oct 2004 03:35:50 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9R7Or2A031588; Wed, 27 Oct 2004 07:24:54 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9R7EAEo028097; Wed, 27 Oct 2004 07:14:12 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102700205111487 ; Wed, 27 Oct 2004 00:20:51 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Oct 2004 00:20:50 -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 Date: Wed, 27 Oct 2004 00:20:50 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0257923F@orsmsx408> Thread-Topic: Feedback: Section 6.2 Thread-Index: AcS5PhA7hDTxbKyLSSWBKJvkRbWkbACs7h0Q From: "Khosravi, Hormuzd M" To: , , "Robert Haas" X-OriginalArrivalTime: 27 Oct 2004 07:20:50.0958 (UTC) FILETIME=[7CDEE2E0:01C4BBF5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Weiming Wang , Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] RE: Feedback: Section 6.2 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Jamal, It seems like your comments on 6.2 are colliding with the comments that Robert had sent, lets discuss this in the call (last 15 mins on agenda). I am fine either way, Regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Saturday, October 23, 2004 1:23 PM To: avri@psg.com Cc: Robert Haas; forces-protocol@ietf.org; Ligang Dong; ram.gopal@nokia.com; Khosravi, Hormuzd M; Weiming Wang Subject: Feedback: Section 6.2 - Section 6.2.1 +--- T =3D Operation =3D SHOW | +-- FE NAME What is the point of having this one operation called SHOW just for this? Is it an operation at all given its position in the hierachy? PENAME may have been a better name. In the diagram:=20 + LFB Instance ID and LFB Class ID=20 should those just be set to 0x1? We already know thats where they are going. + Type =3D operation, using the word "type" is confusing since it is = also used in the main header. I dont think we can avoid using the word type in TLVs; my suggestion is we consider changing the main header type to=20 "command". Thoughts? It is a command after all. + comment on SHOW applies here as well + "HBI will be exchanged with the CE using this LFB" ??? -6.2.2 Association Setup Response Message In the diagram:=20 + LFB Instance ID and LFB Class ID=20 should those just be set to 0x1? We already know thats where they are going. + =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D operation Show | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ FE Object LFB (optional) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What is that? + "HBI will be exchanged with the CE using this LFB" ??? + Type =3D T.reason ? This brings up that we need the following speacial TLVs. FORCES_REASON, FORCES_RESULT, FORCES_NAME. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 27 03:25:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12500 for ; Wed, 27 Oct 2004 03:25:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMiOz-0007Lr-S5 for forces-protocol-web-archive@ietf.org; Wed, 27 Oct 2004 03:39:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMi9t-0005eD-FH; Wed, 27 Oct 2004 03:23:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMi7h-00054a-AG for forces-protocol@megatron.ietf.org; Wed, 27 Oct 2004 03:21:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12146 for ; Wed, 27 Oct 2004 03:21:31 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMiLV-0007Ga-KU for forces-protocol@ietf.org; Wed, 27 Oct 2004 03:35:50 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9R7Kanx001483; Wed, 27 Oct 2004 07:20:36 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9R7EBEm028099; Wed, 27 Oct 2004 07:14:11 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102700204914628 ; Wed, 27 Oct 2004 00:20:49 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Oct 2004 00:20:49 -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 Subject: RE: [Forces-protocol] Feedback: Section 6.4 Date: Wed, 27 Oct 2004 00:20:03 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E0257923E@orsmsx408> Thread-Topic: [Forces-protocol] Feedback: Section 6.4 Thread-Index: AcS7SyD1af3uDwsWTVK5oYcJhVT4DQAqT6Wg From: "Khosravi, Hormuzd M" To: , "Wang,Weiming" X-OriginalArrivalTime: 27 Oct 2004 07:20:49.0645 (UTC) FILETIME=[7C1689D0:01C4BBF5] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Joel M. Halpern" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Jamal, Weiming, I finally got the chance to read some of these emails...sorry for not responding earlier. In general, we will need the concept of PATH atleast for Query messages (GET), but I don't believe from any of the emails that I have read so far that there was any concensus on what this would look like. Jamal has a reasonable proposal which needs more discussion and refinement. Some specific comments on Jamal's proposal so far... Where is the Table ID ? Is this part of the path IDs? I don't believe we need any Flags in the path, this is similar to the comment that Joel had as well. Also, for Config msgs, I think the path can be part of the data itself, but lets discuss this further...cause I am not sure if you guys agree with this, Talk to you soon, regards Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Tuesday, October 26, 2004 3:59 AM To: Wang,Weiming Cc: Joel M. Halpern; Khosravi, Hormuzd M; ram.gopal@nokia.com; forces-protocol@ietf.org; avri@psg.com; Ligang Dong; Robert Haas Subject: Re: [Forces-protocol] Feedback: Section 6.4 On Tue, 2004-10-26 at 00:01, Wang,Weiming wrote: > I have no doubt to agree with this. Just need to calrify that a path is more > than 32 bits long, or there will be not enough bits. >=20 Aha! I think i see where the misunderstanding is;-> Weiming sees either a path like 6 or 1,2,3,4 as represented by _one_ _fixed_ sized element. In which case you have to find a way to pack both representations into that fixed size element. The suggested "path" representation is in fact _variable_. >From the notes i sent earlier to you, the suggestion is: ---- A possible path-data layout.=20 ---------------------------- OPER_TLV : =3D PATH-DATA :=3D flags IDcount [BLOCK_OR_KEY_NOTATION] [DATA] The operational TLV contains an opcode in the T part. Its V contains the PATH-DATA. Opcodes discussed so far: * SET (create, modify or both depending on PATH-DATA flags} * DEL (remove an existing entity specified by PATH-DATA } * GET (Access a entity specified in PATH-DATA } * EV_S (subscribe to an event defined in PATH-DATA } * EV_U (unsubscribe to an event defined in PATH-DATA } -> IDs :=3D a series of 32bit IDs (whose size is given by IDcount) defining the path. -> flags are used to further refine the operation to be applied on the ID_TLV. -> BLOCK_OR_KEY_NOTATION :=3D optional different BLOCK or KEY extension defined in section 4.2 and 4.3 of [1] -> DATA : =3D Optional variable sized data dependent on PATH and applied operations (eg GET will not have DATA). ------- Well read the rest of the doc; and for completion the notes posted by Steve/Zsolt. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 27 09:35:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03588 for ; Wed, 27 Oct 2004 09:35:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMoBF-0005MP-7z for forces-protocol-web-archive@ietf.org; Wed, 27 Oct 2004 09:49:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnsz-0003Am-24; Wed, 27 Oct 2004 09:30:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMnqx-00019B-MP for forces-protocol@megatron.ietf.org; Wed, 27 Oct 2004 09:28:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03257 for ; Wed, 27 Oct 2004 09:28:37 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMo4o-0005GQ-F4 for forces-protocol@ietf.org; Wed, 27 Oct 2004 09:43:00 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102706305723:44169 ; Wed, 27 Oct 2004 06:30:57 -0700 Subject: RE: [Forces-protocol] Feedback: Section 6.4 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0257923E@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E0257923E@orsmsx408> Organization: Znyx Networks Message-Id: <1098883706.1029.11.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Oct 2004 09:28:27 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/27/2004 06:30:57 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/27/2004 06:31:06 AM, Serialize complete at 10/27/2004 06:31:06 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, avri@psg.com, "Joel M. Halpern" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Folks, The PATH is needed for _everything_ thats interfacing to any LFB attributes. Think of it as an SNMP OID - you need that _everytime_ To get to where the table etc fits in, please read the two docs i posted to speed up the discussion; Heres a cutnpaste from one of those docs: path-data ---------- The layout is still under discussion and so is left out from this text. Each accessible attribute within an LFB is expected to have a 32 bit identifier. The path-data will have a map derived from the static class attribute IDs as well as those derived from variable content such table indices (derived at runtime). Below is an illustration of a complex example and how the different attributes could be accessed. Assume LFB Class A. It contains two Arrays, B, and C (assigned identifiers 1 and 2) A also contains a structure of type Stoo with a human name F. F is assigned ID 3. A also contains two attributes, D and E assigned identifiers 4 and 5. Array B is an array, indexed as a table, whose contents are int32s. Array C is an array, indexed as a table, whose contents are a structure named Star. Stoo type structures contain elements X and Y, each characters, assigned identifiers 1 and 2. Star contains An element N (a sting), assigned identifier 1, and an array Arr, assigned identifier 2, indexed as a table, containing int32s. To reference entities within an LFB instance of Class A, selectors are as follows: 1, meaning the full array B 3, meaning the full structure named F. 2, 7 meaning the full structure in the seventh entry of the array C. 4 means the attribute D 2, 8, 2, 9 meaning the 9th number in the array in the structure in the eigth slot of the array C. Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct type definition. Since the model team has asserted that class definitions can only change (version) in ways that leave existing references intact and usable it means backward compatibility is supported. ---------------------- cheers, jamal On Wed, 2004-10-27 at 03:20, Khosravi, Hormuzd M wrote: > Jamal, Weiming, > > I finally got the chance to read some of these emails...sorry for not > responding earlier. In general, we will need the concept of PATH atleast > for Query messages (GET), but I don't believe from any of the emails > that I have read so far that there was any concensus on what this would > look like. Jamal has a reasonable proposal which needs more discussion > and refinement. > > Some specific comments on Jamal's proposal so far... > > Where is the Table ID ? Is this part of the path IDs? > I don't believe we need any Flags in the path, this is similar to the > comment that Joel had as well. > Also, for Config msgs, I think the path can be part of the data itself, > but lets discuss this further...cause I am not sure if you guys agree > with this, > > Talk to you soon, > > regards > Hormuzd > > -----Original Message----- > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > Sent: Tuesday, October 26, 2004 3:59 AM > To: Wang,Weiming > Cc: Joel M. Halpern; Khosravi, Hormuzd M; ram.gopal@nokia.com; > forces-protocol@ietf.org; avri@psg.com; Ligang Dong; Robert Haas > Subject: Re: [Forces-protocol] Feedback: Section 6.4 > > On Tue, 2004-10-26 at 00:01, Wang,Weiming wrote: > > > > I have no doubt to agree with this. Just need to calrify that a path > is more > > than 32 bits long, or there will be not enough bits. > > > > Aha! I think i see where the misunderstanding is;-> > Weiming sees either a path like 6 or 1,2,3,4 as represented by _one_ > _fixed_ sized element. In which case you have to find a way to pack both > representations into that fixed size element. > > The suggested "path" representation is in fact _variable_. > >From the notes i sent earlier to you, the suggestion is: > > ---- > A possible path-data layout. > ---------------------------- > > OPER_TLV : = > PATH-DATA := flags IDcount [BLOCK_OR_KEY_NOTATION] [DATA] > The operational TLV contains an opcode in the T part. Its V > contains the PATH-DATA. > Opcodes discussed so far: > * SET (create, modify or both depending on PATH-DATA flags} > * DEL (remove an existing entity specified by PATH-DATA } > * GET (Access a entity specified in PATH-DATA } > * EV_S (subscribe to an event defined in PATH-DATA } > * EV_U (unsubscribe to an event defined in PATH-DATA } > -> IDs := a series of 32bit IDs (whose size is given by IDcount) > defining the path. > -> flags are used to further refine the operation to be applied > on the ID_TLV. > -> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension > defined in section 4.2 and 4.3 of [1] > -> DATA : = Optional variable sized data dependent on PATH > and applied operations (eg GET will not have DATA). > > ------- > > Well read the rest of the doc; and for completion the notes posted by > Steve/Zsolt. > > cheers, > jamal > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 27 10:43:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10019 for ; Wed, 27 Oct 2004 10:43:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMpFh-0006qA-Co for forces-protocol-web-archive@ietf.org; Wed, 27 Oct 2004 10:58:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMou9-0006lm-QM; Wed, 27 Oct 2004 10:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMojw-0003Hl-Kx for forces-protocol@megatron.ietf.org; Wed, 27 Oct 2004 10:25:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08133 for ; Wed, 27 Oct 2004 10:25:26 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMoxX-0006H5-0j for forces-protocol@ietf.org; Wed, 27 Oct 2004 10:39:49 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Wed, 27 Oct 2004 22:45:19 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Wed, 27 Oct 2004 22:20:30 +0800 Message-ID: <0d0001c4bc30$66067d90$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: , "Khosravi, Hormuzd M" References: <468F3FDA28AA87429AD807992E22D07E0257923E@orsmsx408> <1098883706.1029.11.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Feedback: Section 6.4 Date: Wed, 27 Oct 2004 22:22:31 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Joel M. Halpern" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Jamal,Hormuzd as well, ----- Original Message ----- From: "Jamal Hadi Salim" Subject: RE: [Forces-protocol] Feedback: Section 6.4 > Folks, > > The PATH is needed for _everything_ thats interfacing to any LFB > attributes. [Weiming] I agree you say that path is needed for every attributes in LFB. My opinion is the path is composed of at least two parts: The ID to describe which attribte it is --- this I call it "Attribute ID", (and Hormuzd called "Table ID"?) The Index ID to describe which entry inside the attribute IF THE ATTRIBUTE IS A TABLE --- this we usualy called "table Index". Then, my opinion is (I think Hormuzd also think so) the 'Attribute ID' part should appear in our protocol layer, but the Index ID will not appear in the protocol layer. Instead, it should appear in the data field. Why? because, 1) Not every attribute is a table, therefore not every attribute need such table index. But 'Attribute ID' is always needed. 2) Even in the table case, to put the table index in the data field means to let the LFB definer to have much flexibility to define the index - the length of the index, the format, etc, rathan than to be uniformly defined for all LFBs by our protocol. 3) In this way, we can also easily implement all the operations as you mentioned below. 4) Also note that the 'Attribute ID'is explicitly defined in XML definition of LFBs(e.g. ID=6 in your noop.xml), while the table index will not appear in the xml, that means the table index is a kind of data while the attribute ID is a specific field, from the protocol viewpoint. > Think of it as an SNMP OID - you need that _everytime_ > To get to where the table etc fits in, please read the two docs i posted > to speed up the discussion; > > Heres a cutnpaste from one of those docs: > > path-data > ---------- > The layout is still under discussion and so is left out from this text. > > Each accessible attribute within an LFB is expected to have a 32 bit > identifier. Yes. > > The path-data will have a map derived from the static class attribute > IDs as well as those derived from variable content such table indices > (derived at runtime). Exactly. > > Below is an illustration of a complex example and how the different > attributes could be accessed. > > Assume LFB Class A. > It contains two Arrays, B, and C (assigned identifiers 1 and 2) > A also contains a structure of type Stoo with a human name F. > F is assigned ID 3. > A also contains two attributes, D and E assigned identifiers 4 and 5. > Array B is an array, indexed as a table, whose contents are int32s. > Array C is an array, indexed as a table, whose contents are a structure > named Star. > Stoo type structures contain elements X and Y, each characters, > assigned identifiers 1 and 2. > Star contains An element N (a sting), assigned identifier 1, and an > array > Arr, assigned identifier 2, indexed as a table, containing int32s. > > To reference entities within an LFB instance of Class A, selectors > are as follows: > > 1, meaning the full array B Agreed. Note here 1 is as I mean 'Attribute ID' > 3, meaning the full structure named F. Agreed. 3 is another attribute ID. > 2, 7 meaning the full structure in the seventh entry of the array C. The protocol only pay attention to the 2 ID, while leaving the 7 being inluded in the data field. > 4 means the attribute D > 2, 8, 2, 9 meaning the 9th number in the array in the structure in the The protocol layer only pay attention to the 2 ID, leaving the 8,2,9 in the data field. Whatever format the LFB model may use to define the path. Cheers, Weiming > eigth slot of the array C. > Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct > type definition. > Since the model team has asserted that class definitions can > only change (version) in ways that leave existing references intact > and usable it means backward compatibility is supported. > > ---------------------- > > > cheers, > jamal > > On Wed, 2004-10-27 at 03:20, Khosravi, Hormuzd M wrote: > > Jamal, Weiming, > > > > I finally got the chance to read some of these emails...sorry for not > > responding earlier. In general, we will need the concept of PATH atleast > > for Query messages (GET), but I don't believe from any of the emails > > that I have read so far that there was any concensus on what this would > > look like. Jamal has a reasonable proposal which needs more discussion > > and refinement. > > > > Some specific comments on Jamal's proposal so far... > > > > Where is the Table ID ? Is this part of the path IDs? > > I don't believe we need any Flags in the path, this is similar to the > > comment that Joel had as well. > > Also, for Config msgs, I think the path can be part of the data itself, > > but lets discuss this further...cause I am not sure if you guys agree > > with this, > > > > Talk to you soon, > > > > regards > > Hormuzd > > > > -----Original Message----- > > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > Sent: Tuesday, October 26, 2004 3:59 AM > > To: Wang,Weiming > > Cc: Joel M. Halpern; Khosravi, Hormuzd M; ram.gopal@nokia.com; > > forces-protocol@ietf.org; avri@psg.com; Ligang Dong; Robert Haas > > Subject: Re: [Forces-protocol] Feedback: Section 6.4 > > > > On Tue, 2004-10-26 at 00:01, Wang,Weiming wrote: > > > > > > > I have no doubt to agree with this. Just need to calrify that a path > > is more > > > than 32 bits long, or there will be not enough bits. > > > > > > > Aha! I think i see where the misunderstanding is;-> > > Weiming sees either a path like 6 or 1,2,3,4 as represented by _one_ > > _fixed_ sized element. In which case you have to find a way to pack both > > representations into that fixed size element. > > > > The suggested "path" representation is in fact _variable_. > > >From the notes i sent earlier to you, the suggestion is: > > > > ---- > > A possible path-data layout. > > ---------------------------- > > > > OPER_TLV : = > > PATH-DATA := flags IDcount [BLOCK_OR_KEY_NOTATION] [DATA] > > The operational TLV contains an opcode in the T part. Its V > > contains the PATH-DATA. > > Opcodes discussed so far: > > * SET (create, modify or both depending on PATH-DATA flags} > > * DEL (remove an existing entity specified by PATH-DATA } > > * GET (Access a entity specified in PATH-DATA } > > * EV_S (subscribe to an event defined in PATH-DATA } > > * EV_U (unsubscribe to an event defined in PATH-DATA } > > -> IDs := a series of 32bit IDs (whose size is given by IDcount) > > defining the path. > > -> flags are used to further refine the operation to be applied > > on the ID_TLV. > > -> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension > > defined in section 4.2 and 4.3 of [1] > > -> DATA : = Optional variable sized data dependent on PATH > > and applied operations (eg GET will not have DATA). > > > > ------- > > > > Well read the rest of the doc; and for completion the notes posted by > > Steve/Zsolt. > > > > cheers, > > jamal > > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 27 10:51:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10774 for ; Wed, 27 Oct 2004 10:51:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMpMb-00074M-MP for forces-protocol-web-archive@ietf.org; Wed, 27 Oct 2004 11:05:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMp6V-0001jh-Uf; Wed, 27 Oct 2004 10:48:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMoyE-0008Eu-9Q for forces-protocol@megatron.ietf.org; Wed, 27 Oct 2004 10:40:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09612 for ; Wed, 27 Oct 2004 10:40:11 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMpC6-0006iW-H8 for forces-protocol@ietf.org; Wed, 27 Oct 2004 10:54:35 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102707423927:44323 ; Wed, 27 Oct 2004 07:42:39 -0700 Subject: Re: [Forces-protocol] Feedback: Section 6.4 From: Jamal Hadi Salim To: "Wang,Weiming" In-Reply-To: <0d0001c4bc30$66067d90$845c21d2@Necom.hzic.edu.cn> References: <468F3FDA28AA87429AD807992E22D07E0257923E@orsmsx408> <1098883706.1029.11.camel@jzny.localdomain> <0d0001c4bc30$66067d90$845c21d2@Necom.hzic.edu.cn> Organization: Znyx Networks Message-Id: <1098888008.1029.33.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Oct 2004 10:40:09 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/27/2004 07:42:39 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/27/2004 07:42:41 AM, Serialize complete at 10/27/2004 07:42:41 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Joel M. Halpern" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Content-Transfer-Encoding: 7bit Weiming, Yes, the two are different in the sense that one is defined at static xml definition time and the other created at runtime. However, if you give me a series of 32 bits defining a path which includes table Ids and rows and cells, i can tell you 100% of the time where that path will lead. There is _zero_ ambiguity. Note there are circumstances where it may make sense like in the case of block operations (eg operate on table indices 100-200) - this is probably your main point (as mentioned in your point #3). This does not make the block operation part of the "data" like you said. All it says is "this is how you get to the data". cheers, jamal On Wed, 2004-10-27 at 10:22, Wang,Weiming wrote: > Jamal,Hormuzd as well, > > ----- Original Message ----- > From: "Jamal Hadi Salim" > Subject: RE: [Forces-protocol] Feedback: Section 6.4 > > > > Folks, > > > > The PATH is needed for _everything_ thats interfacing to any LFB > > attributes. > [Weiming] I agree you say that path is needed for every attributes in LFB. > My opinion is the path is composed of at least two parts: > The ID to describe which attribte it is --- this I call it "Attribute ID", (and > Hormuzd called "Table ID"?) > The Index ID to describe which entry inside the attribute IF THE ATTRIBUTE IS A > TABLE --- this we usualy called "table Index". > > Then, my opinion is (I think Hormuzd also think so) the 'Attribute ID' part > should appear in our protocol layer, but the Index ID will not appear in the > protocol layer. Instead, it should appear in the data field. Why? because, > > 1) Not every attribute is a table, therefore not every attribute need such table > index. But 'Attribute ID' is always needed. > > 2) Even in the table case, to put the table index in the data field means to let > the LFB definer to have much flexibility to define the index - the length of the > index, the format, etc, rathan than to be uniformly defined for all LFBs by our > protocol. > > 3) In this way, we can also easily implement all the operations as you mentioned > below. > > 4) Also note that the 'Attribute ID'is explicitly defined in XML definition of > LFBs(e.g. ID=6 in your noop.xml), while the table index will not appear in the > xml, that means the table index is a kind of data while the attribute ID is a > specific field, from the protocol viewpoint. > > > > Think of it as an SNMP OID - you need that _everytime_ > > To get to where the table etc fits in, please read the two docs i posted > > to speed up the discussion; > > > > Heres a cutnpaste from one of those docs: > > > > path-data > > ---------- > > The layout is still under discussion and so is left out from this text. > > > > Each accessible attribute within an LFB is expected to have a 32 bit > > identifier. > Yes. > > > > The path-data will have a map derived from the static class attribute > > IDs as well as those derived from variable content such table indices > > (derived at runtime). > Exactly. > > > > > Below is an illustration of a complex example and how the different > > attributes could be accessed. > > > > Assume LFB Class A. > > It contains two Arrays, B, and C (assigned identifiers 1 and 2) > > A also contains a structure of type Stoo with a human name F. > > F is assigned ID 3. > > A also contains two attributes, D and E assigned identifiers 4 and 5. > > Array B is an array, indexed as a table, whose contents are int32s. > > Array C is an array, indexed as a table, whose contents are a structure > > named Star. > > Stoo type structures contain elements X and Y, each characters, > > assigned identifiers 1 and 2. > > Star contains An element N (a sting), assigned identifier 1, and an > > array > > Arr, assigned identifier 2, indexed as a table, containing int32s. > > > > To reference entities within an LFB instance of Class A, selectors > > are as follows: > > > > 1, meaning the full array B > Agreed. Note here 1 is as I mean 'Attribute ID' > > > 3, meaning the full structure named F. > Agreed. 3 is another attribute ID. > > > 2, 7 meaning the full structure in the seventh entry of the array C. > The protocol only pay attention to the 2 ID, while leaving the 7 being inluded > in the data field. > > > 4 means the attribute D > > 2, 8, 2, 9 meaning the 9th number in the array in the structure in the > The protocol layer only pay attention to the 2 ID, leaving the 8,2,9 in the data > field. Whatever format the LFB model may use to define the path. > > Cheers, > Weiming > > > eigth slot of the array C. > > Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct > > type definition. > > Since the model team has asserted that class definitions can > > only change (version) in ways that leave existing references intact > > and usable it means backward compatibility is supported. > > > > ---------------------- > > > > > > cheers, > > jamal > > > > On Wed, 2004-10-27 at 03:20, Khosravi, Hormuzd M wrote: > > > Jamal, Weiming, > > > > > > I finally got the chance to read some of these emails...sorry for not > > > responding earlier. In general, we will need the concept of PATH atleast > > > for Query messages (GET), but I don't believe from any of the emails > > > that I have read so far that there was any concensus on what this would > > > look like. Jamal has a reasonable proposal which needs more discussion > > > and refinement. > > > > > > Some specific comments on Jamal's proposal so far... > > > > > > Where is the Table ID ? Is this part of the path IDs? > > > I don't believe we need any Flags in the path, this is similar to the > > > comment that Joel had as well. > > > Also, for Config msgs, I think the path can be part of the data itself, > > > but lets discuss this further...cause I am not sure if you guys agree > > > with this, > > > > > > Talk to you soon, > > > > > > regards > > > Hormuzd > > > > > > -----Original Message----- > > > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > Sent: Tuesday, October 26, 2004 3:59 AM > > > To: Wang,Weiming > > > Cc: Joel M. Halpern; Khosravi, Hormuzd M; ram.gopal@nokia.com; > > > forces-protocol@ietf.org; avri@psg.com; Ligang Dong; Robert Haas > > > Subject: Re: [Forces-protocol] Feedback: Section 6.4 > > > > > > On Tue, 2004-10-26 at 00:01, Wang,Weiming wrote: > > > > > > > > > > I have no doubt to agree with this. Just need to calrify that a path > > > is more > > > > than 32 bits long, or there will be not enough bits. > > > > > > > > > > Aha! I think i see where the misunderstanding is;-> > > > Weiming sees either a path like 6 or 1,2,3,4 as represented by _one_ > > > _fixed_ sized element. In which case you have to find a way to pack both > > > representations into that fixed size element. > > > > > > The suggested "path" representation is in fact _variable_. > > > >From the notes i sent earlier to you, the suggestion is: > > > > > > ---- > > > A possible path-data layout. > > > ---------------------------- > > > > > > OPER_TLV : = > > > PATH-DATA := flags IDcount [BLOCK_OR_KEY_NOTATION] [DATA] > > > The operational TLV contains an opcode in the T part. Its V > > > contains the PATH-DATA. > > > Opcodes discussed so far: > > > * SET (create, modify or both depending on PATH-DATA flags} > > > * DEL (remove an existing entity specified by PATH-DATA } > > > * GET (Access a entity specified in PATH-DATA } > > > * EV_S (subscribe to an event defined in PATH-DATA } > > > * EV_U (unsubscribe to an event defined in PATH-DATA } > > > -> IDs := a series of 32bit IDs (whose size is given by IDcount) > > > defining the path. > > > -> flags are used to further refine the operation to be applied > > > on the ID_TLV. > > > -> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension > > > defined in section 4.2 and 4.3 of [1] > > > -> DATA : = Optional variable sized data dependent on PATH > > > and applied operations (eg GET will not have DATA). > > > > > > ------- > > > > > > Well read the rest of the doc; and for completion the notes posted by > > > Steve/Zsolt. > > > > > > cheers, > > > jamal > > > > > > > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 27 11:32:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15765 for ; Wed, 27 Oct 2004 11:32:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMq0S-0008MR-7G for forces-protocol-web-archive@ietf.org; Wed, 27 Oct 2004 11:46:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMpWi-0002vi-Ny; Wed, 27 Oct 2004 11:15:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMpRA-0000Ge-4Y for forces-protocol@megatron.ietf.org; Wed, 27 Oct 2004 11:10:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12724 for ; Wed, 27 Oct 2004 11:10:05 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CMpev-0007Vl-Su for forces-protocol@ietf.org; Wed, 27 Oct 2004 11:24:29 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 99432.341813895; Wed, 27 Oct 2004 23:30:15 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Wed, 27 Oct 2004 23:05:26 +0800 Message-ID: <0d4701c4bc36$ac639600$845c21d2@Necom.hzic.edu.cn> From: "Wang,Weiming" To: References: <468F3FDA28AA87429AD807992E22D07E0257923E@orsmsx408> <1098883706.1029.11.camel@jzny.localdomain> <0d0001c4bc30$66067d90$845c21d2@Necom.hzic.edu.cn> <1098888008.1029.33.camel@jzny.localdomain> Subject: Re: [Forces-protocol] Feedback: Section 6.4 Date: Wed, 27 Oct 2004 23:07:27 +0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Joel M. Halpern" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: [Forces-protocol] Feedback: Section 6.4 > > Weiming, > > Yes, the two are different in the sense that one is defined at static > xml definition time and the other created at runtime. However, > if you give me a series of 32 bits defining a path which includes table > Ids and rows and cells, i can tell you 100% of the time where that path > will lead. There is _zero_ ambiguity. We can just let the first fields of the data being IDs for table index, which is really identical with the one whole path, but leaving more flexibiligy for every different LFBs to define the IDs. This means: Op TLV = AttributeID (or you may call it as : Path , but the path here is only an Attribute type ID). Data := <...> In this way, if the LFB needs the indexing IDs, it will be there, if not, there will be none. Thanks. Weiming > > Note there are circumstances where it may make sense like in the case > of block operations (eg operate on table indices 100-200) - this is > probably your main point (as mentioned in your point #3). This does not > make the block operation part of the "data" like you said. All it says > is "this is how you get to the data". > > > cheers, > jamal > > On Wed, 2004-10-27 at 10:22, Wang,Weiming wrote: > > Jamal,Hormuzd as well, > > > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > Subject: RE: [Forces-protocol] Feedback: Section 6.4 > > > > > > > Folks, > > > > > > The PATH is needed for _everything_ thats interfacing to any LFB > > > attributes. > > [Weiming] I agree you say that path is needed for every attributes in LFB. > > My opinion is the path is composed of at least two parts: > > The ID to describe which attribte it is --- this I call it "Attribute ID", (and > > Hormuzd called "Table ID"?) > > The Index ID to describe which entry inside the attribute IF THE ATTRIBUTE IS A > > TABLE --- this we usualy called "table Index". > > > > Then, my opinion is (I think Hormuzd also think so) the 'Attribute ID' part > > should appear in our protocol layer, but the Index ID will not appear in the > > protocol layer. Instead, it should appear in the data field. Why? because, > > > > 1) Not every attribute is a table, therefore not every attribute need such table > > index. But 'Attribute ID' is always needed. > > > > 2) Even in the table case, to put the table index in the data field means to let > > the LFB definer to have much flexibility to define the index - the length of the > > index, the format, etc, rathan than to be uniformly defined for all LFBs by our > > protocol. > > > > 3) In this way, we can also easily implement all the operations as you mentioned > > below. > > > > 4) Also note that the 'Attribute ID'is explicitly defined in XML definition of > > LFBs(e.g. ID=6 in your noop.xml), while the table index will not appear in the > > xml, that means the table index is a kind of data while the attribute ID is a > > specific field, from the protocol viewpoint. > > > > > > > Think of it as an SNMP OID - you need that _everytime_ > > > To get to where the table etc fits in, please read the two docs i posted > > > to speed up the discussion; > > > > > > Heres a cutnpaste from one of those docs: > > > > > > path-data > > > ---------- > > > The layout is still under discussion and so is left out from this text. > > > > > > Each accessible attribute within an LFB is expected to have a 32 bit > > > identifier. > > Yes. > > > > > > The path-data will have a map derived from the static class attribute > > > IDs as well as those derived from variable content such table indices > > > (derived at runtime). > > Exactly. > > > > > > > > Below is an illustration of a complex example and how the different > > > attributes could be accessed. > > > > > > Assume LFB Class A. > > > It contains two Arrays, B, and C (assigned identifiers 1 and 2) > > > A also contains a structure of type Stoo with a human name F. > > > F is assigned ID 3. > > > A also contains two attributes, D and E assigned identifiers 4 and 5. > > > Array B is an array, indexed as a table, whose contents are int32s. > > > Array C is an array, indexed as a table, whose contents are a structure > > > named Star. > > > Stoo type structures contain elements X and Y, each characters, > > > assigned identifiers 1 and 2. > > > Star contains An element N (a sting), assigned identifier 1, and an > > > array > > > Arr, assigned identifier 2, indexed as a table, containing int32s. > > > > > > To reference entities within an LFB instance of Class A, selectors > > > are as follows: > > > > > > 1, meaning the full array B > > Agreed. Note here 1 is as I mean 'Attribute ID' > > > > > 3, meaning the full structure named F. > > Agreed. 3 is another attribute ID. > > > > > 2, 7 meaning the full structure in the seventh entry of the array C. > > The protocol only pay attention to the 2 ID, while leaving the 7 being inluded > > in the data field. > > > > > 4 means the attribute D > > > 2, 8, 2, 9 meaning the 9th number in the array in the structure in the > > The protocol layer only pay attention to the 2 ID, leaving the 8,2,9 in the data > > field. Whatever format the LFB model may use to define the path. > > > > Cheers, > > Weiming > > > > > eigth slot of the array C. > > > Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct > > > type definition. > > > Since the model team has asserted that class definitions can > > > only change (version) in ways that leave existing references intact > > > and usable it means backward compatibility is supported. > > > > > > ---------------------- > > > > > > > > > cheers, > > > jamal > > > > > > On Wed, 2004-10-27 at 03:20, Khosravi, Hormuzd M wrote: > > > > Jamal, Weiming, > > > > > > > > I finally got the chance to read some of these emails...sorry for not > > > > responding earlier. In general, we will need the concept of PATH atleast > > > > for Query messages (GET), but I don't believe from any of the emails > > > > that I have read so far that there was any concensus on what this would > > > > look like. Jamal has a reasonable proposal which needs more discussion > > > > and refinement. > > > > > > > > Some specific comments on Jamal's proposal so far... > > > > > > > > Where is the Table ID ? Is this part of the path IDs? > > > > I don't believe we need any Flags in the path, this is similar to the > > > > comment that Joel had as well. > > > > Also, for Config msgs, I think the path can be part of the data itself, > > > > but lets discuss this further...cause I am not sure if you guys agree > > > > with this, > > > > > > > > Talk to you soon, > > > > > > > > regards > > > > Hormuzd > > > > > > > > -----Original Message----- > > > > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > > Sent: Tuesday, October 26, 2004 3:59 AM > > > > To: Wang,Weiming > > > > Cc: Joel M. Halpern; Khosravi, Hormuzd M; ram.gopal@nokia.com; > > > > forces-protocol@ietf.org; avri@psg.com; Ligang Dong; Robert Haas > > > > Subject: Re: [Forces-protocol] Feedback: Section 6.4 > > > > > > > > On Tue, 2004-10-26 at 00:01, Wang,Weiming wrote: > > > > > > > > > > > > > I have no doubt to agree with this. Just need to calrify that a path > > > > is more > > > > > than 32 bits long, or there will be not enough bits. > > > > > > > > > > > > > Aha! I think i see where the misunderstanding is;-> > > > > Weiming sees either a path like 6 or 1,2,3,4 as represented by _one_ > > > > _fixed_ sized element. In which case you have to find a way to pack both > > > > representations into that fixed size element. > > > > > > > > The suggested "path" representation is in fact _variable_. > > > > >From the notes i sent earlier to you, the suggestion is: > > > > > > > > ---- > > > > A possible path-data layout. > > > > ---------------------------- > > > > > > > > OPER_TLV : = > > > > PATH-DATA := flags IDcount [BLOCK_OR_KEY_NOTATION] [DATA] > > > > The operational TLV contains an opcode in the T part. Its V > > > > contains the PATH-DATA. > > > > Opcodes discussed so far: > > > > * SET (create, modify or both depending on PATH-DATA flags} > > > > * DEL (remove an existing entity specified by PATH-DATA } > > > > * GET (Access a entity specified in PATH-DATA } > > > > * EV_S (subscribe to an event defined in PATH-DATA } > > > > * EV_U (unsubscribe to an event defined in PATH-DATA } > > > > -> IDs := a series of 32bit IDs (whose size is given by IDcount) > > > > defining the path. > > > > -> flags are used to further refine the operation to be applied > > > > on the ID_TLV. > > > > -> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension > > > > defined in section 4.2 and 4.3 of [1] > > > > -> DATA : = Optional variable sized data dependent on PATH > > > > and applied operations (eg GET will not have DATA). > > > > > > > > ------- > > > > > > > > Well read the rest of the doc; and for completion the notes posted by > > > > Steve/Zsolt. > > > > > > > > cheers, > > > > jamal > > > > > > > > > > > > > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 27 17:51:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19193 for ; Wed, 27 Oct 2004 17:51:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMvv9-0000D1-Q2 for forces-protocol-web-archive@ietf.org; Wed, 27 Oct 2004 18:05:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMvf7-000056-CK; Wed, 27 Oct 2004 17:48:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMva6-0007su-FK for forces-protocol@megatron.ietf.org; Wed, 27 Oct 2004 17:43:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18501 for ; Wed, 27 Oct 2004 17:43:43 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMvo2-0008VJ-No for forces-protocol@ietf.org; Wed, 27 Oct 2004 17:58:11 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9RLgsnx028169; Wed, 27 Oct 2004 21:42:54 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9RLZ1FM027718; Wed, 27 Oct 2004 21:36:04 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102714420031095 ; Wed, 27 Oct 2004 14:42:11 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Oct 2004 14:41:49 -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 Subject: [Forces-protocol] Meeting Notes for today Date: Wed, 27 Oct 2004 14:41:39 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579243@orsmsx408> Thread-Topic: [Forces-protocol] Meeting Notes for today Thread-Index: AcS7f3o4ECQg9kCnTLeIyq3/bNK4MAAAZoRgAAAksGAAAYJZ0AA5YlTw From: "Khosravi, Hormuzd M" To: "Robert Haas" , , , , , , X-OriginalArrivalTime: 27 Oct 2004 21:41:49.0880 (UTC) FILETIME=[C3FCD380:01C4BC6D] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: "Putzolu, David" X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Here are today's meeting minutes that I took.... Meeting Notes 1. PATH - Weiming wants to split path in 2 pieces, path/attribute id and data (one is static, other depends on the data) Attribute ID may be Table ID. Weiming to post email with text describing the two schemes - include Model team in email (Advantages, disadvantages) 2. MultiLFB Addressing - 3 schemes, Robert to present at the IETF (TLV of multiple LFB instances, MIID, changing LFB class/instance TLV again) Jamal - tradeoff between compute and bandwidth 3. Packet Subscribe - 2 schemes - configure attribute of sink/source LFBs using Config, or special operation Packet Subscribe Resolution - use a Config msg to configure the attribute of some LFBS (Source/Sink like LFBs) Do we need to define the Source/Sink LFBs - we need to define the functionality, these LFBs would probably be defined by the model team Do we need anything special for the packet mirroring - this is part of the LFB attributes 4. Jamal/Robert/Hormuzd had more discussion later on about Jamal's comments on 6.1, 6.2. One resolution was to change the name of operation "SHOW" to "ADVERTISE". Jamal will send out an email to summarize the other topic regarding Events being addressed to LFBs rather than CE, FEs. Let me know if there are any comments, Thanks all for attending, Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 27 19:00:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25437 for ; Wed, 27 Oct 2004 19:00:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMx0E-0001ZA-Er for forces-protocol-web-archive@ietf.org; Wed, 27 Oct 2004 19:14:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwlM-0001lD-GM; Wed, 27 Oct 2004 18:59:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwjB-0001Ow-Qr for forces-protocol@megatron.ietf.org; Wed, 27 Oct 2004 18:57:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25226 for ; Wed, 27 Oct 2004 18:57:09 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMwx7-0001U2-CF for forces-protocol@ietf.org; Wed, 27 Oct 2004 19:11:38 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9RMvMM2018528; Wed, 27 Oct 2004 22:57:22 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9RMnVc1021871; Wed, 27 Oct 2004 22:49:57 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102715563717023 ; Wed, 27 Oct 2004 15:56:38 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Oct 2004 15:56:37 -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 Date: Wed, 27 Oct 2004 15:56:36 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E030E6F45@orsmsx408> Thread-Topic: draft-ietf-forces-protocol-01.txt Thread-Index: AcS6iTMyo20TNpE/SVOipDhic+KjEQB7prsQ From: "Khosravi, Hormuzd M" To: "Robert Haas" , X-OriginalArrivalTime: 27 Oct 2004 22:56:37.0967 (UTC) FILETIME=[37188DF0:01C4BC78] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: "\(\(Ram Gopal \)\)" , Jamal Hadi Salim , Weiming Wang , Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] RE: draft-ietf-forces-protocol-01.txt X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Avri, I agree with Robert's comment below, pls call yourself as Editor in the draft. Also, you can list your address in a separate section for Editor's addresses, if you like. I did have a comment on the Author's addresses section, I will send you in another email Regards Hormuzd=20 -----Original Message----- From: Robert Haas [mailto:rha@zurich.ibm.com]=20 - you should appear as "Editor", not "co-editor". At least that's my=20 understanding. Also, the ETRI name appears on the first page. I thought=20 you said you didn't want that ? I personally don't care. _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Wed Oct 27 19:17:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26672 for ; Wed, 27 Oct 2004 19:17:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxH8-0001vF-30 for forces-protocol-web-archive@ietf.org; Wed, 27 Oct 2004 19:32:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwxH-0003Xa-6Y; Wed, 27 Oct 2004 19:11:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMwwu-0003QK-8U for forces-protocol@megatron.ietf.org; Wed, 27 Oct 2004 19:11:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26299 for ; Wed, 27 Oct 2004 19:11:20 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMxAq-0001no-Sf for forces-protocol@ietf.org; Wed, 27 Oct 2004 19:25:49 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9RNBUM2025677; Wed, 27 Oct 2004 23:11:30 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9RN42bn001971; Wed, 27 Oct 2004 23:04:05 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102716104519542 ; Wed, 27 Oct 2004 16:10:45 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 27 Oct 2004 16:10:45 -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 Subject: RE: [Forces-protocol] RE: 01-8 Date: Wed, 27 Oct 2004 16:10:44 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E030E6FA5@orsmsx408> Thread-Topic: [Forces-protocol] RE: 01-8 Thread-Index: AcS68JQwwSDTGN83Sx+L38GyHSBRGABh6rDA From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 27 Oct 2004 23:10:45.0946 (UTC) FILETIME=[3087E1A0:01C4BC7A] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Jamal Hadi Salim , "Wang, Weiming" , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Avri, Sorry to bother you via email, but since I wont be coming for the IETF,=20 I thought this might be the best way. My reply below.. -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 > This is fine for now but I would prefer the Authors Addresses being a > separate section rather than part of the Appendix cause that is how I > have seen it in most RFCs including All the ForCES RFCs. the problem with what is currently possible is that it came before the=20 references when the regular authors section came after. [HK] This can be easily fixed in the final text, I think i would probably have to hack at xml2rfc to make it work. but i still=20 think it is against the rules proper - even if you got away with it on=20 the requirements. [HK] I don't think we got away with anything in the Requirements, I wish we had :-) If you look at any of the ForCES RFCs (below) that we have so far, the Authors Addresses are listed as a separate section, not as part of Appendix. That's my only requirement, I would like to see this as some section, not in the Appendix. And I agree that this section should be after the references. http://www.ietf.org/rfc/rfc3746.txt, http://www.ietf.org/rfc/rfc3549.txt Thanks Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 28 20:04:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21150 for ; Thu, 28 Oct 2004 20:04:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNKTh-0006wy-LJ for forces-protocol-web-archive@ietf.org; Thu, 28 Oct 2004 20:18:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJ81-00072x-VE; Thu, 28 Oct 2004 18:52:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNG6i-0006N8-CP for forces-protocol@megatron.ietf.org; Thu, 28 Oct 2004 15:38:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24983 for ; Thu, 28 Oct 2004 15:38:47 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNGKq-0006rH-1h for forces-protocol@ietf.org; Thu, 28 Oct 2004 15:53:24 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9SJgCkZ010659; Thu, 28 Oct 2004 19:42:12 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9SJfc22017119; Thu, 28 Oct 2004 19:41:46 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102812375620254 ; Thu, 28 Oct 2004 12:38:00 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Oct 2004 12:37:53 -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 Subject: RE: [Forces-protocol] Feedback: Section 6.4 Date: Thu, 28 Oct 2004 12:37:52 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E03127C40@orsmsx408> Thread-Topic: [Forces-protocol] Feedback: Section 6.4 Thread-Index: AcS8Nx7I8WRocJKZSFOi63Wye7CDgQA7hsDg From: "Khosravi, Hormuzd M" To: "Wang,Weiming" , X-OriginalArrivalTime: 28 Oct 2004 19:37:53.0781 (UTC) FILETIME=[9E23EA50:01C4BD25] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Joel M. Halpern" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Content-Transfer-Encoding: quoted-printable Weiming, I think it would be good if you summarized both approaches for PATH (Advantages, Disadvantages, etc) and send out an email to the group to discuss and decide. I do see my advantages to your approach and this is definitely a viable option for Config messages. For Query messages, the path will be more involved with all the IDs, etc (since there will be no data) Thanks Hormuzd -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn]=20 Sent: Wednesday, October 27, 2004 8:07 AM To: hadi@znyx.com Cc: Khosravi, Hormuzd M; Joel M. Halpern; ram.gopal@nokia.com; forces-protocol@ietf.org; avri@psg.com; Ligang Dong; Robert Haas Subject: Re: [Forces-protocol] Feedback: Section 6.4 ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: [Forces-protocol] Feedback: Section 6.4 > > Weiming, > > Yes, the two are different in the sense that one is defined at static > xml definition time and the other created at runtime. However, > if you give me a series of 32 bits defining a path which includes table > Ids and rows and cells, i can tell you 100% of the time where that path > will lead. There is _zero_ ambiguity. We can just let the first fields of the data being IDs for table index, which is really identical with the one whole path, but leaving more flexibiligy for every different LFBs to define the IDs. This means: Op TLV =3D AttributeID (or you may call it as : Path , but the path here is only an Attribute type ID). Data :=3D <...> In this way, if the LFB needs the indexing IDs, it will be there, if not, there will be none. Thanks. Weiming > > Note there are circumstances where it may make sense like in the case > of block operations (eg operate on table indices 100-200) - this is > probably your main point (as mentioned in your point #3). This does not > make the block operation part of the "data" like you said. All it says > is "this is how you get to the data". > > > cheers, > jamal > > On Wed, 2004-10-27 at 10:22, Wang,Weiming wrote: > > Jamal,Hormuzd as well, > > > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > Subject: RE: [Forces-protocol] Feedback: Section 6.4 > > > > > > > Folks, > > > > > > The PATH is needed for _everything_ thats interfacing to any LFB > > > attributes. > > [Weiming] I agree you say that path is needed for every attributes in LFB. > > My opinion is the path is composed of at least two parts: > > The ID to describe which attribte it is --- this I call it "Attribute ID", (and > > Hormuzd called "Table ID"?) > > The Index ID to describe which entry inside the attribute IF THE ATTRIBUTE IS A > > TABLE --- this we usualy called "table Index". > > > > Then, my opinion is (I think Hormuzd also think so) the 'Attribute ID' part > > should appear in our protocol layer, but the Index ID will not appear in the > > protocol layer. Instead, it should appear in the data field. Why? because, > > > > 1) Not every attribute is a table, therefore not every attribute need such table > > index. But 'Attribute ID' is always needed. > > > > 2) Even in the table case, to put the table index in the data field means to let > > the LFB definer to have much flexibility to define the index - the length of the > > index, the format, etc, rathan than to be uniformly defined for all LFBs by our > > protocol. > > > > 3) In this way, we can also easily implement all the operations as you mentioned > > below. > > > > 4) Also note that the 'Attribute ID'is explicitly defined in XML definition of > > LFBs(e.g. ID=3D6 in your noop.xml), while the table index will not appear in the > > xml, that means the table index is a kind of data while the attribute ID is a > > specific field, from the protocol viewpoint. > > > > > > > Think of it as an SNMP OID - you need that _everytime_ > > > To get to where the table etc fits in, please read the two docs i posted > > > to speed up the discussion; > > > > > > Heres a cutnpaste from one of those docs: > > > > > > path-data > > > ---------- > > > The layout is still under discussion and so is left out from this text. > > > > > > Each accessible attribute within an LFB is expected to have a 32 bit > > > identifier. > > Yes. > > > > > > The path-data will have a map derived from the static class attribute > > > IDs as well as those derived from variable content such table indices > > > (derived at runtime). > > Exactly. > > > > > > > > Below is an illustration of a complex example and how the different > > > attributes could be accessed. > > > > > > Assume LFB Class A. > > > It contains two Arrays, B, and C (assigned identifiers 1 and 2) > > > A also contains a structure of type Stoo with a human name F. > > > F is assigned ID 3. > > > A also contains two attributes, D and E assigned identifiers 4 and 5. > > > Array B is an array, indexed as a table, whose contents are int32s. > > > Array C is an array, indexed as a table, whose contents are a structure > > > named Star. > > > Stoo type structures contain elements X and Y, each characters, > > > assigned identifiers 1 and 2. > > > Star contains An element N (a sting), assigned identifier 1, and an > > > array > > > Arr, assigned identifier 2, indexed as a table, containing int32s. > > > > > > To reference entities within an LFB instance of Class A, selectors > > > are as follows: > > > > > > 1, meaning the full array B > > Agreed. Note here 1 is as I mean 'Attribute ID' > > > > > 3, meaning the full structure named F. > > Agreed. 3 is another attribute ID. > > > > > 2, 7 meaning the full structure in the seventh entry of the array C. > > The protocol only pay attention to the 2 ID, while leaving the 7 being inluded > > in the data field. > > > > > 4 means the attribute D > > > 2, 8, 2, 9 meaning the 9th number in the array in the structure in the > > The protocol layer only pay attention to the 2 ID, leaving the 8,2,9 in the data > > field. Whatever format the LFB model may use to define the path. > > > > Cheers, > > Weiming > > > > > eigth slot of the array C. > > > Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct > > > type definition. > > > Since the model team has asserted that class definitions can > > > only change (version) in ways that leave existing references intact > > > and usable it means backward compatibility is supported. > > > > > > ---------------------- > > > > > > > > > cheers, > > > jamal > > > > > > On Wed, 2004-10-27 at 03:20, Khosravi, Hormuzd M wrote: > > > > Jamal, Weiming, > > > > > > > > I finally got the chance to read some of these emails...sorry for not > > > > responding earlier. In general, we will need the concept of PATH atleast > > > > for Query messages (GET), but I don't believe from any of the emails > > > > that I have read so far that there was any concensus on what this would > > > > look like. Jamal has a reasonable proposal which needs more discussion > > > > and refinement. > > > > > > > > Some specific comments on Jamal's proposal so far... > > > > > > > > Where is the Table ID ? Is this part of the path IDs? > > > > I don't believe we need any Flags in the path, this is similar to the > > > > comment that Joel had as well. > > > > Also, for Config msgs, I think the path can be part of the data itself, > > > > but lets discuss this further...cause I am not sure if you guys agree > > > > with this, > > > > > > > > Talk to you soon, > > > > > > > > regards > > > > Hormuzd > > > > > > > > -----Original Message----- > > > > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > > Sent: Tuesday, October 26, 2004 3:59 AM > > > > To: Wang,Weiming > > > > Cc: Joel M. Halpern; Khosravi, Hormuzd M; ram.gopal@nokia.com; > > > > forces-protocol@ietf.org; avri@psg.com; Ligang Dong; Robert Haas > > > > Subject: Re: [Forces-protocol] Feedback: Section 6.4 > > > > > > > > On Tue, 2004-10-26 at 00:01, Wang,Weiming wrote: > > > > > > > > > > > > > I have no doubt to agree with this. Just need to calrify that a path > > > > is more > > > > > than 32 bits long, or there will be not enough bits. > > > > > > > > > > > > > Aha! I think i see where the misunderstanding is;-> > > > > Weiming sees either a path like 6 or 1,2,3,4 as represented by _one_ > > > > _fixed_ sized element. In which case you have to find a way to pack both > > > > representations into that fixed size element. > > > > > > > > The suggested "path" representation is in fact _variable_. > > > > >From the notes i sent earlier to you, the suggestion is: > > > > > > > > ---- > > > > A possible path-data layout. > > > > ---------------------------- > > > > > > > > OPER_TLV : =3D > > > > PATH-DATA :=3D flags IDcount [BLOCK_OR_KEY_NOTATION] = [DATA] > > > > The operational TLV contains an opcode in the T part. Its V > > > > contains the PATH-DATA. > > > > Opcodes discussed so far: > > > > * SET (create, modify or both depending on PATH-DATA flags} > > > > * DEL (remove an existing entity specified by PATH-DATA } > > > > * GET (Access a entity specified in PATH-DATA } > > > > * EV_S (subscribe to an event defined in PATH-DATA } > > > > * EV_U (unsubscribe to an event defined in PATH-DATA } > > > > -> IDs :=3D a series of 32bit IDs (whose size is given by = IDcount) > > > > defining the path. > > > > -> flags are used to further refine the operation to be applied > > > > on the ID_TLV. > > > > -> BLOCK_OR_KEY_NOTATION :=3D optional different BLOCK or KEY extension > > > > defined in section 4.2 and 4.3 of [1] > > > > -> DATA : =3D Optional variable sized data dependent on PATH > > > > and applied operations (eg GET will not have DATA). > > > > > > > > ------- > > > > > > > > Well read the rest of the doc; and for completion the notes posted by > > > > Steve/Zsolt. > > > > > > > > cheers, > > > > jamal > > > > > > > > > > > > > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Thu Oct 28 23:12:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01155 for ; Thu, 28 Oct 2004 23:12:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNPg-0002EH-28 for forces-protocol-web-archive@ietf.org; Thu, 28 Oct 2004 23:26:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMfZ-0004up-CI; Thu, 28 Oct 2004 22:39:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNKhy-0002U7-IJ for forces-protocol@megatron.ietf.org; Thu, 28 Oct 2004 20:33:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28725 for ; Thu, 28 Oct 2004 20:33:33 -0400 (EDT) Received: from [202.96.99.56] (helo=202.96.99.56) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNKw0-0000q4-PJ for forces-protocol@ietf.org; Thu, 28 Oct 2004 20:48:13 -0400 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 58110.341813895; Fri, 29 Oct 2004 08:53:47 +0800 (CST) Received: from wwm1 (unverified [219.82.178.109]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id ; Fri, 29 Oct 2004 08:28:40 +0800 Message-ID: <001301c4bd4f$63d66ec0$020aa8c0@wwm1> From: "Weiming Wang" To: "Khosravi, Hormuzd M" , References: <468F3FDA28AA87429AD807992E22D07E03127C40@orsmsx408> Subject: Re: [Forces-protocol] Feedback: Section 6.4 Date: Fri, 29 Oct 2004 08:36:52 +0800 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 X-Spam-Score: 0.4 (/) X-Scan-Signature: 6b519fb0ef66258f34533f52ff46aedf Cc: ram.gopal@nokia.com, forces-protocol@ietf.org, avri@psg.com, "Joel M. Halpern" , Ligang Dong , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Hormuzd, I'm very busy again during this weekdays. Pls allow me to do it during this weekend. I'l post something in detail then. Regards, Weiming ----- Original Message ----- From: "Khosravi, Hormuzd M" To: "Wang,Weiming" ; Cc: "Joel M. Halpern" ; ; ; ; "Ligang Dong" ; "Robert Haas" Sent: Friday, October 29, 2004 3:37 AM Subject: RE: [Forces-protocol] Feedback: Section 6.4 Weiming, I think it would be good if you summarized both approaches for PATH (Advantages, Disadvantages, etc) and send out an email to the group to discuss and decide. I do see my advantages to your approach and this is definitely a viable option for Config messages. For Query messages, the path will be more involved with all the IDs, etc (since there will be no data) Thanks Hormuzd -----Original Message----- From: Wang,Weiming [mailto:wmwang@mail.hzic.edu.cn] Sent: Wednesday, October 27, 2004 8:07 AM To: hadi@znyx.com Cc: Khosravi, Hormuzd M; Joel M. Halpern; ram.gopal@nokia.com; forces-protocol@ietf.org; avri@psg.com; Ligang Dong; Robert Haas Subject: Re: [Forces-protocol] Feedback: Section 6.4 ----- Original Message ----- From: "Jamal Hadi Salim" Subject: Re: [Forces-protocol] Feedback: Section 6.4 > > Weiming, > > Yes, the two are different in the sense that one is defined at static > xml definition time and the other created at runtime. However, > if you give me a series of 32 bits defining a path which includes table > Ids and rows and cells, i can tell you 100% of the time where that path > will lead. There is _zero_ ambiguity. We can just let the first fields of the data being IDs for table index, which is really identical with the one whole path, but leaving more flexibiligy for every different LFBs to define the IDs. This means: Op TLV = AttributeID (or you may call it as : Path , but the path here is only an Attribute type ID). Data := <...> In this way, if the LFB needs the indexing IDs, it will be there, if not, there will be none. Thanks. Weiming > > Note there are circumstances where it may make sense like in the case > of block operations (eg operate on table indices 100-200) - this is > probably your main point (as mentioned in your point #3). This does not > make the block operation part of the "data" like you said. All it says > is "this is how you get to the data". > > > cheers, > jamal > > On Wed, 2004-10-27 at 10:22, Wang,Weiming wrote: > > Jamal,Hormuzd as well, > > > > ----- Original Message ----- > > From: "Jamal Hadi Salim" > > Subject: RE: [Forces-protocol] Feedback: Section 6.4 > > > > > > > Folks, > > > > > > The PATH is needed for _everything_ thats interfacing to any LFB > > > attributes. > > [Weiming] I agree you say that path is needed for every attributes in LFB. > > My opinion is the path is composed of at least two parts: > > The ID to describe which attribte it is --- this I call it "Attribute ID", (and > > Hormuzd called "Table ID"?) > > The Index ID to describe which entry inside the attribute IF THE ATTRIBUTE IS A > > TABLE --- this we usualy called "table Index". > > > > Then, my opinion is (I think Hormuzd also think so) the 'Attribute ID' part > > should appear in our protocol layer, but the Index ID will not appear in the > > protocol layer. Instead, it should appear in the data field. Why? because, > > > > 1) Not every attribute is a table, therefore not every attribute need such table > > index. But 'Attribute ID' is always needed. > > > > 2) Even in the table case, to put the table index in the data field means to let > > the LFB definer to have much flexibility to define the index - the length of the > > index, the format, etc, rathan than to be uniformly defined for all LFBs by our > > protocol. > > > > 3) In this way, we can also easily implement all the operations as you mentioned > > below. > > > > 4) Also note that the 'Attribute ID'is explicitly defined in XML definition of > > LFBs(e.g. ID=6 in your noop.xml), while the table index will not appear in the > > xml, that means the table index is a kind of data while the attribute ID is a > > specific field, from the protocol viewpoint. > > > > > > > Think of it as an SNMP OID - you need that _everytime_ > > > To get to where the table etc fits in, please read the two docs i posted > > > to speed up the discussion; > > > > > > Heres a cutnpaste from one of those docs: > > > > > > path-data > > > ---------- > > > The layout is still under discussion and so is left out from this text. > > > > > > Each accessible attribute within an LFB is expected to have a 32 bit > > > identifier. > > Yes. > > > > > > The path-data will have a map derived from the static class attribute > > > IDs as well as those derived from variable content such table indices > > > (derived at runtime). > > Exactly. > > > > > > > > Below is an illustration of a complex example and how the different > > > attributes could be accessed. > > > > > > Assume LFB Class A. > > > It contains two Arrays, B, and C (assigned identifiers 1 and 2) > > > A also contains a structure of type Stoo with a human name F. > > > F is assigned ID 3. > > > A also contains two attributes, D and E assigned identifiers 4 and 5. > > > Array B is an array, indexed as a table, whose contents are int32s. > > > Array C is an array, indexed as a table, whose contents are a structure > > > named Star. > > > Stoo type structures contain elements X and Y, each characters, > > > assigned identifiers 1 and 2. > > > Star contains An element N (a sting), assigned identifier 1, and an > > > array > > > Arr, assigned identifier 2, indexed as a table, containing int32s. > > > > > > To reference entities within an LFB instance of Class A, selectors > > > are as follows: > > > > > > 1, meaning the full array B > > Agreed. Note here 1 is as I mean 'Attribute ID' > > > > > 3, meaning the full structure named F. > > Agreed. 3 is another attribute ID. > > > > > 2, 7 meaning the full structure in the seventh entry of the array C. > > The protocol only pay attention to the 2 ID, while leaving the 7 being inluded > > in the data field. > > > > > 4 means the attribute D > > > 2, 8, 2, 9 meaning the 9th number in the array in the structure in the > > The protocol layer only pay attention to the 2 ID, leaving the 8,2,9 in the data > > field. Whatever format the LFB model may use to define the path. > > > > Cheers, > > Weiming > > > > > eigth slot of the array C. > > > Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct > > > type definition. > > > Since the model team has asserted that class definitions can > > > only change (version) in ways that leave existing references intact > > > and usable it means backward compatibility is supported. > > > > > > ---------------------- > > > > > > > > > cheers, > > > jamal > > > > > > On Wed, 2004-10-27 at 03:20, Khosravi, Hormuzd M wrote: > > > > Jamal, Weiming, > > > > > > > > I finally got the chance to read some of these emails...sorry for not > > > > responding earlier. In general, we will need the concept of PATH atleast > > > > for Query messages (GET), but I don't believe from any of the emails > > > > that I have read so far that there was any concensus on what this would > > > > look like. Jamal has a reasonable proposal which needs more discussion > > > > and refinement. > > > > > > > > Some specific comments on Jamal's proposal so far... > > > > > > > > Where is the Table ID ? Is this part of the path IDs? > > > > I don't believe we need any Flags in the path, this is similar to the > > > > comment that Joel had as well. > > > > Also, for Config msgs, I think the path can be part of the data itself, > > > > but lets discuss this further...cause I am not sure if you guys agree > > > > with this, > > > > > > > > Talk to you soon, > > > > > > > > regards > > > > Hormuzd > > > > > > > > -----Original Message----- > > > > From: Jamal Hadi Salim [mailto:hadi@znyx.com] > > > > Sent: Tuesday, October 26, 2004 3:59 AM > > > > To: Wang,Weiming > > > > Cc: Joel M. Halpern; Khosravi, Hormuzd M; ram.gopal@nokia.com; > > > > forces-protocol@ietf.org; avri@psg.com; Ligang Dong; Robert Haas > > > > Subject: Re: [Forces-protocol] Feedback: Section 6.4 > > > > > > > > On Tue, 2004-10-26 at 00:01, Wang,Weiming wrote: > > > > > > > > > > > > > I have no doubt to agree with this. Just need to calrify that a path > > > > is more > > > > > than 32 bits long, or there will be not enough bits. > > > > > > > > > > > > > Aha! I think i see where the misunderstanding is;-> > > > > Weiming sees either a path like 6 or 1,2,3,4 as represented by _one_ > > > > _fixed_ sized element. In which case you have to find a way to pack both > > > > representations into that fixed size element. > > > > > > > > The suggested "path" representation is in fact _variable_. > > > > >From the notes i sent earlier to you, the suggestion is: > > > > > > > > ---- > > > > A possible path-data layout. > > > > ---------------------------- > > > > > > > > OPER_TLV : = > > > > PATH-DATA := flags IDcount [BLOCK_OR_KEY_NOTATION] [DATA] > > > > The operational TLV contains an opcode in the T part. Its V > > > > contains the PATH-DATA. > > > > Opcodes discussed so far: > > > > * SET (create, modify or both depending on PATH-DATA flags} > > > > * DEL (remove an existing entity specified by PATH-DATA } > > > > * GET (Access a entity specified in PATH-DATA } > > > > * EV_S (subscribe to an event defined in PATH-DATA } > > > > * EV_U (unsubscribe to an event defined in PATH-DATA } > > > > -> IDs := a series of 32bit IDs (whose size is given by IDcount) > > > > defining the path. > > > > -> flags are used to further refine the operation to be applied > > > > on the ID_TLV. > > > > -> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension > > > > defined in section 4.2 and 4.3 of [1] > > > > -> DATA : = Optional variable sized data dependent on PATH > > > > and applied operations (eg GET will not have DATA). > > > > > > > > ------- > > > > > > > > Well read the rest of the doc; and for completion the notes posted by > > > > Steve/Zsolt. > > > > > > > > cheers, > > > > jamal > > > > > > > > > > > > > > > > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 29 01:45:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11397 for ; Fri, 29 Oct 2004 01:45:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNPoF-0005dR-Do for forces-protocol-web-archive@ietf.org; Fri, 29 Oct 2004 02:00:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNPVQ-0002bb-Fo; Fri, 29 Oct 2004 01:40:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNPRU-0006ax-4U for forces-protocol@megatron.ietf.org; Fri, 29 Oct 2004 01:36:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10745 for ; Fri, 29 Oct 2004 01:36:50 -0400 (EDT) Received: from fmr12.intel.com ([134.134.136.15] helo=orsfmr001.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNPfh-0005TP-0P for forces-protocol@ietf.org; Fri, 29 Oct 2004 01:51:33 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9T5atCl031997; Fri, 29 Oct 2004 05:36:58 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9T5bTuZ026181; Fri, 29 Oct 2004 05:39:55 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102822360927317 ; Thu, 28 Oct 2004 22:36:09 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Oct 2004 22:36:09 -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 Date: Thu, 28 Oct 2004 22:35:49 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579248@orsmsx408> Thread-Topic: 01-5 Thread-Index: AcS6EcAdW6oqqyLWQoCU1qgz0l0UQwDZtfoQ From: "Khosravi, Hormuzd M" To: , "Jamal Hadi Salim" X-OriginalArrivalTime: 29 Oct 2004 05:36:09.0372 (UTC) FILETIME=[31946DC0:01C4BD79] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, "Putzolu, David" , Ligang Dong , Robert Haas Subject: [Forces-protocol] RE: 01-5 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Avri, -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 > > The WG should see the draft after we are done i think. I wouldnt say we > are. i tend to disagree with this. now that this is a WG document, and the=20 WG is the owner of the doc, i believe they should have more frequent=20 snapshots and should be brought into the discussions. but i defer to the team and the chairs on this issue. [HK] I completely agree with you on this, if we cannot agree on issues we should start sending emails to the main list and ask for WG opinion. This way we can make faster progress and keep the WG involved as well. regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 29 01:51:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11681 for ; Fri, 29 Oct 2004 01:51:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNPtg-0005jb-GQ for forces-protocol-web-archive@ietf.org; Fri, 29 Oct 2004 02:06:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNPVn-000377-LG; Fri, 29 Oct 2004 01:41:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNPTB-0008Nm-SS for forces-protocol@megatron.ietf.org; Fri, 29 Oct 2004 01:38:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10801 for ; Fri, 29 Oct 2004 01:38:36 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNPhO-0005Uk-4s for forces-protocol@ietf.org; Fri, 29 Oct 2004 01:53:19 -0400 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9T5g8pr002338; Fri, 29 Oct 2004 05:42:08 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9T5fOuK029681; Fri, 29 Oct 2004 05:41:50 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102822380427705 ; Thu, 28 Oct 2004 22:38:04 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 28 Oct 2004 22:38:04 -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 Date: Thu, 28 Oct 2004 22:37:52 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E02579249@orsmsx408> Thread-Topic: Open issues list ? Thread-Index: AcS6EcAdW6oqqyLWQoCU1qgz0l0UQwDZtfoQAAApzeA= From: "Khosravi, Hormuzd M" To: , "Jamal Hadi Salim" X-OriginalArrivalTime: 29 Oct 2004 05:38:04.0209 (UTC) FILETIME=[76072A10:01C4BD79] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, "Wang, Weiming" , forces-protocol@ietf.org, "Putzolu, David" , Ligang Dong , Robert Haas Subject: [Forces-protocol] Open issues list ? X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Avri, BTW, at some point I thought you were keeping a list of open issues...do we still have this ? -----Original Message----- From: avri@psg.com [mailto:avri@psg.com]=20 > > The WG should see the draft after we are done i think. I wouldnt say we > are. i tend to disagree with this. now that this is a WG document, and the=20 WG is the owner of the doc, i believe they should have more frequent=20 snapshots and should be brought into the discussions. but i defer to the team and the chairs on this issue. [HK] I completely agree with you on this, if we cannot agree on issues we should start sending emails to the main list and ask for WG opinion. This way we can make faster progress and keep the WG involved as well. regards Hormuzd _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 29 09:09:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27028 for ; Fri, 29 Oct 2004 09:09:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWjl-0006c3-MY for forces-protocol-web-archive@ietf.org; Fri, 29 Oct 2004 09:24:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWQ1-0005wv-At; Fri, 29 Oct 2004 09:03:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWId-0001Cw-Hl for forces-protocol@megatron.ietf.org; Fri, 29 Oct 2004 08:56:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26183 for ; Fri, 29 Oct 2004 08:56:10 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWWv-0006MS-7M for forces-protocol@ietf.org; Fri, 29 Oct 2004 09:10:57 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102906000219:667 ; Fri, 29 Oct 2004 06:00:02 -0700 From: Jamal Hadi Salim To: david.putzolu@intel.com Organization: ZNYX Networks Message-Id: <1099054567.1026.115.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Oct 2004 08:56:07 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/29/2004 06:00:02 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/29/2004 06:00:04 AM, Serialize complete at 10/29/2004 06:00:04 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: dro@zurich.ibm.com, forces-protocol@ietf.org Subject: [Forces-protocol] request for slot X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit - Protocol presentation - 30-45 minutes. - presenter: jamal cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 29 09:23:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27750 for ; Fri, 29 Oct 2004 09:23:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWww-0006qM-08 for forces-protocol-web-archive@ietf.org; Fri, 29 Oct 2004 09:37:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWhH-0006px-O2; Fri, 29 Oct 2004 09:21:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNWRQ-00073l-NC for forces-protocol@megatron.ietf.org; Fri, 29 Oct 2004 09:05:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26743 for ; Fri, 29 Oct 2004 09:05:15 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNWfi-0006X7-Ld for forces-protocol@ietf.org; Fri, 29 Oct 2004 09:20:02 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102906090405:673 ; Fri, 29 Oct 2004 06:09:04 -0700 From: Jamal Hadi Salim To: avri@psg.com In-Reply-To: <1098562959.1096.80.camel@jzny.localdomain> References: <468F3FDA28AA87429AD807992E22D07E02579210@orsmsx408> <1E526654-24BF-11D9-9DB1-000393CC2112@psg.com> <417A23E6.7010504@zurich.ibm.com> <1098562959.1096.80.camel@jzny.localdomain> Organization: ZNYX Networks Message-Id: <1099055108.1028.125.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Oct 2004 09:05:09 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/29/2004 06:09:04 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/29/2004 06:09:09 AM, Serialize complete at 10/29/2004 06:09:09 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: "Khosravi, Hormuzd M" , ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, Weiming Wang , Robert Haas Subject: [Forces-protocol] Resend: Feedback: Section 6.2 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Folks, I am gonna start queueing (inot a queue that holds only one message) issues i think are unresolved (we either didnt get to completion on call or havent discussed them to satisfaction to close them). - Section 6.2.1 +--- T = Operation = SHOW | +-- FE NAME Is it an operation at all given its position in the hierachy? PENAME may have been a better name. I didnt explain this well on the call. Where operation is showing up is the wrong spot for the grammar which says operation comes after LFBSelection. It is therefore not an operation. Hence the suggestion to call it PENAME. In the diagram: + LFB Instance ID and LFB Class ID should those just be set to 0x1? We already know thats where they are going. + Type = operation, using the word "type" is confusing since it is also used in the main header. I dont think we can avoid using the word type in TLVs; my suggestion is we consider changing the main header type to "command". Thoughts? It is a command after all. + comment on SHOW applies here as well + "HBI will be exchanged with the CE using this LFB" ??? -6.2.2 Association Setup Response Message In the diagram: + LFB Instance ID and LFB Class ID should those just be set to 0x1? We already know thats where they are going. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = operation Show | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ FE Object LFB (optional) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What is that? + "HBI will be exchanged with the CE using this LFB" ??? + Type = T.reason ? This brings up that we need the following speacial TLVs. FORCES_REASON, FORCES_RESULT, FORCES_NAME. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 29 13:56:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19569 for ; Fri, 29 Oct 2004 13:56:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNbDe-0004e2-Kz for forces-protocol-web-archive@ietf.org; Fri, 29 Oct 2004 14:11:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNavH-0001Ar-QB; Fri, 29 Oct 2004 13:52:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNaqy-0004hp-3d for forces-protocol@megatron.ietf.org; Fri, 29 Oct 2004 13:47:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19031 for ; Fri, 29 Oct 2004 13:47:54 -0400 (EDT) Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNb5F-0004Ta-Jh for forces-protocol@ietf.org; Fri, 29 Oct 2004 14:02:44 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9THpKdW007529; Fri, 29 Oct 2004 17:51:20 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9THe4Od030306; Fri, 29 Oct 2004 17:40:27 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102910471408656 ; Fri, 29 Oct 2004 10:47:14 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Oct 2004 10:47:14 -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 Date: Fri, 29 Oct 2004 10:47:13 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E03128AB1@orsmsx408> Thread-Topic: Resend: Feedback: Section 6.2 Thread-Index: AcS9t/RrKU+fQSMUTMiUJer79UnxPwAJqfww From: "Khosravi, Hormuzd M" To: , , "Robert Haas" X-OriginalArrivalTime: 29 Oct 2004 17:47:14.0559 (UTC) FILETIME=[5344C8F0:01C4BDDF] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Weiming Wang , Ligang Dong , forces-protocol@ietf.org Subject: [Forces-protocol] RE: Resend: Feedback: Section 6.2 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Jamal, I thought we discussed this on the call and the resolution was to change the Operation name from SHOW to ADVERTISE. I am not sure why you are bringing this up again, pls look at the grammar once... PL level PDU :=3D MAINHDR+ LFBselect :=3D LFBCLASSID LFBInstance + OPER :=3D ]*>+ I think this fits quite well into it, and the Operation name Advertise is more general and can be reused as opposed to what your suggestions are. Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Friday, October 29, 2004 6:05 AM To: avri@psg.com Cc: Robert Haas; forces-protocol@ietf.org; Ligang Dong; ram.gopal@nokia.com; Khosravi, Hormuzd M; Weiming Wang Subject: Resend: Feedback: Section 6.2 Folks, I am gonna start queueing (inot a queue that holds only one message) issues i think are unresolved (we either didnt get to completion on call or havent discussed them to satisfaction to close them). - Section 6.2.1 +--- T =3D Operation =3D SHOW | +-- FE NAME Is it an operation at all given its position in the hierachy? PENAME may have been a better name. I didnt explain this well on the call. Where operation is showing up is the wrong spot for the grammar which says operation comes after LFBSelection. It is therefore not an operation. Hence the suggestion to call it PENAME. In the diagram:=20 + LFB Instance ID and LFB Class ID=20 should those just be set to 0x1? We already know thats where they are going. + Type =3D operation, using the word "type" is confusing since it is = also used in the main header. I dont think we can avoid using the word type in TLVs; my suggestion is we consider changing the main header type to=20 "command". Thoughts? It is a command after all. + comment on SHOW applies here as well + "HBI will be exchanged with the CE using this LFB" ??? -6.2.2 Association Setup Response Message In the diagram:=20 + LFB Instance ID and LFB Class ID=20 should those just be set to 0x1? We already know thats where they are going. + =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D operation Show | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ FE Object LFB (optional) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What is that? + "HBI will be exchanged with the CE using this LFB" ??? + Type =3D T.reason ? This brings up that we need the following speacial TLVs. FORCES_REASON, FORCES_RESULT, FORCES_NAME. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 29 14:24:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21427 for ; Fri, 29 Oct 2004 14:24:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNbed-0005C9-OH for forces-protocol-web-archive@ietf.org; Fri, 29 Oct 2004 14:39:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNbKL-00007q-7X; Fri, 29 Oct 2004 14:18:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNbBl-0004cO-PT for forces-protocol@megatron.ietf.org; Fri, 29 Oct 2004 14:09:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20688 for ; Fri, 29 Oct 2004 14:09:24 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNbQ5-0004xG-Pb for forces-protocol@ietf.org; Fri, 29 Oct 2004 14:24:14 -0400 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102911131548:989 ; Fri, 29 Oct 2004 11:13:15 -0700 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03128AB1@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E03128AB1@orsmsx408> Organization: Znyx Networks Message-Id: <1099073360.1025.30.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Oct 2004 14:09:21 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/29/2004 11:13:15 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/29/2004 11:13:17 AM, Serialize complete at 10/29/2004 11:13:17 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Weiming Wang , Robert Haas Subject: [Forces-protocol] RE: Resend: Feedback: Section 6.2 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit On Fri, 2004-10-29 at 13:47, Khosravi, Hormuzd M wrote: > Jamal, > > I thought we discussed this on the call and the resolution was to change > the Operation name from SHOW to ADVERTISE. The issue has nothing to do with the name but where things fit in in the grammar. > I am not sure why you are > bringing this up again, pls look at the grammar once... > Because it was not resolved. > PL level PDU := MAINHDR+ > LFBselect := LFBCLASSID LFBInstance + > OPER := ]*>+ > > > I think this fits quite well into it, and the Operation name Advertise > is more general and can be reused as opposed to what your suggestions > are. Look again please: -------- main hdr (eg type = Association setup) | | +--- T = LFBselect | | | +-- LFBCLASSID = FE object | | | | | +-- LFBInstance = 0x1 | +--- T = Operation = SHOW | +-- FE NAME --------------- The operation is Not part of the LFBSelect. It should be: -------- main hdr (eg type = Association setup) | | +--- T = LFBselect | +-- LFBCLASSID = FE object | | +-- LFBInstance = 0x1 | +--- T = Operation = ADVERTISE | +-- FE NAME --------------- If you want to leave it there call it PENAME as i suggested. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 29 17:42:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16406 for ; Fri, 29 Oct 2004 17:42:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNeke-0003FO-CQ for forces-protocol-web-archive@ietf.org; Fri, 29 Oct 2004 17:57:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNe43-00022d-Gr; Fri, 29 Oct 2004 17:13:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNdRw-0006E1-Ej for forces-protocol@megatron.ietf.org; Fri, 29 Oct 2004 16:34:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06951 for ; Fri, 29 Oct 2004 16:34:13 -0400 (EDT) Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdgH-0000gA-B2 for forces-protocol@ietf.org; Fri, 29 Oct 2004 16:49:05 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i9TKXMJ7022496; Fri, 29 Oct 2004 20:33:22 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.11 2004/07/29 22:51:53 root Exp $) with SMTP id i9TKP8Op005174; Fri, 29 Oct 2004 20:26:37 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102913332227726 ; Fri, 29 Oct 2004 13:33:22 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Oct 2004 13:33:22 -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 Date: Fri, 29 Oct 2004 13:33:21 -0700 Message-ID: <468F3FDA28AA87429AD807992E22D07E031688E1@orsmsx408> Thread-Topic: Resend: Feedback: Section 6.2 Thread-Index: AcS94m+BgibkvxeXT8az4KdvfDtXjAAE9s0g From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 29 Oct 2004 20:33:22.0496 (UTC) FILETIME=[889F4400:01C4BDF6] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Weiming Wang , Robert Haas Subject: [Forces-protocol] RE: Resend: Feedback: Section 6.2 X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Ok, I see where the confusion is, the bitwise message representation is in the correct format but the other format which you have drawn below is not. This is a copy/paste error, I'll send out a fix to Avri. Thanks Hormuzd -----Original Message----- From: Jamal Hadi Salim [mailto:hadi@znyx.com]=20 Sent: Friday, October 29, 2004 11:09 AM To: Khosravi, Hormuzd M Cc: avri@psg.com; Robert Haas; forces-protocol@ietf.org; Ligang Dong; ram.gopal@nokia.com; Weiming Wang Subject: RE: Resend: Feedback: Section 6.2 On Fri, 2004-10-29 at 13:47, Khosravi, Hormuzd M wrote: > Jamal, >=20 > I thought we discussed this on the call and the resolution was to change > the Operation name from SHOW to ADVERTISE.=20 The issue has nothing to do with the name but where things fit in in the grammar. > I am not sure why you are > bringing this up again, pls look at the grammar once... >=20 Because it was not resolved.=20 > PL level PDU :=3D MAINHDR+ > LFBselect :=3D LFBCLASSID LFBInstance + > OPER :=3D ]*>+ >=20 >=20 > I think this fits quite well into it, and the Operation name Advertise > is more general and can be reused as opposed to what your suggestions > are. Look again please: -------- main hdr (eg type =3D Association setup) | | +--- T =3D LFBselect | | | +-- LFBCLASSID =3D FE object | | | | | +-- LFBInstance =3D 0x1 | +--- T =3D Operation =3D SHOW | +-- FE NAME --------------- The operation is Not part of the LFBSelect. It should be: -------- main hdr (eg type =3D Association setup) | | +--- T =3D LFBselect | +-- LFBCLASSID =3D FE object | | +-- LFBInstance =3D 0x1 | +--- T =3D Operation =3D ADVERTISE | +-- FE NAME --------------- If you want to leave it there call it PENAME as i suggested. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 29 18:22:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21214 for ; Fri, 29 Oct 2004 18:22:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNfNR-0004Fz-J3 for forces-protocol-web-archive@ietf.org; Fri, 29 Oct 2004 18:37:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNet0-0001CH-62; Fri, 29 Oct 2004 18:06:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNegT-00084p-G4 for forces-protocol@megatron.ietf.org; Fri, 29 Oct 2004 17:53:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17932 for ; Fri, 29 Oct 2004 17:53:19 -0400 (EDT) From: avri@psg.com Received: from tla.crepundia.net ([194.71.127.149] helo=report.tla-group.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNeuo-0003g7-VB for forces-protocol@ietf.org; Fri, 29 Oct 2004 18:08:12 -0400 Received: from [127.0.0.1] (report.tla-group.com [194.71.127.149]) by report.tla-group.com (8.12.4/8.12.4) with ESMTP id i9TLRwep010948; Fri, 29 Oct 2004 23:27:59 +0200 In-Reply-To: <468F3FDA28AA87429AD807992E22D07E030E6FA5@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E030E6FA5@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Subject: Re: [Forces-protocol] RE: 01-8 Date: Fri, 29 Oct 2004 16:53:14 -0500 To: "Khosravi, Hormuzd M" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.3 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Jamal Hadi Salim , Robert Haas , Weiming Wang , "Ram Gopal Ligang Dong" , forces-protocol@ietf.org X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit On 27 okt 2004, at 18.10, Khosravi, Hormuzd M wrote: > Avri, > > Sorry to bother you via email, but since I wont be coming for the IETF, > I thought this might be the best way. My reply below.. no bother, my life is spent in email. well almost. Anyway, i will see what i can do about it. At the worst, I will hand edit on the final submission - when we get there. > > -----Original Message----- > From: avri@psg.com [mailto:avri@psg.com] > >> This is fine for now but I would prefer the Authors Addresses being a >> separate section rather than part of the Appendix cause that is how I >> have seen it in most RFCs including All the ForCES RFCs. > > the problem with what is currently possible is that it came before the > references when the regular authors section came after. > > [HK] This can be easily fixed in the final text, I think > > i would probably have to hack at xml2rfc to make it work. but i still > think it is against the rules proper - even if you got away with it on > the requirements. > > [HK] I don't think we got away with anything in the Requirements, I > wish > we had :-) > If you look at any of the ForCES RFCs (below) that we have so far, the > Authors Addresses are listed as a separate section, not as part of > Appendix. That's my only requirement, I would like to see this as some > section, not in the Appendix. And I agree that this section should be > after the references. > > > http://www.ietf.org/rfc/rfc3746.txt, > http://www.ietf.org/rfc/rfc3549.txt > > > Thanks > Hormuzd > > > > > _______________________________________________ > Forces-protocol mailing list > Forces-protocol@ietf.org > https://www1.ietf.org/mailman/listinfo/forces-protocol > _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol From forces-protocol-bounces@ietf.org Fri Oct 29 20:03:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27617 for ; Fri, 29 Oct 2004 20:03:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNgwc-00064g-0u for forces-protocol-web-archive@ietf.org; Fri, 29 Oct 2004 20:18:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNgb7-0008V3-Ss; Fri, 29 Oct 2004 19:55:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNgNP-0007VS-NZ for forces-protocol@megatron.ietf.org; Fri, 29 Oct 2004 19:41:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26506 for ; Fri, 29 Oct 2004 19:41:45 -0400 (EDT) Received: from znx208-2-156-007.znyx.com ([208.2.156.7] helo=lotus.znyx.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNgbn-0005j6-Hy for forces-protocol@ietf.org; Fri, 29 Oct 2004 19:56:39 -0400 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004102916453653:2300 ; Fri, 29 Oct 2004 16:45:36 -0700 Subject: Re: [Forces-protocol] RE: Resend: Feedback: Section 6.2 From: Jamal Hadi Salim To: "Khosravi, Hormuzd M" In-Reply-To: <468F3FDA28AA87429AD807992E22D07E031688E1@orsmsx408> References: <468F3FDA28AA87429AD807992E22D07E031688E1@orsmsx408> Organization: ZNYX Networks Message-Id: <1099093301.1039.4.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 29 Oct 2004 19:41:41 -0400 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/29/2004 04:45:37 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 10/29/2004 04:45:40 PM, Serialize complete at 10/29/2004 04:45:40 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: ram.gopal@nokia.com, Ligang Dong , forces-protocol@ietf.org, avri@psg.com, Weiming Wang , Robert Haas X-BeenThere: forces-protocol@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hadi@znyx.com List-Id: forces-protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: forces-protocol-bounces@ietf.org Errors-To: forces-protocol-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit On Fri, 2004-10-29 at 16:33, Khosravi, Hormuzd M wrote: > Ok, I see where the confusion is, the bitwise message representation is > in the correct format but the other format which you have drawn below is > not. This is a copy/paste error, I'll send out a fix to Avri. > ok, yes i see it to now ;-> I guess you were on one piece and i was on the other ;-> Theres still that other cruft still there: + LFB Instance ID and LFB Class ID should those just be set to 0x1? We already know thats where they are going. + Generaly, Type = operation, using the word "type" is confusing since it is also used in the main header. I dont think we can avoid using the word type in TLVs; my suggestion is we consider changing the main header type to "command". Thoughts? It is a command after all. + comment on SHOW applies here as well + "HBI will be exchanged with the CE using this LFB" ??? -6.2.2 Association Setup Response Message In the diagram, repeat of above: + LFB Instance ID and LFB Class ID should those just be set to 0x1? We already know thats where they are going. + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = operation Show | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ FE Object LFB (optional) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What is that? + "HBI will be exchanged with the CE using this LFB" ??? Robert said something in the concal on this, cant remember. + Type = T.reason ? This brings up that we need the following speacial TLVs. FORCES_REASON, FORCES_RESULT, FORCES_NAME. cheers, jamal _______________________________________________ Forces-protocol mailing list Forces-protocol@ietf.org https://www1.ietf.org/mailman/listinfo/forces-protocol