From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 1 01:33: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 BAA08017 for ; Wed, 1 Dec 2004 01:33:12 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZO8N-0007zw-I9 for forces-archive@IETF.ORG; Wed, 01 Dec 2004 01:38:40 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00EF7014@cherry.ease.lsoft.com>; Wed, 1 Dec 2004 1:33:04 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47441401 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 1 Dec 2004 01:32:58 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 1 Dec 2004 01:32:28 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iB16WWRC007321; Wed, 1 Dec 2004 06:32:32 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 iB16Niud008704; Wed, 1 Dec 2004 06:23:45 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 M2004113022323112245 ; Tue, 30 Nov 2004 22:32:31 -0800 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, 30 Nov 2004 22:32:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Meeting Minutes for IETF 61 ? Thread-Index: AcTFr8Ld1ZF4aL8ZQDmCYE+0DZEORQRv3svg X-OriginalArrivalTime: 01 Dec 2004 06:32:31.0539 (UTC) FILETIME=[8923E830:01C4D76F] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E0370F48C@orsmsx408> Date: Tue, 30 Nov 2004 22:32:30 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Meeting Minutes for IETF 61 ? Comments: To: "Putzolu, David" , Patrick Droz To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Hi All, Could someone post the final meeting minutes for IETF 61 ? Thanks Hormuzd=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Putzolu, David Sent: Monday, November 08, 2004 8:27 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: [FORCES] Updated Agenda, ForCES Meeting @ IETF 61 All, Below is the current agenda for the ForCES meeting being held later today at IETF 61. -David --- Forwarding and Control Element Separation (ForCES)=20 Agenda, IETF 61 Monday, November 8, 2004, 1300-1500 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CHAIRS: David Putzolu Patrick Droz ADs: Alex Zinin Bill Fenner =20 DRAFT AGENDA: 5 min - WG status & Agenda Bash - chairs 30 min - ForCES Protocol Draft Status & Changes - Jamal Hadi Salim=20 draft-forces-protocol-01.txt 20 min - Options for LFB-level multicast and related issues - Robert Haas (no draft available) 15 min - IP TML Proposal - Alex Audu draft-audu-forces-iptml-00.txt 20 min - TIPC Transport Mapping Layer Proposal - Jon Maloy draft-maloy-tipc-01.txt 5 min - ForCES IP TML Proposal - Furquan Ansari draft-khosravi-tcptml-00.txt 15 min - ForCES Element Discovery Proposal - Furquan Ansari draft-ansari-forces-discovery-01.txt 10 min - Flexinet EU ForCES Protocol Implementation Experience - Robert Haas (no draft available) (Updated November 8, 2004) From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 1 09:01: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 JAA29945 for ; Wed, 1 Dec 2004 09:01:17 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZV86-0000fK-MU for forces-archive@IETF.ORG; Wed, 01 Dec 2004 09:06:51 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00EF78CD@cherry.ease.lsoft.com>; Wed, 1 Dec 2004 9:01:18 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47503823 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 1 Dec 2004 09:01:14 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 1 Dec 2004 09:00: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 2004120106035523:43254 ; Wed, 1 Dec 2004 06:03:55 -0800 References: <468F3FDA28AA87429AD807992E22D07E036776DF@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/01/2004 06:03:55 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/01/2004 06:03:58 AM, Serialize complete at 12/01/2004 06:03:58 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1101905159.1042.49.camel@jzny.localdomain> Date: Wed, 1 Dec 2004 07:45:59 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 7] All PL messages addressed to only LFBs? To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E036776DF@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit On Mon, 2004-11-29 at 00:23, Khosravi, Hormuzd M wrote: > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > Note, These are two different grammars. > BTW, are you dropping the Association message from that list? Good. We are back on track. > I think we may need to add text that when the message comes from the > FE->CE that infact the LFB selector refers to the source LFB+instance > and not destination. Would this help? > > [HK] Yes, this would clear up the confusion. We should also add text > stating that for CE->FE msgs the LFB selector refers to the destination > LFB, we don't have any text which states that either...but you had > assumed this, thus there was the confusion about FE->CE msgs Ok. I have opened ID#8 on the tracker. > [HK] The only exception is for HB msg, which we have discussed in great > detail before. < > We have probably exchanged a dozen emails on the protocol > list and even discussed it in one of our conf calls, so if you refer to > those or recall the discussion (it was done for efficiency reasons in > this case), it will be pretty clear. > Which i disagree on - I suppose thats why we are having this discussion to begin with. I oppose any exceptions. I have stated my reasons why i oppose this in most of my previous emails on the subject (I could repeat them if needed). cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 3 04:02: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 EAA13639 for ; Fri, 3 Dec 2004 04:02:13 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca9Q6-0006Pp-2V for forces-archive@IETF.ORG; Fri, 03 Dec 2004 04:08:08 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00EFA7D2@cherry.ease.lsoft.com>; Fri, 3 Dec 2004 4:02:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47769777 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 3 Dec 2004 04:02:00 -0500 Approved-By: dro@ZURICH.IBM.COM Received: from 195.212.29.153 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 3 Dec 2004 03:55:52 -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 iB38tqvU221352 for ; Fri, 3 Dec 2004 08:55:52 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB38tlG8127116 for ; Fri, 3 Dec 2004 09:55:47 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB38tqoR002348 for ; Fri, 3 Dec 2004 09:55:52 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id iB38tqLO002342 for ; Fri, 3 Dec 2004 09:55:52 +0100 Received: from zurich.ibm.com (dhcp69-169.zurich.ibm.com [9.4.69.169]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA50882; Fri, 3 Dec 2004 09:55:51 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000507040805050708070005" Message-ID: <41B02A17.9070206@zurich.ibm.com> Date: Fri, 3 Dec 2004 09:55:51 +0100 Reply-To: Patrick Droz Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: tentative ForCES minutes from the IETF61 in DC To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c This is a cryptographically signed message in MIME format. --------------ms000507040805050708070005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit attached are the tentative meeting minutes from the ForCES meeting in DC at the IETF61. Please report changes and extensions to me. Thanks to Avri for taking minutes at the meeting. Regards, Patrick Minutes ForCES WG at the IETF61 in Washington DC, USA ----------------------------------------------------- Agenda, IETF 61 Monday, November 8, 2004, 1300-1500 ==================================== CHAIRS: David Putzolu Patrick Droz ADs: Alex Zinin Bill Fenner AGENDA: 5 min - WG status & Agenda Bash - chairs 30 min - ForCES Protocol Draft Status & Changes Jamal Hadi Salim draft-forces-protocol-01.txt 10 min - ForCES LFB Path Discussion Robert Haas on behalf of Weiming Wang (no draft available) 20 min - Options for LFB-level multicast and related issues Robert Haas (no draft available) 15 min - IP TML Proposal Alex Audu draft-audu-forces-iptml-00.txt 20 min - TIPC Transport Mapping Layer Proposal Jon Maloy draft-maloy-tipc-01.txt 5 min - ForCES IP TML Proposal Furquan Ansari draft-khosravi-tcptml-00.txt 15 min - ForCES Element Discovery Proposal Furquan Ansari draft-ansari-forces-discovery-01.txt 10 min - Flexinet EU ForCES Protocol Implementation Experience Robert Haas (no draft available) Attendees: 50 Minutes: The chairs began the meeting by reviewing the agenda and then going over the status of the group. It was stated the the protocol was expected to go through 1 or 2 more drafts before going to WG Last Call. Jamal gave a presentation on the protocol covering both the current structure and the open issues. He asked for comments on the open issues: - possibly adding a CE protocol LFB but that is still an open question - open issue on how path data is recorded. - controversial issues: -what is a path: - a map to a targeted entity - or 32 identifier similar to SMI OID - issue of how to access multiple rows - open question of whether content based access possible - packing/transport of path referenced data. Authors are looking for input on all the issues Q.- are they all in tracker - A. believe so, will check At the moment there are 8 open issues on the on the list: http://www.mip4.org/issues/tracker/forces/ There was no further discussion on the protocol draft ............................................................... Robert presents on behalf on Weiming the status of the Path LFB path discussion. Joel - Weiming is very concerned that subscripting include explicitly what field being used as index. He has a valuable point but I am not sure I got it. By what is Weiming subscripting - regular subscript - content field Joel believes every table should have a regular subscript. Weiming has the opinion that we need to explicitly indicate what we are using for selection. Joel comment: assume we have specified what you are going subscript, but where is the subscript to be found? or is there another sequence of information that indicates where the subscript is found? Joel wonder whether one must always have explicit indices that are index based and content (field ) based. A path should always have attributes and the fields. Joel thinks semantically putting it in the data is the wrong place. We need a clear indication what the target of operation is. Jamal wants closure of the discussion. Robert is not sure he sees the difference. David - need to resolve over the next few weeks probably best is to setup a call with Weiming to discuss. .................................................................. Robert presented options for LFB-level multicast and related issues. The question is how does one set information into several LFBs. There are three ways of doing multicast: 1) merged multicast: use PL-level multicast for LFB multicasting 2) split multicast that needs both PL level and LFB level (proposal from Joel, Steven) 3) xcast that only has unicast PL messages, list of LFB explicitly included in message proposal from Weiming Q: can you multicast to all LFBs of a given class. A: as is no, but if it is important we should find a way to support it. .............................................................. Alex presents the TML draft. He starts with the TML functions and design criteria such as simplicity, statelessness, security and trust model. Joel is surprised by what he found in the TML draft. He is looking for how to really do it. Either select a protocol with a transport or use TCP with explanation of how to transport. A: Well it is an API Joel: we need to find the transport David: this needs to be added Joel: that is where they should start David; so you are talking about a service access point Jamal: I was going to write a draft on this Joel: a service definition has to exist jamal: do we expect to see two different vendors to provide a TML and a PL At this point the lengthy discussion of what this draft should be was taken off line. But further questions came: Joel: I am missing the semantics of the join message. Why do we need TML level join message. Critical piece are missing, what is carrying the message. Alex: what transport do you want to map to Joel: well what transport do you want to map to. You must pick what the transport is: Jamal: this is a first cut. Joel: but this should have come first. This discussion was again take off line. Q; why only one way authentication A: Feels that the CE should be trusted. Q: there are several different models Jamal: there are several different trust models Q: what if there is a CE spoofer, could take over the network A: but FE initiated so it should know who it is initiating to. ................................................................. John Malloy presents TIPC. It is a transport protocol connection less and connection oriented Reliable and unreliable including multicast. Can be reliable in one direction And unreliable in the other direction. The protocol does not have any security Features. It is assumed to be operated in a trusted environment. It does have congestion control. They have control and data connections which have lower priority. The main purpose of the draft is to promote TIPC as the TML for ForCES. ............................................................... Furquan presented a TCP/IP based TML for ForCES. Control and data connections are used. Security is provided through TLS. It also supports prioritization and it protects against DoS attacks. David: the draft needs more details explaining how it should be used. Only very few people had read it so consideration as a WG was deferred to the list. ............................................................... Finally Robert presented the FlexiNET project. FlexiNET is a EU project that will make use of ForCES. The objective of FlexiNET is to accelerate the introduction of next generation marketable services, and increase the competitiveness in the telecom field by facilitating the broadening of current business model for services provisioning and exploitation. -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 --------------ms000507040805050708070005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAe3eMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDQwOTA4MDgyOTEwWhcNMDUwOTIyMDgyOTEwWjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCMCH7XfNWjsk4/JLer GkIF+4NOltUEjJ5tpFUpAznm3q1gLpks5Hq9AiZ0NROrS/leyppP29dNJsUEVnO9dwyfQUWh Hk3VlPDuNneKhbvfDoYyJRxhp+Lpnw5uBtLpvm0RXKttbw3XCUPCcyMs046Y1m5+XunUotEF 7Fvci8/n8QIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFD/OrZ9kTj9WbmJ+g8txJM0UxO3hMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQAXIgUJHKxCg7P4f12BKKBShLMk+9LWTKoYj0J/txL+A8XNM2EFSKQpbQJKmnh5 lmAUaMd64LC0OokYfRWh4WFazM0nNfGFAHto6glO15GtPgIzRJY3gD18AvwiKuaWED7N1aLI P2/hfbLBrG++uh6agT2wLtTLdrFTHOwKTsPGRTCCAyQwggKNoAMCAQICAwHt3jANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTA0MDkwODA4MjkxMFoXDTA1MDkyMjA4MjkxMFowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAjAh+13zVo7JOPyS3qxpC BfuDTpbVBIyebaRVKQM55t6tYC6ZLOR6vQImdDUTq0v5XsqaT9vXTSbFBFZzvXcMn0FFoR5N 1ZTw7jZ3ioW73w6GMiUcYafi6Z8ObgbS6b5tEVyrbW8N1wlDwnMjLNOOmNZufl7p1KLRBexb 3IvP5/ECAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBQ/zq2fZE4/Vm5ifoPLcSTNFMTt4TAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAFyIFCRysQoOz+H9dgSigUoSzJPvS1kyqGI9Cf7cS/gPFzTNhBUikKW0CSpp4eZZg FGjHeuCwtDqJGH0VoeFhWszNJzXxhQB7aOoJTteRrT4CM0SWN4A9fAL8IirmlhA+zdWiyD9v 4X2ywaxvvroemoE9sC7Uy3axUxzsCk7DxkUxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEyMDMw ODU1NTFaMCMGCSqGSIb3DQEJBDEWBBQu4TIMi05aFhSTK+3ADWdZw1qupDBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwHt3jANBgkqhkiG9w0BAQEFAASBgA8r0iA9zXmCv1DfGFkVFPvglkulHuc9spzA BhVZj33SKc2IyNeZARSIIQP7zi9ueP0e+ouDEuDeCmdacAr8aY36pBWe7zMFwEN3WJfL5uOF gVUV14l4GQFXNW0J5wQZcPoyY1fdTAcEYLD7r3UAQ9aDmPD3lZgXGlA/cAg3Zb6iAAAAAAAA --------------ms000507040805050708070005-- From owner-forces@PEACH.EASE.LSOFT.COM Tue Dec 7 16:01: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 QAA20404 for ; Tue, 7 Dec 2004 16:01:29 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbmZK-0006M3-JN for forces-archive@IETF.ORG; Tue, 07 Dec 2004 16:08:23 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00F0127E@cherry.ease.lsoft.com>; Tue, 7 Dec 2004 16:01:26 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48040832 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 7 Dec 2004 16:01:24 -0500 Approved-By: ellen.m.deleganes@INTEL.COM Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 7 Dec 2004 16:00:39 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iB7L0cPR017789 for ; Tue, 7 Dec 2004 21:00:38 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iB7L0TaB009894 for ; Tue, 7 Dec 2004 21:00:38 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 M2004120713003830085 for ; Tue, 07 Dec 2004 13:00:38 -0800 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, 7 Dec 2004 13:00:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Model document Thread-Index: AcTcn/QvFvtRnBeATp6AIEueem7wKw== X-OriginalArrivalTime: 07 Dec 2004 21:00:27.0603 (UTC) FILETIME=[C75F2A30:01C4DC9F] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E0387DC16@orsmsx408> Date: Tue, 7 Dec 2004 13:01:43 -0800 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: Model document To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable I am starting to look at the FE model document. To start, I've removed the LFB class definitions and have them in a separate document. If you would like for me just to post the class definitions to the reflector, I'll do so. Currently, they are in a word document, but can be converted to a .txt file. While doing so, I noticed that the previous section in the model document is titled "Model and Schema for LFB Classes". I think it would make sense to put the schema with the document describing the LFB class definitions. At least some description of the model should probably remain with the model document. Anyone have comments about this?=20 The outstanding tasks the model team had for this document last summer are as follows: * Harmonize sections 4 & 5 to use a similar textual and organizational approach (Joel and Zsolt were to agree on an approach and to update their sections as needed)=20 * Put a total view of the schema in one place (Joel and Zsolt) * Clean up the overall text (Ellen) * Address comments/issues from the reflector (All) The main reason that the model team held off taking the draft to last call this year was to wait for the protocol draft to get a little more stable. We wanted to make sure the model draft stayed synchronized with the protocol draft. Now that the issues are settling down, we should make sure that we make forward progress again. Regards, Ellen Deleganes From owner-forces@PEACH.EASE.LSOFT.COM Tue Dec 7 16:12: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 QAA21770 for ; Tue, 7 Dec 2004 16:12:52 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbmk1-0006gq-PE for forces-archive@IETF.ORG; Tue, 07 Dec 2004 16:19:46 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F01258@cherry.ease.lsoft.com>; Tue, 7 Dec 2004 16:12:31 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48040732 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 7 Dec 2004 16:12:28 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 7 Dec 2004 16:07:10 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8162102 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 07 Dec 2004 16:07:09 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E0387DC16@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041207160106.04003458@localhost> Date: Tue, 7 Dec 2004 16:03:10 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Model document To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0387DC16@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 I believe that the schema needs to remain in the base model document. There will (I expect) be multiple LFB Class library documents. The one we produce will only be the first. So it will work much better if the schema is in once place, referenced by all the library docs. The model doc is the obvious place to do that. When we work over the schema, one thing we have to do is add the identifiers to be used by the protocol. Yours, Joel At 04:01 PM 12/7/2004, Deleganes, Ellen M wrote: >I am starting to look at the FE model document. To start, I've removed >the LFB class definitions and have them in a separate document. If you >would like for me just to post the class definitions to the reflector, >I'll do so. Currently, they are in a word document, but can be converted >to a .txt file. While doing so, I noticed that the previous section in >the model document is titled "Model and Schema for LFB Classes". I think >it would make sense to put the schema with the document describing the >LFB class definitions. At least some description of the model should >probably remain with the model document. Anyone have comments about >this? > >The outstanding tasks the model team had for this document last summer >are as follows: > >* Harmonize sections 4 & 5 to use a similar textual and organizational >approach (Joel and Zsolt were to agree on an approach and to update >their sections as needed) >* Put a total view of the schema in one place (Joel and Zsolt) >* Clean up the overall text (Ellen) >* Address comments/issues from the reflector (All) > >The main reason that the model team held off taking the draft to last >call this year was to wait for the protocol draft to get a little more >stable. We wanted to make sure the model draft stayed synchronized with >the protocol draft. Now that the issues are settling down, we should >make sure that we make forward progress again. > >Regards, >Ellen Deleganes From owner-forces@PEACH.EASE.LSOFT.COM Tue Dec 7 17:01: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 RAA04156 for ; Tue, 7 Dec 2004 17:01:01 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbnUy-0001os-67 for forces-archive@IETF.ORG; Tue, 07 Dec 2004 17:07:56 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00F0136C@cherry.ease.lsoft.com>; Tue, 7 Dec 2004 17:00:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48045209 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 7 Dec 2004 17:00:47 -0500 Approved-By: lily.l.yang@INTEL.COM Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 7 Dec 2004 16:58:56 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iB7LwuYe021970 for ; Tue, 7 Dec 2004 21:58:56 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iB7LwPaH007803 for ; Tue, 7 Dec 2004 21:58:56 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 M2004120713585510783 for ; Tue, 07 Dec 2004 13:58:55 -0800 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, 7 Dec 2004 13:58:55 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Model document Thread-Index: AcTcoX0gn2FbkK7DRHaLA+PJ6wWB0wABmFaA X-OriginalArrivalTime: 07 Dec 2004 21:58:55.0804 (UTC) FILETIME=[F26C27C0:01C4DCA7] X-Scanned-By: MIMEDefang 2.44 Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE01837104@orsmsx408> Date: Tue, 7 Dec 2004 13:58:54 -0800 Reply-To: "Yang, Lily L" Sender: Forwarding and Control Element Separation From: "Yang, Lily L" Subject: Re: Model document To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Yes, the schema should stay in the base model doc. > -----Original Message----- > From: Forwarding and Control Element Separation=20 > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > Sent: Tuesday, December 07, 2004 1:03 PM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: Model document >=20 > I believe that the schema needs to remain in the base model=20 > document. There will (I expect) be multiple LFB Class=20 > library documents. The one we produce will only be the=20 > first. So it will work much better if the schema is in once=20 > place, referenced by all the library docs. The model doc is=20 > the obvious place to do that. >=20 > When we work over the schema, one thing we have to do is add=20 > the identifiers to be used by the protocol. >=20 > Yours, > Joel >=20 > At 04:01 PM 12/7/2004, Deleganes, Ellen M wrote: > >I am starting to look at the FE model document. To start,=20 > I've removed=20 > >the LFB class definitions and have them in a separate=20 > document. If you=20 > >would like for me just to post the class definitions to the=20 > reflector,=20 > >I'll do so. Currently, they are in a word document, but can be=20 > >converted to a .txt file. While doing so, I noticed that the=20 > previous=20 > >section in the model document is titled "Model and Schema for LFB=20 > >Classes". I think it would make sense to put the schema with the=20 > >document describing the LFB class definitions. At least some=20 > >description of the model should probably remain with the model=20 > >document. Anyone have comments about this? > > > >The outstanding tasks the model team had for this document=20 > last summer=20 > >are as follows: > > > >* Harmonize sections 4 & 5 to use a similar textual and=20 > organizational=20 > >approach (Joel and Zsolt were to agree on an approach and to update=20 > >their sections as needed) > >* Put a total view of the schema in one place (Joel and Zsolt) > >* Clean up the overall text (Ellen) > >* Address comments/issues from the reflector (All) > > > >The main reason that the model team held off taking the=20 > draft to last=20 > >call this year was to wait for the protocol draft to get a=20 > little more=20 > >stable. We wanted to make sure the model draft stayed=20 > synchronized with=20 > >the protocol draft. Now that the issues are settling down, we should=20 > >make sure that we make forward progress again. > > > >Regards, > >Ellen Deleganes >=20 From owner-forces@PEACH.EASE.LSOFT.COM Tue Dec 7 17:02: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 RAA04396 for ; Tue, 7 Dec 2004 17:02:35 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbnWU-0001tV-9p for forces-archive@IETF.ORG; Tue, 07 Dec 2004 17:09:30 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00F013F1@cherry.ease.lsoft.com>; Tue, 7 Dec 2004 17:02:37 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48045923 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 7 Dec 2004 17:02:30 -0500 Approved-By: zsolt@MODULARNET.COM Received: from 66.235.180.58 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 7 Dec 2004 17:01:55 -0500 Received: from rdu74-167-053.nc.rr.com ([24.74.167.53] helo=[192.168.2.3]) by server87.totalchoicehosting.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1CbnOz-00009R-A2; Tue, 07 Dec 2004 17:01:45 -0500 References: <468F3FDA28AA87429AD807992E22D07E0387DC16@orsmsx408> Content-Type: text/plain Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server87.totalchoicehosting.com X-AntiAbuse: Original Domain - peach.ease.lsoft.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - modularnet.com Message-ID: <1102456877.4303.777.camel@localhost.localdomain> Date: Tue, 7 Dec 2004 17:01:17 -0500 Reply-To: Zsolt Haraszti Sender: Forwarding and Control Element Separation From: Zsolt Haraszti Subject: Re: Model document Comments: To: "Deleganes, Ellen M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0387DC16@orsmsx408> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit I agree with Joel, the schema should stay in the model document. Joel, I will reload my cache in a few days and will make an attempt to augment the schema with the right IDs. There were a couple of other changes we wanted (e.g., x-referencing some attributes and capabilities) too. /zsolt On Tue, 2004-12-07 at 16:01, Deleganes, Ellen M wrote: > I am starting to look at the FE model document. To start, I've removed > the LFB class definitions and have them in a separate document. If you > would like for me just to post the class definitions to the reflector, > I'll do so. Currently, they are in a word document, but can be converted > to a .txt file. While doing so, I noticed that the previous section in > the model document is titled "Model and Schema for LFB Classes". I think > it would make sense to put the schema with the document describing the > LFB class definitions. At least some description of the model should > probably remain with the model document. Anyone have comments about > this? > > The outstanding tasks the model team had for this document last summer > are as follows: > > * Harmonize sections 4 & 5 to use a similar textual and organizational > approach (Joel and Zsolt were to agree on an approach and to update > their sections as needed) > * Put a total view of the schema in one place (Joel and Zsolt) > * Clean up the overall text (Ellen) > * Address comments/issues from the reflector (All) > > The main reason that the model team held off taking the draft to last > call this year was to wait for the protocol draft to get a little more > stable. We wanted to make sure the model draft stayed synchronized with > the protocol draft. Now that the issues are settling down, we should > make sure that we make forward progress again. > > Regards, > Ellen Deleganes -- Zsolt Haraszti Phone: +1 919-765-0027/2017 Modular Networks Mobile: +1 919-522-2337 Email: zsolt@modularnet.com From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 8 04:20: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 EAA05057 for ; Wed, 8 Dec 2004 04:20:17 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cby6O-0000DA-9u for forces-archive@IETF.ORG; Wed, 08 Dec 2004 04:27:17 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F021DD@cherry.ease.lsoft.com>; Wed, 8 Dec 2004 4:20:16 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48099487 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 8 Dec 2004 04:20:14 -0500 Approved-By: dro@ZURICH.IBM.COM Received: from 195.212.29.134 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 8 Dec 2004 04:18:05 -0500 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iB89HXVQ298900; Wed, 8 Dec 2004 09:17:33 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB89HeTw062626; Wed, 8 Dec 2004 09:17:41 GMT Received: from zurich.ibm.com (dhcp71-77.zurich.ibm.com [9.4.71.77]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA38876; Wed, 8 Dec 2004 10:17:31 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060100010406020801090206" Message-ID: <41B6C6AB.7020308@zurich.ibm.com> Date: Wed, 8 Dec 2004 10:17:31 +0100 Reply-To: Patrick Droz Sender: Forwarding and Control Element Separation From: Patrick Droz Organization: IBM Research Subject: ForCES minutes from the IETF61 in DC Comments: To: proceedings@ietf.org To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 This is a cryptographically signed message in MIME format. --------------ms060100010406020801090206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Minutes ForCES WG at the IETF61 in Washington DC, USA ----------------------------------------------------- Agenda, IETF 61 Monday, November 8, 2004, 1300-1500 ==================================== CHAIRS: David Putzolu Patrick Droz ADs: Alex Zinin Bill Fenner AGENDA: 5 min - WG status & Agenda Bash - chairs 30 min - ForCES Protocol Draft Status & Changes Jamal Hadi Salim draft-forces-protocol-01.txt 10 min - ForCES LFB Path Discussion Robert Haas on behalf of Weiming Wang (no draft available) 20 min - Options for LFB-level multicast and related issues Robert Haas (no draft available) 15 min - IP TML Proposal Alex Audu draft-audu-forces-iptml-00.txt 20 min - TIPC Transport Mapping Layer Proposal Jon Maloy draft-maloy-tipc-01.txt 5 min - ForCES IP TML Proposal Furquan Ansari draft-khosravi-tcptml-00.txt 15 min - ForCES Element Discovery Proposal Furquan Ansari draft-ansari-forces-discovery-01.txt 10 min - Flexinet EU ForCES Protocol Implementation Experience Robert Haas (no draft available) Attendees: 50 Minutes: The chairs began the meeting by reviewing the agenda and then going over the status of the group. It was stated the the protocol was expected to go through 1 or 2 more drafts before going to WG Last Call. Jamal gave a presentation on the protocol covering both the current structure and the open issues. He asked for comments on the open issues: - possibly adding a CE protocol LFB but that is still an open question - open issue on how path data is recorded. - controversial issues: -what is a path: - a map to a targeted entity - or 32 identifier similar to SMI OID - issue of how to access multiple rows - open question of whether content based access possible - packing/transport of path referenced data. Authors are looking for input on all the issues Q.- are they all in tracker - A. believe so, will check At the moment there are 8 open issues on the on the list: http://www.mip4.org/issues/tracker/forces/ There was no further discussion on the protocol draft ............................................................... Robert presents on behalf on Weiming the status of the Path LFB path discussion. Joel - Weiming is very concerned that subscripting include explicitly what field being used as index. He has a valuable point but I am not sure I got it. By what is Weiming subscripting - regular subscript - content field Joel believes every table should have a regular subscript. Weiming has the opinion that we need to explicitly indicate what we are using for selection. Joel comment: assume we have specified what you are going subscript, but where is the subscript to be found? or is there another sequence of information that indicates where the subscript is found? Joel wonder whether one must always have explicit indices that are index based and content (field ) based. A path should always have attributes and the fields. Joel thinks semantically putting it in the data is the wrong place. We need a clear indication what the target of operation is. Jamal wants closure of the discussion. Robert is not sure he sees the difference. David - need to resolve over the next few weeks probably best is to setup a call with Weiming to discuss. .................................................................. Robert presented options for LFB-level multicast and related issues. The question is how does one set information into several LFBs. There are three ways of doing multicast: 1) merged multicast: use PL-level multicast for LFB multicasting 2) split multicast that needs both PL level and LFB level (proposal from Joel, Steven) 3) xcast that only has unicast PL messages, list of LFB explicitly included in message proposal from Weiming Q: can you multicast to all LFBs of a given class. A: as is no, but if it is important we should find a way to support it. .............................................................. Alex presents the TML draft. He starts with the TML functions and design criteria such as simplicity, statelessness, security and trust model. Joel is surprised by what he found in the TML draft. He is looking for how to really do it. Either select a protocol with a transport or use TCP with explanation of how to transport. A: Well it is an API Joel: we need to find the transport David: this needs to be added Joel: that is where they should start David; so you are talking about a service access point Jamal: I was going to write a draft on this Joel: a service definition has to exist jamal: do we expect to see two different vendors to provide a TML and a PL At this point the lengthy discussion of what this draft should be was taken off line. But further questions came: Joel: I am missing the semantics of the join message. Why do we need TML level join message. Critical piece are missing, what is carrying the message. Alex: what transport do you want to map to Joel: well what transport do you want to map to. You must pick what the transport is: Jamal: this is a first cut. Joel: but this should have come first. This discussion was again take off line. Q; why only one way authentication A: Feels that the CE should be trusted. Q: there are several different models Jamal: there are several different trust models Q: what if there is a CE spoofer, could take over the network A: but FE initiated so it should know who it is initiating to. ................................................................. John Malloy presents TIPC. It is a transport protocol connection less and connection oriented Reliable and unreliable including multicast. Can be reliable in one direction And unreliable in the other direction. The protocol does not have any security Features. It is assumed to be operated in a trusted environment. It does have congestion control. They have control and data connections which have lower priority. The main purpose of the draft is to promote TIPC as the TML for ForCES. ............................................................... Furquan presented a TCP/IP based TML for ForCES. Control and data connections are used. Security is provided through TLS. It also supports prioritization and it protects against DoS attacks. David: the draft needs more details explaining how it should be used. ............................................................... In a second presentation Furquan presented a draft on ForCES Element Discovery Proposal. Only very few people had read it so consideration as a WG was deferred to the list. The content of the draft falls under the current ForCES charter. ............................................................... Finally Robert presented the FlexiNET project. FlexiNET is a EU project that will make use of ForCES. The objective of FlexiNET is to accelerate the introduction of next generation marketable services, and increase the competitiveness in the telecom field by facilitating the broadening of current business model for services provisioning and exploitation. -- Dr. Patrick Droz | dro@zurich.ibm.com IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro Saumerstrasse 4 | Tel. +41-1-724-85-25 CH-8803 Rueschlikon/Switzerland | Fax. +41-1-724-85-78 --------------ms060100010406020801090206 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJLjCC AtowggJDoAMCAQICAwMUtjANBgkqhkiG9w0BAQQFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9y aXR5MB4XDTAyMDExNDIyMDcxMVoXDTExMTIzMTIyMDcxMVowaTELMAkGA1UEBhMCVVMxNDAy BgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5lc3MgTWFjaGluZXMgQ29ycG9yYXRpb24xJDAi BgNVBAMTG0lCTSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA629xc49NpAPzcAsuShTImLRYMkyepDEkC1UrPbsFRyAFZKsv3pw0MGfW/+7g lzJKgPkPzlTZZfznznGbmAWVnNBQlyPasOtCjif603euRXReHcKfHMPLItKozibWIPHJuOnw NclOnnP2sKufuPzbTImQTTi5c8JZNZcMJ0YFzTcCAwEAAaOBqjCBpzARBglghkgBhvhCAQEE BAMCAIcwDgYDVR0PAQH/BAQDAgHGMB0GA1UdDgQWBBSuVA6S6qgzqSskLcfIbzDc3vNKQDAf BgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MDEGA1Ud JQQqMCgGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3 DQEBBAUAA4GBADJye3NmC8q2PzypRZfu7JvDRDX1rRcanZvujQupk2oCScMd3FIHLE7hOfu8 YffvxtLU3y8wNamQEORjTD175qAffryXypwtiVjBUKSDlBCQ14keMcF9ViNdewEoBGiAycUq 8R3Lrlf4TCDvW4GeguNTFFZnS0ygYATiJk7iDyvEMIIDJDCCAo2gAwIBAgIDAe3eMA0GCSqG SIb3DQEBBAUAMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2lu ZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwHhcNMDQwOTA4MDgyOTEwWhcNMDUwOTIyMDgyOTEwWjCBgzELMAkGA1UEBhMC VVMxDDAKBgNVBAoTA0lCTTERMA8GA1UECxMIRU1QTE9ZRUUxFTATBgNVBAMTDFBhdHJpY2sg RHJvejEZMBcGCgmSJomT8ixkAQETCTMzMTkwMzg0ODEhMB8GCSqGSIb3DQEJARYSZHJvQHp1 cmljaC5pYm0uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCMCH7XfNWjsk4/JLer GkIF+4NOltUEjJ5tpFUpAznm3q1gLpks5Hq9AiZ0NROrS/leyppP29dNJsUEVnO9dwyfQUWh Hk3VlPDuNneKhbvfDoYyJRxhp+Lpnw5uBtLpvm0RXKttbw3XCUPCcyMs046Y1m5+XunUotEF 7Fvci8/n8QIDAQABo4G+MIG7MBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMCBeAw HQYDVR0OBBYEFD/OrZ9kTj9WbmJ+g8txJM0UxO3hMC0GA1UdEQQmMCSgIgYKKwYBBAGCNxQC A6AUDBJkcm9AenVyaWNoLmlibS5jb20wHwYDVR0jBBgwFoAUrlQOkuqoM6krJC3HyG8w3N7z SkAwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDANBgkqhkiG9w0B AQQFAAOBgQAXIgUJHKxCg7P4f12BKKBShLMk+9LWTKoYj0J/txL+A8XNM2EFSKQpbQJKmnh5 lmAUaMd64LC0OokYfRWh4WFazM0nNfGFAHto6glO15GtPgIzRJY3gD18AvwiKuaWED7N1aLI P2/hfbLBrG++uh6agT2wLtTLdrFTHOwKTsPGRTCCAyQwggKNoAMCAQICAwHt3jANBgkqhkiG 9w0BAQQFADBpMQswCQYDVQQGEwJVUzE0MDIGA1UEChMrSW50ZXJuYXRpb25hbCBCdXNpbmVz cyBNYWNoaW5lcyBDb3Jwb3JhdGlvbjEkMCIGA1UEAxMbSUJNIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MB4XDTA0MDkwODA4MjkxMFoXDTA1MDkyMjA4MjkxMFowgYMxCzAJBgNVBAYTAlVT MQwwCgYDVQQKEwNJQk0xETAPBgNVBAsTCEVNUExPWUVFMRUwEwYDVQQDEwxQYXRyaWNrIERy b3oxGTAXBgoJkiaJk/IsZAEBEwkzMzE5MDM4NDgxITAfBgkqhkiG9w0BCQEWEmRyb0B6dXJp Y2guaWJtLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAjAh+13zVo7JOPyS3qxpC BfuDTpbVBIyebaRVKQM55t6tYC6ZLOR6vQImdDUTq0v5XsqaT9vXTSbFBFZzvXcMn0FFoR5N 1ZTw7jZ3ioW73w6GMiUcYafi6Z8ObgbS6b5tEVyrbW8N1wlDwnMjLNOOmNZufl7p1KLRBexb 3IvP5/ECAwEAAaOBvjCBuzARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgXgMB0G A1UdDgQWBBQ/zq2fZE4/Vm5ifoPLcSTNFMTt4TAtBgNVHREEJjAkoCIGCisGAQQBgjcUAgOg FAwSZHJvQHp1cmljaC5pYm0uY29tMB8GA1UdIwQYMBaAFK5UDpLqqDOpKyQtx8hvMNze80pA MCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEFBQcDAwYIKwYBBQUHAwQwDQYJKoZIhvcNAQEE BQADgYEAFyIFCRysQoOz+H9dgSigUoSzJPvS1kyqGI9Cf7cS/gPFzTNhBUikKW0CSpp4eZZg FGjHeuCwtDqJGH0VoeFhWszNJzXxhQB7aOoJTteRrT4CM0SWN4A9fAL8IirmlhA+zdWiyD9v 4X2ywaxvvroemoE9sC7Uy3axUxzsCk7DxkUxggLQMIICzAIBATBwMGkxCzAJBgNVBAYTAlVT MTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9u MSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jAJBgUrDgMCGgUA oIIBtjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEyMDgw OTE3MzFaMCMGCSqGSIb3DQEJBDEWBBR4WNLcpH5ScWwpibR+eV83nZILMjBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDB/BgkrBgEEAYI3EAQxcjBwMGkxCzAJBgNVBAYTAlVTMTQw MgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIE1hY2hpbmVzIENvcnBvcmF0aW9uMSQw IgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCAwHt3jCBgQYLKoZIhvcNAQkQ AgsxcqBwMGkxCzAJBgNVBAYTAlVTMTQwMgYDVQQKEytJbnRlcm5hdGlvbmFsIEJ1c2luZXNz IE1hY2hpbmVzIENvcnBvcmF0aW9uMSQwIgYDVQQDExtJQk0gQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkCAwHt3jANBgkqhkiG9w0BAQEFAASBgBx2GUpvBJZODAIE4bKiyi5oaJXM2SLMD090 UHkamoEIf7xgO5fO0C/GA7wUFS3NT1UDdMhgI/xfh5QKCVFqK51/aJcausylzN+fTHW06/ey Gb/21yq+8FgwsuHqysnlQ9/bSuFRY7C6piPP0Pr9Zt2PNlJc9XrPTb1ZOADjyLmmAAAAAAAA --------------ms060100010406020801090206-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 8 18:19: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 SAA23246 for ; Wed, 8 Dec 2004 18:19:37 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcBCn-0004xR-5C for forces-archive@IETF.ORG; Wed, 08 Dec 2004 18:26:46 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00F033D3@cherry.ease.lsoft.com>; Wed, 8 Dec 2004 18:19:34 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48211858 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 8 Dec 2004 18:19:32 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 8 Dec 2004 18:18:49 -0500 Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iB8NImbM027307; Wed, 8 Dec 2004 23:18:48 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 iB8NNCaX025110; Wed, 8 Dec 2004 23:23:20 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 M2004120815184731864 ; Wed, 08 Dec 2004 15:18:48 -0800 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, 8 Dec 2004 15:18:47 -0800 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_01C4DD7C.449FFF10" X-MS-Has-Attach: yes Thread-Topic: [FORCES] [issue 7] All PL messages addressed to only LFBs? Thread-Index: AcTXrj4eB/E8xZXARZW9PsNRzBVdJgFzHerw X-OriginalArrivalTime: 08 Dec 2004 23:18:47.0865 (UTC) FILETIME=[45206290:01C4DD7C] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Message-ID: <468F3FDA28AA87429AD807992E22D07E038BF65C@orsmsx408> Date: Wed, 8 Dec 2004 15:18:46 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue 7] All PL messages addressed to only LFBs? Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c3f828922b5ae9a0fa296d4bd5b66d71 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4DD7C.449FFF10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jamal,=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > I think we may need to add text that when the message comes from the > FE->CE that infact the LFB selector refers to the source LFB+instance > and not destination. Would this help? > > [HK] Yes, this would clear up the confusion. We should also add text > stating that for CE->FE msgs the LFB selector refers to the destination > LFB, we don't have any text which states that either...but you had > assumed this, thus there was the confusion about FE->CE msgs Ok. I have opened ID#8 on the tracker.=20 [HK] As far as I am concerned, this is resolved.=20 I will send some text to Avri to clarify this in the draft. > [HK] The only exception is for HB msg, which we have discussed in great > detail before. < > We have probably exchanged a dozen emails on the protocol > list and even discussed it in one of our conf calls, so if you refer to > those or recall the discussion (it was done for efficiency reasons in > this case), it will be pretty clear. > Which i disagree on - I suppose thats why we are having this discussion to begin with. I oppose any exceptions. I have stated my reasons why i oppose this in most of my previous emails on the subject (I could repeat them if needed). [HK] Actually this is a separate issue (HB msg) in my opinion, my original issue has been resolved as I said in my comment above. The HB msgs has been well discussed by the protocol team and the consensus is already reflected in the draft since rev-00. If you want to reopen this, you can do that...just call it a different issue... #9, for eg. Regards Hormuzd P.s. Attached a few emails that I could find on this one (HB msg), there are more but hopefully this will help you recall. Robert's email explains all the reasoning as well. ------_=_NextPart_001_01C4DD7C.449FFF10 Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from orsmsx311.amr.corp.intel.com ([192.168.65.40]) by orsmsx408.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 05:39:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by orsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 05:39:44 -0700 Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 05:39:44 -0700 Received: from fmsmsxvs040.fm.intel.com ([132.233.42.124]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 05:39:43 -0700 Received: from fmsfmr100.fm.intel.com ([10.1.192.58]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102105394112301 for ; Thu, 21 Oct 2004 05:39:41 -0700 Received: from fmsfmr003.fm.intel.com (fmsfmr003.fm.intel.com [10.1.193.43]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with ESMTP id i9LCdf9P004664 for ; Thu, 21 Oct 2004 12:39:41 GMT Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by fmsfmr003.fm.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 i9LCfNvU014624 for ; Thu, 21 Oct 2004 12:41:23 GMT 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) 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 Content-class: urn:content-classes:message Subject: RE: [Forces-protocol] RE: sync with BNF as discussed with model folks Date: Thu, 21 Oct 2004 04:18:26 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Forces-protocol] RE: sync with BNF as discussed with model folks Thread-Index: AcS2eoqQC8S+d+rgSZelopFRt78z7QAYQAHwACMPgsA= From: To: "Khosravi, Hormuzd M" , , Cc: 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 ________________________________ 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_01C4DD7C.449FFF10 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from orsmsx311.amr.corp.intel.com ([192.168.65.40]) by orsmsx408.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 00:58:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by orsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 00:58:09 -0700 Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 00:58:09 -0700 Received: from fmsmsxvs041.fm.intel.com ([132.233.42.126]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 00:58:08 -0700 Received: from petasus.fm.intel.com ([10.1.192.37]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004102000580826516 for ; Wed, 20 Oct 2004 00:58:08 -0700 Received: from hermes.fm.intel.com (hermes.fm.intel.com [10.1.193.8]) by petasus.fm.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 ESMTP id i9K7vvv4006727 for ; Wed, 20 Oct 2004 07:57:57 GMT Received: from mtagate2.de.ibm.com (mtagate2.de.ibm.com [195.212.29.151]) by hermes.fm.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 i9K80Qw0029059 for ; Wed, 20 Oct 2004 08:00:27 GMT 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 Content-class: urn:content-classes:message Subject: Re: [Forces-protocol] RE: sync with BNF as discussed with model folks Date: Tue, 19 Oct 2004 23:55:06 -0800 Message-ID: <417619DA.4050000@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Forces-protocol] RE: sync with BNF as discussed with model folks Thread-Index: AcS2eoqQC8S+d+rgSZelopFRt78z7Q== From: "Robert Haas" To: Cc: "Khosravi, Hormuzd M" , Content-Transfer-Encoding: quoted-printable 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 =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 =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_01C4DD7C.449FFF10-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 8 18: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 SAA26591 for ; Wed, 8 Dec 2004 18:50:22 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcBgX-0005yY-Kv for forces-archive@IETF.ORG; Wed, 08 Dec 2004 18:57:31 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F031A8@cherry.ease.lsoft.com>; Wed, 8 Dec 2004 18:50:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48213922 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 8 Dec 2004 18:50:17 -0500 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 8 Dec 2004 18:39:38 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iB8Ndctl018121 for ; Wed, 8 Dec 2004 23:39:38 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iB8NdZdm007640 for ; Wed, 8 Dec 2004 23:39:35 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 M2004120815393413614 for ; Wed, 08 Dec 2004 15:39:34 -0800 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 8 Dec 2004 15:39:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: ForCES Protocol Issue Resolution Thread-Index: AcTdfywNClSu2HvgQIiRyyWbcUt4Ew== X-OriginalArrivalTime: 08 Dec 2004 23:39:35.0016 (UTC) FILETIME=[2C7C8680:01C4DD7F] X-Scanned-By: MIMEDefang 2.44 Message-ID: Date: Wed, 8 Dec 2004 15:39:34 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: ForCES Protocol Issue Resolution To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable All, The ForCES protocol has an issues tracker at: http://www.mip4.org/issues/tracker/forces/ Patrick and I would like the working group to begin resolving the open issues currently listed with the protocol. As such, we would like to utilize the following process: For each issue, determine whether it is already addressed in the protocol draft. If yes, treat the issue as a change request. If no, treat it as a new feature request. For change requests, determine if there is a consensus to make the requested change. If the consensus is to not change it, mark the issue as closed and stay with the current draft. If the consensus is that a change is needed or at least more discussion is needed, then we will drive the issue on the list through a discussion. For new features, identify at least one issue owner and ask=20 them to put forth a proposal within a reasonable time frame. Others may put forth alternative proposals. Review & select a proposal (or choose to do nothing) after the proposals are in. If no proposals are put forth, do not add the feature. We will kick off the process later this week. In the meanwhile, I urge people to familiarize themselves with the current issues list and add or correct any issues as needed. -David From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 8 22:47: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 WAA28613 for ; Wed, 8 Dec 2004 22:47:46 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcFOK-0002ZF-L0 for forces-archive@IETF.ORG; Wed, 08 Dec 2004 22:54:57 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F034C3@cherry.ease.lsoft.com>; Wed, 8 Dec 2004 22:47:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48233342 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 8 Dec 2004 22:47:45 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 8 Dec 2004 22:43:33 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004120819465845:54887 ; Wed, 8 Dec 2004 19:46:58 -0800 References: <6.1.2.0.0.20041122091159.02ac1780@localhost> <00f701c4d172$f4eff520$020aa8c0@wwm1> <6.1.2.0.0.20041123113807.03f3b840@localhost> <1101266555.1353.81.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/08/2004 07:46:59 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/08/2004 07:47:01 PM, Serialize complete at 12/08/2004 07:47:01 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1102563808.1046.5.camel@jzny.localdomain> Date: Wed, 8 Dec 2004 22:43:28 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Apology & Clarification on indexing To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1101266555.1353.81.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Joel/Weiming, Can we close on this? I think we were close and the break was good. Thoughts? cheers, jamal On Tue, 2004-11-23 at 22:22, Jamal Hadi Salim wrote: > Folks, > > Syntax aside on how to the key is represented. (Actually i agree with > Weiming that a key is definable as a sub-path, but thats a side issue). > > I think the differences now boil to whether we want to restrict the > keys. Joel makes a compelling case why we do want that below. > It is also true that there will be well known content keys per LFB and > that these will be known at definition time. > > The compromise: > It seems to me we need to define the key(s) in the xml. The defined key > is the minimal an LFB at the FE is expected to allow for content lookup > ex the L3 lookup of prefix/mask/nhid. > If we dont do so we would need some discovery to figure out what the > mythical FPGA implementing an LFB does as a minimal. And this from a > first glance appears like it would add a _lot_ of complexity to the > protocol (as well as the model). > > Having said that: for the "power" LFB i think we should allow more > powerful content expressions that are outside the scope of the model. > This should be done with minimal impact on the grammar representation > of the path-data. If it is impacting i think we will not grossly miss > this feature in the first incarnation of the protocol. We could always > revisit it after implementation experience. > > Thoughts? > > cheers, > jamal > > On Tue, 2004-11-23 at 11:44, Joel M. Halpern wrote: > > I don't care whether the key declaration is on the array line or on the > > description of the content of the array. > > In order to keep the syntax simple, if we are going to support keys that > > are elements of structs insides structs, or keys which are collections of > > elements, I was assigning a single value to that key in order to avoid > > trying to carry collections of key path material. > > This is easy to do if one assumes that keying must be declared with the > > class definition, and indeed makes no sense if you assume that the CE can > > use any keying which it knows to be suitable. > > > > The argument for content indexing was based on what was natural for the FE > > to support. If that is the goal, then the CE needs to know (probably from > > the schema) what sorts of content indexing make sense. Thus, for this > > problem, key declaration in the class definition makes sense. I have > > agreed to go along with including this capability in the protocol and model. > > > > I can see no argument for supporting arbitrary searching by the CE. The CE > > is going to need to have a representation of the LFB information. If the > > CE wants to create interesting keys so it can find things in its own > > tables, that is the CEs business. It is not the job of the FE to provide > > such capabilities. Remember that the FE may be a simple control processor > > manipulating FPGA (or even ASIC) tables. It is not necessarily an NPU, > > much less a general purpose processor. > > I would argue that supporting general search capabilities is far afield > > from what ForCES needs. > > > > Yours, > > Joel M. Halpern > > > > At 10:41 AM 11/23/2004, Weiming Wang wrote: > > >Joel, > > > > > >----- Original Message ----- > > >From: "Joel M. Halpern" > > > > > > > tst: structure > > > > t1: uint32, id = 1 > > > > t2: uint32, id = 2 > > > > end structure > > > > > > > > sst: structure > > > > s1: uint32, id = 1 > > > > s2: type=tst, id = 2 > > > > s3: uint32, id = 3 > > > > end structure > > > > > > > > and assume that in the LFB class definition of interest we have a field > > > > definition: > > > > > > > > farr: array, variable, id = 1 > > > > type = sst > > > > key = s1 > > > > end array > > > > > > >From my limited viewpoint, I see this key definition is only trying to > > > move the > > >work of the protocol to the model team. I suppose you were trying to say that > > >the farr array is composed of one element with the 'sst' structure type > > >and you > > >hope to only alow the s1 in the sst structure as a searching key. As a result, > > >what from my viewpoint of the first part of definition is something like: > > > > > > farr: array, variable, id=1 > > > f1: sst, id=1 > > > > > >Then the second part you wanted to express as key=s1 actually in my view > > >is not > > >a 'thing' of element. It's actually something like to assign a subpath. > > >What you > > >are going to do is to assign a key with a subpath. Then comes the question is > > >can this kind of key=subpath expression be allowed in the arry element field > > >definition? My answer is NO. I suppose what you meant actually means : > > > > > > farr: array, variable, id=1, key=subpath > > > f1: sst, id=1 > > > > > >Then, if you have two allowed keys in the array, you will have to express it > > >like: > > > > > > farr: array, variable, id=1, key=subpath1, key=subpath2, ( or > > >key=subpath1&subpath2, etc) > > > f1: sst, id=1 > > > > > >(A minute note here, the key=s1 subpath you referred here actually in my > > >view > > >should be a subpath of 'f1.s1' rather than 's1'. Just consider if the > > >array has > > >two subfields as f1(sst type) and f2(still sst type), then your key =s1 means > > >nothing). > > > > > >Note that, where the key is expressed as a property(attribute) of the array > > >rather than an element field. > > > > > >Conclusion: your scheme of using a limited key in fact has just moved the > > >'subpath' issue from protocol layer to model XML layer. you are just trying to > > >use some specific elements in the XML to express the subpaths, therefore the > > >generic grammar for the protocol format as : > > > > > > PATH-DATA := MainPath [IndexTLV] [SubPath-Value]+ [Data] > > >still keeps the same. > > > > > >Now let's compare the merits and demerits for the two scheme: > > > > > >1. Obviously, the keys defined subpaths are a subset of the explicit subpath > > >expression. It limits the searching power. Maybe you may say that's what > > >we want > > >for simplicity cause, but I don't see. My question is, does using such way to > > >limit the searching power really saves network processor resourses? I don't > > >see even a little. I just think they are the same in the resourse take, not to > > >mention that the FE searching engine for CE does not need to work at line > > >speed. > > > > > >2. On contrary, the pay for the key is with a much more comlex XML > > >expression(you have to define the idea of 'path' also in model), the reward is > > >mainly a limit to searching engine and maybe with a small save of bits in the > > >subpath expression. > > > > > >3. Key by XML mode may also result in a version compatibility problem as Jamal > > >pointed out, and limit the extension ability. > > > > > >Cheers, > > >Weiming > > > > > >P.S. One more thing I have just thought of is, actually in some cases, the key > > >even does not save bit very much. Consider N field elements f1, f2, and fN, > > >that we allowed as keys and we also allow any kind of logical searching > > >for the > > >elements like f1, f1&f2, f1&f3, ... f2, f2&f3,... f1&f2&f3, ...... we > > >will then > > >have to define 2 to the power N of KEYs!!! Along with the techniques step > > >forward, can we say 10 elements are definitely impossible? From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 8 22:56: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 WAA29086 for ; Wed, 8 Dec 2004 22:56:44 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcFX1-0002if-9v for forces-archive@IETF.ORG; Wed, 08 Dec 2004 23:03:55 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F03695@cherry.ease.lsoft.com>; Wed, 8 Dec 2004 22:56:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48233872 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 8 Dec 2004 22:56:41 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 8 Dec 2004 22:56:18 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004120819594548:54903 ; Wed, 8 Dec 2004 19:59:45 -0800 References: <468F3FDA28AA87429AD807992E22D07E038BF65C@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/08/2004 07:59:46 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/08/2004 07:59:47 PM, Serialize complete at 12/08/2004 07:59:47 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1102564575.1046.20.camel@jzny.localdomain> Date: Wed, 8 Dec 2004 22:56:15 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 7] All PL messages addressed to only LFBs? Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E038BF65C@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit On Wed, 2004-12-08 at 18:18, Khosravi, Hormuzd M wrote: > Jamal, > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > > I think we may need to add text that when the message comes from the > > FE->CE that infact the LFB selector refers to the source LFB+instance > > and not destination. Would this help? > > > > [HK] Yes, this would clear up the confusion. We should also add text > > stating that for CE->FE msgs the LFB selector refers to the > destination > > LFB, we don't have any text which states that either...but you had > > assumed this, thus there was the confusion about FE->CE msgs > > Ok. I have opened ID#8 on the tracker. > > [HK] As far as I am concerned, this is resolved. > I will send some text to Avri to clarify this in the draft. > Please do - When the text is agreeable i will close that item. The main reason it is captured in the database is to ensure that the issue is remembered and draft doesnt get released unless appropriate text is in. > > [HK] The only exception is for HB msg, which we have discussed in > great > > detail before. > < > > We have probably exchanged a dozen emails on the protocol > > list and even discussed it in one of our conf calls, so if you refer > to > > those or recall the discussion (it was done for efficiency reasons in > > this case), it will be pretty clear. > > > > Which i disagree on - I suppose thats why we are having this discussion > to > begin with. > I oppose any exceptions. I have stated my reasons why i oppose this in > most of my previous emails on the subject (I could repeat them if > needed). > > [HK] Actually this is a separate issue (HB msg) in my opinion, my > original issue has been resolved as I said in my comment above. The HB > msgs has been well discussed by the protocol team and the consensus is > already reflected in the draft since rev-00. If you want to reopen this, > you can do that...just call it a different issue... #9, for eg. Do you agree with Roberts view below in which he states the heartbeat going to the FE protocol Object? If yes, that would be fine for me to move on since LFBselector would have to exist (even if the CE protocol object is not used) and there would be a consistent grammar. cheers, jamal PS:- Note in the text you quoted my contention is that i dont see anything speacial to desire a "heartbeat to a FE or CE" - since all we have to do is direct it to some LFB - I argue in that text that heartbeats may be directed at other LFBs other than the FE protocol object - to which there is disagreement from Robert and Ram. I dont wish to bring that discussion up, at least not at this stage. And if we agree targeting an LFBselector, it wouldnt matter anyways. From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 8 23:12: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 XAA00044 for ; Wed, 8 Dec 2004 23:12:44 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcFmS-0002zT-TK for forces-archive@IETF.ORG; Wed, 08 Dec 2004 23:19:55 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00F037FD@cherry.ease.lsoft.com>; Wed, 8 Dec 2004 23:12:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48236590 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 8 Dec 2004 23:12:36 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 8 Dec 2004 23:11:29 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004120820145603:54930 ; Wed, 8 Dec 2004 20:14:56 -0800 References: <2AF68A477DD44C4EBCBE338C24E7A9EE01837104@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/08/2004 08:14:56 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/08/2004 08:14:58 PM, Serialize complete at 12/08/2004 08:14:58 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1102565485.1047.34.camel@jzny.localdomain> Date: Wed, 8 Dec 2004 23:11:26 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model document To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <2AF68A477DD44C4EBCBE338C24E7A9EE01837104@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Wheee .. what she said below. cheers, jamal On Tue, 2004-12-07 at 16:58, Yang, Lily L wrote: > Yes, the schema should stay in the base model doc. > > > -----Original Message----- > > From: Forwarding and Control Element Separation > > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern > > Sent: Tuesday, December 07, 2004 1:03 PM > > To: FORCES@PEACH.EASE.LSOFT.COM > > Subject: Re: Model document > > > > I believe that the schema needs to remain in the base model > > document. There will (I expect) be multiple LFB Class > > library documents. The one we produce will only be the > > first. So it will work much better if the schema is in once > > place, referenced by all the library docs. The model doc is > > the obvious place to do that. > > > > When we work over the schema, one thing we have to do is add > > the identifiers to be used by the protocol. > > > > Yours, > > Joel > > > > At 04:01 PM 12/7/2004, Deleganes, Ellen M wrote: > > >I am starting to look at the FE model document. To start, > > I've removed > > >the LFB class definitions and have them in a separate > > document. If you > > >would like for me just to post the class definitions to the > > reflector, > > >I'll do so. Currently, they are in a word document, but can be > > >converted to a .txt file. While doing so, I noticed that the > > previous > > >section in the model document is titled "Model and Schema for LFB > > >Classes". I think it would make sense to put the schema with the > > >document describing the LFB class definitions. At least some > > >description of the model should probably remain with the model > > >document. Anyone have comments about this? > > > > > >The outstanding tasks the model team had for this document > > last summer > > >are as follows: > > > > > >* Harmonize sections 4 & 5 to use a similar textual and > > organizational > > >approach (Joel and Zsolt were to agree on an approach and to update > > >their sections as needed) > > >* Put a total view of the schema in one place (Joel and Zsolt) > > >* Clean up the overall text (Ellen) > > >* Address comments/issues from the reflector (All) > > > > > >The main reason that the model team held off taking the > > draft to last > > >call this year was to wait for the protocol draft to get a > > little more > > >stable. We wanted to make sure the model draft stayed > > synchronized with > > >the protocol draft. Now that the issues are settling down, we should > > >make sure that we make forward progress again. > > > > > >Regards, > > >Ellen Deleganes > > From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 10 17:42: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 RAA04980 for ; Fri, 10 Dec 2004 17:42:23 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CctaH-0002NQ-D5 for forces-archive@IETF.ORG; Fri, 10 Dec 2004 17:49:57 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00F07B44@cherry.ease.lsoft.com>; Fri, 10 Dec 2004 17:42:24 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48540497 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 10 Dec 2004 17:42:23 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 10 Dec 2004 17:40:09 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBAMe9Yn018004; Fri, 10 Dec 2004 22:40:09 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBAMe5ej021894; Fri, 10 Dec 2004 22:40:09 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 M2004121014400915752 ; Fri, 10 Dec 2004 14:40:09 -0800 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, 10 Dec 2004 14:40:09 -0800 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 Thread-Topic: [FORCES] [issue 7] HB msg Thread-Index: AcTdoxwCMy8vkCR4TsW+ZIcpC1uujgBZIbrA X-OriginalArrivalTime: 10 Dec 2004 22:40:09.0578 (UTC) FILETIME=[34255CA0:01C4DF09] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E0393706B@orsmsx408> Date: Fri, 10 Dec 2004 14:40:07 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue 7] HB msg Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Jamal, You definitely have a different opinion on this from what we have in the draft and as I said you can reopen this one as a separate issue, if you wish. Regarding Robert's email, here is the part that summarizes the discussion well... - 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 This explains all the rationale. IMHO at this time, I don't see any point of spending too much time in debating this. If anyone else has an opinion on this, let us know ? Regards, Hormuzd=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > [HK] Actually this is a separate issue (HB msg) in my opinion, my > original issue has been resolved as I said in my comment above. The HB > msgs has been well discussed by the protocol team and the consensus is > already reflected in the draft since rev-00. If you want to reopen this, > you can do that...just call it a different issue... #9, for eg. Do you agree with Roberts view below in which he states the heartbeat going to the FE protocol Object? If yes, that would be fine for me to move on since LFBselector would have to exist (even if the CE protocol object is not used) and there would be a consistent grammar. cheers, jamal PS:- Note in the text you quoted my contention is that i dont see anything speacial to desire a "heartbeat to a FE or CE" - since all we have to do is direct it to some LFB - I argue in that text that heartbeats may be directed at other LFBs other than the FE protocol object - to which there is disagreement from Robert and Ram. I dont wish to bring that discussion up, at least not at this stage. And if we agree targeting an LFBselector, it wouldnt matter anyways. From owner-forces@PEACH.EASE.LSOFT.COM Sat Dec 11 08:05: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 IAA20451 for ; Sat, 11 Dec 2004 08:05:00 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cd73A-0002CX-Jt for forces-archive@IETF.ORG; Sat, 11 Dec 2004 08:12:41 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00F09298@cherry.ease.lsoft.com>; Sat, 11 Dec 2004 8:05:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48637361 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 11 Dec 2004 08:04:58 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 11 Dec 2004 08:03:29 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121105063097:58502 ; Sat, 11 Dec 2004 05:06:30 -0800 References: <468F3FDA28AA87429AD807992E22D07E0393706B@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/11/2004 05:06:31 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/11/2004 05:06:57 AM, Serialize complete at 12/11/2004 05:06:57 AM Content-Type: multipart/mixed; boundary="=-fHu6w66wdOd5tL/8JYWM" Message-ID: <1102770182.1092.105.camel@jzny.localdomain> Date: Sat, 11 Dec 2004 08:03:02 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: [issue 7] HB msg To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0393706B@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 --=-fHu6w66wdOd5tL/8JYWM Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2004-12-10 at 17:40, Khosravi, Hormuzd M wrote: > Jamal, > > You definitely have a different opinion on this from what we have in the > draft Why would we be discussing it otherwise??? my recollection is _you_ put it in the draft with intent we will revisit and disscuss. I sent the attached document back in October to accelerate the changes to the original draft. Look at section 6.7 - I gave you a clear opportunity to discuss this and didnt impose. Now its in the draft, is the implication that it no longer holds?? Sounds almost like a lawyer sneaking in fine print. > and as I said you can reopen this one as a separate issue, if you > wish. if you are unhappy with the way issue #4 is worded i could modify it. But that was my first review of section 6.7 after i sent the attached document. > Regarding Robert's email, here is the part that summarizes the > discussion well... Robert seems to be tied elsewhere - but anyone else with an opinion please speak up (and when Robert becomes loose, speak up). We have lost track of what this issue is in this long thread; If people dont follow, we could restate our positions. cheers, jamal --=-fHu6w66wdOd5tL/8JYWM 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 --=-fHu6w66wdOd5tL/8JYWM-- From owner-forces@PEACH.EASE.LSOFT.COM Sat Dec 11 11:58: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 LAA04615 for ; Sat, 11 Dec 2004 11:58:55 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdAha-0006FH-TY for forces-archive@IETF.ORG; Sat, 11 Dec 2004 12:06:40 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00F09249@cherry.ease.lsoft.com>; Sat, 11 Dec 2004 11:58:56 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48656430 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 11 Dec 2004 11:58:55 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 11 Dec 2004 11:57:54 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121109012026:58984 ; Sat, 11 Dec 2004 09:01:20 -0800 Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/11/2004 09:01:20 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/11/2004 09:01:22 AM, Serialize complete at 12/11/2004 09:01:22 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1102784270.1091.326.camel@jzny.localdomain> Date: Sat, 11 Dec 2004 11:57:50 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Issue: Atomicity, batching and config result message To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Some small nitpick coming from implementation experience and its a good time to bring this up. There are 3 modes in which a single PL message with a batch of multiple LFB targets or even multiple operations to one LFB selector can be executed: 1) "all-or-none" Atomic transaction. I believe the SNMP way of life. The FE executes operations till the first one fails. If one fails to execute all fail. A 2pc may help here. We discussed earlier that if we crossed transactions across messages we would have atomic flag indicating where things start and end as part of one transaction. (section 3.3.1) 2) "one of N" independent operations. In which several independent operations are targeted at one or more LFB selector. CE doesnt care if one fails - execution needs to continue. It just neds to be told why the failure happened at each failed operation. 3) "go to N" loose transaction In which all operations are executed on FE sequentially until first failure. The rest are not executed but everything upto failed is not undone (unlike #1). So far our experiences looking at the config response message implies it respects #2 only. Can we discuss the above? Do we need all 3 modes? Do we keep one? We need to discuss the atomicity flags per operation/ message with more clarity In regards to Config response. It does seem to me to be a source of a lot of noise if i have to send back the full message everytime. I should be able to say "I want this config in all-or-none mode and just send me a NACK with global reason when a failure happens". This has been restricting how we batch in our implementation. Anyways, hopefully this will start a discussion that will lead to a resolution. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Sat Dec 11 12:06: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 MAA04975 for ; Sat, 11 Dec 2004 12:06:29 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdAol-0006MC-16 for forces-archive@IETF.ORG; Sat, 11 Dec 2004 12:14:13 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00F093DA@cherry.ease.lsoft.com>; Sat, 11 Dec 2004 12:06:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48657341 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 11 Dec 2004 12:06:16 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 11 Dec 2004 12:05:49 -0500 Received: from [69.170.19.177] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8214921 for FORCES@PEACH.EASE.LSOFT.COM; Sat, 11 Dec 2004 12:05:49 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1102784270.1091.326.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041211115754.03ddb3d0@localhost> Date: Sat, 11 Dec 2004 12:02:16 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Issue: Atomicity, batching and config result message To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1102784270.1091.326.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 It is nice to be able to support mode 2 (do what you can from the set). My understanding was that the atomic / transaction mode would be used to enable mode 1 (all or none) whether the components were in one request or several. I believe the theory was that this could even be used to support atomicity across FEs. However, I don't know that we have seen enough details to be able to mark this "done". In practice, my impression is that mode 3 (up to N errors) is not particularly helpful, is hard to implement, and is a pain for protocol. Hence I would prefer not to try to provide it. For completeness, I will mention a mode 4 that was discussed. This would be "go till error" where the processing stops at the first error, but earlier operations are not unwound. This is easy to implement, and a CE can use it to cover a number of cases. However, it is probably not worth doing if we are going to have full rollback anyway. (It is a useful augment if all we were doing was mode 2, do whatever works.) Yours, Joel At 11:57 AM 12/11/2004, Jamal Hadi Salim wrote: >Some small nitpick coming from implementation experience and its a good >time to bring this up. > >There are 3 modes in which a single PL message with a batch of multiple >LFB targets or even multiple operations to one LFB selector can be >executed: > >1) "all-or-none" Atomic transaction. I believe the SNMP way of life. > >The FE executes operations till the first one fails. If one fails >to execute all fail. A 2pc may help here. >We discussed earlier that if we crossed transactions across messages we >would have atomic flag indicating where things start and end as part of >one transaction. (section 3.3.1) > >2) "one of N" independent operations. > >In which several independent operations are targeted at one or more LFB >selector. CE doesnt care if one fails - execution needs to continue. It >just neds to be told why the failure happened at each failed operation. > >3) "go to N" loose transaction > >In which all operations are executed on FE sequentially until first >failure. The rest are not executed but everything upto failed is not >undone (unlike #1). > >So far our experiences looking at the config response message implies it >respects #2 only. >Can we discuss the above? Do we need all 3 modes? Do we keep one? >We need to discuss the atomicity flags per operation/ message with >more clarity > >In regards to Config response. It does seem to me to be a source of a >lot of noise if i have to send back the full message everytime. I should >be able to say "I want this config in all-or-none mode and just send me >a NACK with global reason when a failure happens". This has been >restricting how we batch in our implementation. > >Anyways, hopefully this will start a discussion that will lead to a >resolution. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Dec 13 09:11: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 JAA11344 for ; Mon, 13 Dec 2004 09:11:41 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdr3D-0006tW-5g for forces-archive@IETF.ORG; Mon, 13 Dec 2004 09:19:47 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00F0B859@cherry.ease.lsoft.com>; Mon, 13 Dec 2004 9:11:40 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 48920681 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 13 Dec 2004 09:11:38 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 13 Dec 2004 09:10:29 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121306135381:61916 ; Mon, 13 Dec 2004 06:13:53 -0800 References: <1102784270.1091.326.camel@jzny.localdomain> <6.1.2.0.0.20041211115754.03ddb3d0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/13/2004 06:13:54 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/13/2004 06:13:55 AM, Serialize complete at 12/13/2004 06:13:55 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1102947026.1091.382.camel@jzny.localdomain> Date: Mon, 13 Dec 2004 09:10:26 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Issue: Atomicity, batching and config result message To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041211115754.03ddb3d0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit On Sat, 2004-12-11 at 12:02, Joel M. Halpern wrote: > It is nice to be able to support mode 2 (do what you can from the set). > My understanding was that the atomic / transaction mode would be used to > enable mode 1 (all or none) whether the components were in one request or > several. I believe the theory was that this could even be used to support > atomicity across FEs. A 2pc should allow cross FE atomicity of transactions.. > However, I don't know that we have seen enough details to be able to mark > this "done". I think we may need two maintainance messages (maybe 3) that would facilitate 2pC. This would be directed at one or more LFB targets (or at the FE Object if what you want is to lock the FE). Those commands could also be used as aliases for LOCK/UNLOCK. Start and End(what you refer as done) of a specific transaction (whether in one message batch or across, could be done via global flags as opposed per operation flags) > In practice, my impression is that mode 3 (up to N errors) is not > particularly helpful, is hard to implement, and is a pain for > protocol. Hence I would prefer not to try to provide it. > > For completeness, I will mention a mode 4 that was discussed. I may have miscommunicated - #3 is infact the same as what you refer to as #4. > This would > be "go till error" where the processing stops at the first error, but > earlier operations are not unwound. Nod from here. > This is easy to implement, and a CE > can use it to cover a number of cases. However, it is probably not worth > doing if we are going to have full rollback anyway. (It is a useful > augment if all we were doing was mode 2, do whatever works.) > It seems to me the 3 modes can be selected from a global flag level (we need two bits). For default we can have mode 2. Does this sound reasonable? So in summary: Global flags, - 2 for selecting the 3 modes. Global Types/commands: - 2 one for "DONE" and another one for "START" DONE is also == UNLOCK, START == LOCK used only in 2pc like setup. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Dec 14 13:12: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 NAA28722 for ; Tue, 14 Dec 2004 13:12:06 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeHHg-00010l-BW for forces-archive@IETF.ORG; Tue, 14 Dec 2004 13:20:29 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00F0DE5E@cherry.ease.lsoft.com>; Tue, 14 Dec 2004 13:12:02 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49109700 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 14 Dec 2004 13:11:59 -0500 Approved-By: ellen.m.deleganes@INTEL.COM Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 14 Dec 2004 11:42:04 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBEGg42l018483 for ; Tue, 14 Dec 2004 16:42:04 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBEGfg5A018637 for ; Tue, 14 Dec 2004 16:42: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 M2004121408420300847 for ; Tue, 14 Dec 2004 08:42:03 -0800 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, 14 Dec 2004 08:42:03 -0800 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_01C4E1FB.D69BCA1C" X-MS-Has-Attach: yes Thread-Topic: LFB Class text extracted from the ForCES FE Model Draft Thread-Index: AcTh/AYaJK2gJZVMSnCr96Wy/h3Qcw== X-OriginalArrivalTime: 14 Dec 2004 16:42:03.0618 (UTC) FILETIME=[D72B0C20:01C4E1FB] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E039B6B8C@orsmsx408> Date: Tue, 14 Dec 2004 08:43:22 -0800 Reply-To: "Deleganes, Ellen M" Sender: Forwarding and Control Element Separation From: "Deleganes, Ellen M" Subject: LFB Class text extracted from the ForCES FE Model Draft To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.7 (/) X-Scan-Signature: 18100d5cbd6ebe12591b0282c337464d This is a multi-part message in MIME format. ------_=_NextPart_001_01C4E1FB.D69BCA1C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4E1FB.D69BCA1C" ------_=_NextPart_002_01C4E1FB.D69BCA1C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the LFB Class text extracted from the original ForCES FE Model Draft to start to build the LFB Class definitions. =20 Regards, Ellen ------_=_NextPart_002_01C4E1FB.D69BCA1C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is the LFB Class text extracted = from the original ForCES FE Model Draft to start to build the LFB Class = definitions.

 

Regards,

Ellen

------_=_NextPart_002_01C4E1FB.D69BCA1C-- ------_=_NextPart_001_01C4E1FB.D69BCA1C Content-Type: text/plain; name="lfb-class.txt" Content-Transfer-Encoding: base64 Content-Description: lfb-class.txt Content-Disposition: attachment; filename="lfb-class.txt" Content-Transfer-Encoding: base64 DQogICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgRXhwaXJhdGlvbjogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgIEZpbGU6 IGRyYWZ0LXh4eHgtZm9yY2VzLWxmYi1jbGFzcy50eHQgICAgICAgICAgICANCiAgICBXb3JraW5n IEdyb3VwOiBGb3JDRVMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCiAgICAgDQogICAgICAgICAgIEZvckNFUyBMb2dpY2FsIEZ1bmN0 aW9uIEJsb2NrIChMRkIpIENsYXNzIERlc2NyaXB0aW9ucyANCiAgDQogICAgICAgICAgICAgICAg ICAgICBkcmFmdC14eHh4LWZvcmNlcy1sZmItY2xhc3MtMDAudHh0IA0KICAgICANCiAgICAgDQog ICAgIA0KICAgICANCiAgICBTdGF0dXMgb2YgdGhpcyBNZW1vIA0KICAgICANCiAgICBUaGlzIGRv Y3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdp dGggDQogICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2LiAgSW50ZXJu ZXQtRHJhZnRzIGFyZSANCiAgICB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5n aW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURiksIA0KICAgIGl0cyBhcmVhcywgYW5kIGl0cyB3b3Jr aW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gDQogICAgZGlzdHJp YnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuIA0KICAgICANCiAgICBJ bnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9m IHNpeCANCiAgICBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xl dGVkIGJ5IG90aGVyIA0KICAgIGRvY3VtZW50cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyANCiAgICBhcyByZWZlcmVuY2UgbWF0ZXJpYWwg b3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgYGB3b3JrIGluIA0KICAgIHByb2dyZXNzLicn IA0KICAgICANCiAgICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUg YWNjZXNzZWQgYXQgDQogICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMu dHh0LiANCiAgICAgDQogICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVj dG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdCAgDQogICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFk b3cuaHRtbC4gDQogICAgIA0KIEFic3RyYWN0IA0KICAgICANCiAgICBUaGlzIGRvY3VtZW50IGRl ZmluZXMgYSBsaXN0IG9mIHRoZSBiYXNpYyBsb2dpY2FsIGZ1bmN0aW9uYWwgYmxvY2tzIA0KICAg IChMRkJzKSB3aXRoaW4gdGhlIExGQiBjbGFzcyBsaWJyYXJ5IHRvIGFpZCB0aGUgZWZmb3J0IGlu IGRlZmluaW5nIA0KICAgIGluZGl2aWR1YWwgTEZCcy4gIA0KICAgICANCiBUYWJsZSBvZiBDb250 ZW50cyAgDQogIA0KIDEuIA0gICAgTEZCIENsYXNzIExpYnJhcnkgIA0KICAgICAgIA0KICAgIEEg c2V0IG9mIGluaXRpYWwgTEZCIGNsYXNzZXMgYXJlIGlkZW50aWZpZWQgaGVyZSBpbiB0aGUgTEZC IGNsYXNzIA0KICAgIGxpYnJhcnkgYXMgbmVjZXNzYXJ5IHRvIGJ1aWxkIGNvbW1vbiBGRSBmdW5j dGlvbnMuICBTb21lIG9mIHRoZSBMRkIgDQogICAgY2xhc3NlcyBkZXNjcmliZWQgaGVyZSBhcmUg YWJzdHJhY3QgYmFzZSBjbGFzc2VzIGZyb20gd2hpY2ggDQogICAgc3BlY2lmaWMgTEZCIHN1Yi1j bGFzc2VzIHdpbGwgYmUgZGVyaXZlZC4gIEhlbmNlLCB0aGUgYmFzZSBjbGFzc2VzIA0KICAgIG1h eSBub3QgYmUgdXNlZCBkaXJlY3RseSBpbiBhIHBhcnRpY3VsYXIgRkUncyBtb2RlbCwgYnV0IHRo ZSBzdWItDQogICAgY2xhc3NlcyAoeWV0IHRvIGJlIGRlZmluZWQpIGNvdWxkIGJlLiAgVGhpcyBp bml0aWFsIGxpc3QgYXR0ZW1wdHMgDQogICAgdG8gZGVzY3JpYmUgTEZCIGNsYXNzZXMgYXQgdGhl IGV4cGVjdGVkIGxldmVsIG9mIGdyYW51bGFyaXR5LiAgVGhpcyANCiAgICBsaXN0IGlzIG5laXRo ZXIgZXhoYXVzdGl2ZSBub3Igc3VmZmljaWVudGx5IGRldGFpbGVkLiANCgwgICAgICAgICAgDQog ICAgU2V2ZXJhbCB3b3JraW5nIGdyb3VwcyBpbiB0aGUgSUVURiBoYXZlIGFscmVhZHkgZG9uZSBz b21lIHJlbGV2YW50IA0KICAgIHdvcmsgaW4gbW9kZWxpbmcgdGhlIHByb3Zpc2lvbmluZyBwb2xp Y3kgZGF0YSBmb3Igc29tZSBvZiB0aGUgDQogICAgZnVuY3Rpb25zIHdlIGFyZSBpbnRlcmVzdGVk IGluLCBmb3IgZXhhbXBsZSwgdGhlIERpZmZTZXJ2IA0KICAgIChEaWZmZXJlbnRpYXRlZCBTZXJ2 aWNlcykgUElCIFs0XSBhbmQgSVBTZWMgUElCIFs4XS4gIFdoZW5ldmVyIA0KICAgIHBvc3NpYmxl LCB3ZSBoYXZlIHRyaWVkIHRvIHJldXNlIHRoZSB3b3JrIGRvbmUgZWxzZXdoZXJlLiAgDQogICAg ICAgICAgDQogMS4xLiBQb3J0IExGQiAgDQogICAgICAgDQogICAgQSBQb3J0IExGQiBpcyB1c2Vk IHRvIG1vZGVsIHBoeXNpY2FsIEkvTyBwb3J0cyBvbiB0aGUgRkUuICBJdCBpcyANCiAgICBib3Ro IGEgc291cmNlIG9mIGRhdGEgInJlY2VpdmVkIiBieSB0aGUgRkUgYW5kIGEgc2luayBvZiBkYXRh IA0KICAgICJ0cmFuc21pdHRlZCIgYnkgdGhlIEZFLiAgVGhlIFBvcnQgTEZCIGNvbnRhaW5zIGEg bnVtYmVyIG9mIHN0YXRpYyANCiAgICBhdHRyaWJ1dGVzLCB3aGljaCBtYXkgaW5jbHVkZSwgYnV0 IGFyZSBub3QgbGltaXRlZCB0bywgdGhlIA0KICAgIGZvbGxvd2luZyBpdGVtczogDQogICAgICAg LiB0aGUgbnVtYmVyIG9mIHBoeXNpY2FsIHBvcnRzIG9uIHRoaXMgTEZCIA0KICAgICAgIC4gcGh5 c2ljYWwgcG9ydCB0eXBlIA0KICAgICAgIC4gcGh5c2ljYWwgcG9ydCBsaW5rIHNwZWVkIChtYXkg YmUgdmFyaWFibGU7IGUuZy4sIDEwLzEwMC8xMDAwIA0KICAgICAgICAgRXRoZXJuZXQpLiANCiAg ICAgDQogICAgSW4gYWRkaXRpb24sIHRoZSBQb3J0IExGQiBjb250YWlucyBhIG51bWJlciBvZiBj b25maWd1cmFibGUgDQogICAgYXR0cmlidXRlcywgaW5jbHVkaW5nOiANCiAgICAgICAuIHBoeXNp Y2FsIHBvcnQgY3VycmVudCBzdGF0dXMgKHVwIG9yIGRvd24pIA0KICAgICAgIC4gcGh5c2ljYWwg cG9ydCBsb29wYmFjayANCiAgICAgICAuIHBoeXNpY2FsIHBvcnQgbWFwcGluZyB0byBMMiBpbnRl cmZhY2UuIA0KICAgICANCiAgICBUaGUgUG9ydCBMRkIgY2FuIGJlIHN1Yi1jbGFzc2VkIGludG8g dGVjaG5vbG9neSBzcGVjaWZpYyBMRkIgDQogICAgY2xhc3Nlcywgd2l0aCBhZGRpdGlvbmFsIHN0 YXRpYyBhbmQgY29uZmlndXJhYmxlIGF0dHJpYnV0ZXMuICANCiAgICBFeGFtcGxlcyBvZiBwb3Nz aWJsZSBzdWItY2xhc3NlcyBpbmNsdWRlOiANCiAgICAgICAuIEV0aGVybmV0IA0KICAgICAgIC4g UGFja2V0LW92ZXItU09ORVQgT0MtTiANCiAgICAgICAuIEFUTS1vdmVyLVNPTkVUL1NETiBPQy1O IA0KICAgICAgIC4gVDMgDQogICAgICAgLiBFMyANCiAgICAgICAuIFQxIA0KICAgICAgIC4gRTEg DQogICAgICAgLiBDU0lYLUwxIHN3aXRjaGluZyBmYWJyaWMgcG9ydCAoRmkgaW50ZXJmYWNlKSAN CiAgICAgICAuIENFLUZFIHBvcnQgKGZvciBGcCBpbnRlcmZhY2UpLiANCiAgICAgDQogICAgTEZC IGNsYXNzIGluaGVyaXRhbmNlIGNhbiBiZSB1c2VkIHRvIHN1Yi1jbGFzcyBkZXJpdmVkIExGQiBj bGFzc2VzIA0KICAgIHdpdGggYWRkaXRpb25hbCBwcm9wZXJ0aWVzLCBzdWNoIGFzIFRETSBjaGFu bmVsaXphdGlvbi4gDQogICAgIA0KICAgIFRoZSBQb3J0IExGQiAicmVjZWl2ZXMiIChzb3VyY2Vz KSBhbmQgInRyYW5zbWl0cyIgKHNpbmtzKSBmcmFtZXMgaW4gDQogICAgdGVjaG5vbG9neSBzcGVj aWZpYyBmb3JtYXRzIChkZXNjcmliZWQgaW4gdGhlIHJlc3BlY3RpdmUgTEZCIGNsYXNzIA0KICAg IGRlZmluaXRpb24gYnV0IG5vdCBvdGhlcndpc2UgbW9kZWxlZCkgaW50by9vdXQgb2YgdGhlIEZF LiAgUGFja2V0cyANCiAgICAicmVjZWl2ZWQiIGZyb20gYSBwaHlzaWNhbCBwb3J0IGFyZSBzb3Vy Y2VkIG9uIChvbmUgb2YpIHRoZSBMRkIncyANCiAgICBvdXRwdXQgcG9ydChzKSwgd2hpbGUgcGFj a2V0cyB0byBiZSAidHJhbnNtaXR0ZWQiIG9uIGEgcGh5c2ljYWwgDQogICAgcG9ydCBhcmUgc2lu a2VkIG9uIChvbmUgb2YpIHRoZSBMRkIncyBpbnB1dCBwb3J0KHMpLiAgVGhlIFBvcnQgTEZCIA0K ICAgIGlzIHVuaXF1ZSBhbW9uZyBMRkIgY2xhc3NlcyBpbiB0aGF0IHBhY2tldHMgYWNjZXB0ZWQg b24gYSBMRkIgaW5wdXQgDQogICAgcG9ydCBhcmUgbm90IGVtaXR0ZWQgYmFjayBvdXQgb24gYW4g TEZCIG91dHB1dCBwb3J0IChleGNlcHQgaW4gdGhlIA0KICAgIGNhc2Ugb2YgcGh5c2ljYWwgcG9y dCBsb29wYmFjayBvcGVyYXRpb24pLiANCiAgICAgICAgIA0KDCAgICBUaGUgUG9ydCBMRkIgdHJh bnNtaXRzIHRlY2hub2xvZ3kgc3BlY2lmaWMgTDIgZnJhbWVzIHRvIA0KICAgIHRvcG9sb2dpY2Fs bHkgYWRqYWNlbnQgTEZCIGluc3RhbmNlcyAoaS5lLiwgbm8gZnJhbWUgDQogICAgZGVjYXBzdWxh dGlvbi9lbmNhcHN1bGF0aW9uIGlzIG1vZGVsZWQgaW4gdGhpcyBMRkIgY2xhc3MpLiAgV2hlbiAN CiAgICB0cmFuc21pdHRpbmcgYSBmcmFtZSB0byBhbiBhZGphY2VudCBkb3duc3RyZWFtIExGQiwg dGhlIFBvcnQgTEZCIA0KICAgIHByb3ZpZGVzIHR3byBpdGVtcyBvZiBtZXRhZGF0YTogdGhlIGZy YW1lIGxlbmd0aCBhbmQgdGhlIEwyIA0KICAgIGludGVyZmFjZSBpZGVudGlmaWVyLiAgV2hlbiBy ZWNlaXZpbmcgZnJhbWVzIGZyb20gYW4gYWRqYWNlbnQgDQogICAgdXBzdHJlYW0gTEZCLCB0aGUg ZnJhbWUgaXMgYWNjb21wYW5pZWQgYnkgdHdvIGl0ZW1zIG9mIG1ldGFkYXRhOiANCiAgICBmcmFt ZSBsZW5ndGggYW5kIG91dGdvaW5nIHBvcnQgaWRlbnRpZmllci4gDQogICAgIA0KICAgIFN0YXRp c3RpY3MgYXJlIG5vdCBtYWludGFpbmVkIGJ5IHRoZSBQb3J0IExGQjsgc3RhdGlzdGljcyANCiAg ICBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0aWN1bGFyIHBvcnQgbWF5IGJlIG1haW50YWluZWQgYnkg YW4gTDIgDQogICAgaW50ZXJmYWNlIExGQiAoc2VlIFNlY3Rpb24gNi4yKS4gDQogICAgIA0KIDEu Mi4gTDIgSW50ZXJmYWNlIExGQiANCiAgICAgIA0KICAgIFRoZSBMMiBJbnRlcmZhY2UgTEZCIG1v ZGVscyBMMiBwcm90b2NvbCB0ZXJtaW5hdGlvbi4gIFRoZSBMMiANCiAgICBJbnRlcmZhY2UgTEZC IHBlcmZvcm1zIHR3byBzZXRzIG9mIGZ1bmN0aW9uczogZGVjYXBzdWxhdGlvbiBhbmQgDQogICAg ZGVtdWx0aXBsZXhpbmcgYXMgbmVlZGVkIG9uIHRoZSByZWNlaXZlIHNpZGUgb2YgYW4gRkUsIGFu ZCANCiAgICBlbmNhcHN1bGF0aW9uIGFuZCBtdWx0aXBsZXhpbmcgYXMgbmVlZGVkIG9uIHRoZSB0 cmFuc21pdCBzaWRlLiAgDQogICAgSGVuY2UgdGhlIExGQiBoYXMgdHdvIGRpc3RpbmN0IHNldHMg b2YgaW5wdXRzIGFuZCBvdXRwdXRzIHRhaWxvcmVkIA0KICAgIGZvciB0aGVzZSBzZXBhcmF0ZSBm dW5jdGlvbnMuICBUaGUgTDIgSW50ZXJmYWNlIExGQiBpcyBub3QgbW9kZWxlZCANCiAgICBhcyB0 d28gc2VwYXJhdGUgKHJlY2VpdmUvdHJhbnNtaXQpIExGQnMgYmVjYXVzZSB0aGVyZSBhcmUgc2hh cmVkIA0KICAgIGF0dHJpYnV0ZXMgYmV0d2VlbiB0aGUgZGVjYXBzdWxhdGlvbiBhbmQgZW5jYXBz dWxhdGlvbiBmdW5jdGlvbnMuIA0KICAgICAgICANCiAgICBPbiB0aGUgZGVjYXBzdWxhdGlvbiBp bnB1dChzKSwgdGhlIExGQiBhY2NlcHRzIGFuIEwyIHByb3RvY29sIA0KICAgIHNwZWNpZmljIGZy YW1lLCBhbG9uZyB3aXRoIGZyYW1lIGxlbmd0aCBhbmQgTDIgaW50ZXJmYWNlIG1ldGFkYXRhLiAg DQogICAgVGhlIExGQiBkZWNhcHN1bGF0ZXMgdGhlIEwyIGZyYW1lIGJ5IHJlbW92aW5nIGFueSBM MiANCiAgICBoZWFkZXIvdHJhaWxlcnMgKHdoaWxlIHNpbXVsdGFuZW91c2x5IGFwcGx5aW5nIGFu eSBjaGVja3N1bS9DUkMgDQogICAgZnVuY3Rpb25zKSwgZGV0ZXJtaW5lcyB0aGUgTDIgb3IgTDMg cHJvdG9jb2wgdHlwZSBvZiB0aGUgbmV4dC1sYXllciANCiAgICBwYWNrZXQgKGJhc2VkIG9uIGEg UElEIG9yIEV0aGVydHlwZSB3aXRoaW4gdGhlIEwyIGZyYW1lIGhlYWRlciksIA0KICAgIGFkanVz dHMgdGhlIGZyYW1lIGxlbmd0aCBtZXRhZGF0YSwgYW5kIHVzZXMgdGhlIEwyIGludGVyZmFjZSAN CiAgICBtZXRhZGF0YSB0byBzZWxlY3QgYW4gTDIgaW50ZXJmYWNlIGF0dHJpYnV0ZS4gIFRoZSBM MiBpbnRlcmZhY2UgDQogICAgYXR0cmlidXRlIHN1cHBvcnRzIGEgbnVtYmVyIG9mIGFkZGl0aW9u YWwgYXR0cmlidXRlcywgaW5jbHVkaW5nOiANCiAgICAgICAuIEwyIE1UVSAgDQogICAgICAgLiBz dXBwb3J0ZWQgbmV4dC1sYXllciBMMiBvciBMMyBwcm90b2NvbHMgDQogICAgICAgLiBMMi1zcGVj aWZpYyByZWNlaXZlIGNvdW50ZXJzIChieXRlLCBwYWNrZXQpIA0KICAgICAgIC4gY291bnRpbmcg bW9kZSANCiAgICAgICAuIEwyIG9yIEwzIGludGVyZmFjZSBtZXRhZGF0YSBmb3IgbmV4dC1sYXll ciBwYWNrZXQgDQogICAgICAgLiBMRkIgb3V0cHV0IHBvcnQuIA0KICAgIFRoZSBMRkIgbWF5IHN1 cHBvcnQgbXVsdGlwbGUgZGVjYXBzdWxhdGlvbiBvdXRwdXQgcG9ydHMgd2l0aGluIHR3byANCiAg ICBvdXRwdXQgZ3JvdXBzOyBvbmUgZm9yIG5vcm1hbCBmb3J3YXJkaW5nLCBhbmQgb25lIGZvciBl eGNlcHRpb24gDQogICAgcGFja2V0cy4gIFRoZSBMRkIgZW1pdHMgdGhlIGRlY2Fwc3VsYXRlZCBw YWNrZXQgYWxvbmcgd2l0aCB0aGUgDQogICAgbW9kaWZpZWQgZnJhbWUgbGVuZ3RoIG1ldGFkYXRh LCBhbiBMMiBvciBMMyBwcm90b2NvbCB0eXBlIG1ldGFkYXRhLCANCiAgICBhbmQgYW4gTDIgb3Ig TDMgaW50ZXJmYWNlIG1ldGFkYXRhLiAgDQogICAgIA0KICAgIE9uIHRoZSBlbmNhcHN1bGF0aW9u IGlucHV0KHMpLCB0aGUgTEZCIGFjY2VwdHMgYSBwYWNrZXQgYWxvbmcgd2l0aCANCiAgICBmcmFt ZSBsZW5ndGgsIHByb3RvY29sIHR5cGUsIGFuZCBMMiBpbnRlcmZhY2UgbWV0YWRhdGEuICBUaGUg TDIgDQogICAgaW50ZXJmYWNlIG1ldGFkYXRhIGlzIHVzZWQgdG8gc2VsZWN0IGFuIEwyIGludGVy ZmFjZSBhdHRyaWJ1dGUsIA0KICAgIHdoaWNoIHN1cHBvcnRzIGEgbnVtYmVyIG9mIGFkZGl0aW9u YWwgYXR0cmlidXRlcywgaW5jbHVkaW5nOiANCiAgICAgICAuIEwyLXNwZWNpZmljIHRyYW5zbWl0 IGNvdW50ZXJzIChieXRlLCBwYWNrZXQpIA0KICAgICAgIC4gY291bnRpbmcgbW9kZSAobWF5IGJl IHRha2VuIGZyb20gcmVjZWl2ZSBjb3VudGVycyBtb2RlKSANCgwgICAgICAgLiBMMiBvciBMMyBp bnRlcmZhY2UgbWV0YWRhdGEgZm9yIG5leHQtbGF5ZXIgZnJhbWUgKHdlIGFzc3VtZSANCiAgICAg ICAgIHRoYXQgTDIgcHJvdG9jb2xzIGNvdWxkIGJlIGxheWVyZWQgb24gdG9wIG9mIGFuIEwzIHBy b3RvY29sOyANCiAgICAgICAgIGUuZy4sIEwyVFAgb3IgUFdFMyksIG9yIHBvcnQgbWV0YWRhdGEu IA0KICAgICAgIC4gTEZCIG91dHB1dCBwb3J0IA0KICAgIFRoZSBMRkIgZW5jYXBzdWxhdGVzIHRo ZSBwYWNrZXQgdXNpbmcgdGhlIGFwcHJvcHJpYXRlIEwyIA0KICAgIGhlYWRlci90cmFpbGVyIGFu ZCBwcm90b2NvbCB0eXBlIGluZm9ybWF0aW9uIChjYWxjdWxhdGluZyANCiAgICBjaGVja3N1bXMv Q1JDcyBhcyBuZWNlc3NhcnkpLCBhbmQgcHJvdmlkZXMgdGhlIGZyYW1lIHRvIHRoZSBuZXh0IA0K ICAgIExGQiBhbG9uZyB3aXRoIGluY3JlbWVudGVkIGZyYW1lIGxlbmd0aCBtZXRhZGF0YSwgdXBk YXRlZCBwcm90b2NvbCANCiAgICB0eXBlIG1ldGFkYXRhLCBhbmQgdXBkYXRlZCBpbnRlcmZhY2Ug KG9yIHBvcnQpIG1ldGFkYXRhLCBvbiBhIA0KICAgIGNvbmZpZ3VyYWJsZSBMRkIgZW5jYXBzdWxh dGlvbiBvdXRwdXQuIA0KICAgICANCiAgICBBcyBpbiB0aGUgY2FzZSBvZiB0aGUgUG9ydCBMRkIs IHRlY2hub2xvZ3kgc3BlY2lmaWMgdmFyaWFudHMgb2YgdGhlIA0KICAgIEwyIGludGVyZmFjZSBM RkIgd2lsbCBiZSBzdWItY2xhc3NlcyBvZiB0aGUgTDIgSW50ZXJmYWNlIExGQi4gIA0KICAgIEV4 YW1wbGUgc3ViLWNsYXNzZXMgaW5jbHVkZTogDQogICAgICAgLiBFdGhlcm5ldC84MDIuMVEgDQog ICAgICAgLiBQUFAgDQogICAgICAgLiBBVE0gQUFMNS4gDQogICAgRWFjaCBzdWItY2xhc3Mgd2ls bCBsaWtlbHkgc3VwcG9ydCBzdGF0aWMgYW5kIGNvbmZpZ3VyYWJsZSANCiAgICBhdHRyaWJ1dGVz IHNwZWNpZmljIHRvIHRoZSBMMiB0ZWNobm9sb2d5OyBmb3IgZXhhbXBsZSB0aGUgDQogICAgRXRo ZXJuZXQvODAyLjFRIEludGVyZmFjZSBMRkIgd2lsbCBzdXBwb3J0IGEgcGVyLWludGVyZmFjZSBN QUMgDQogICAgYWRkcmVzcyBhdHRyaWJ1dGUuICBOb3RlIHRoYXQgZWFjaCB0ZWNobm9sb2d5IHNw ZWNpZmljIHN1Yi1jbGFzcyANCiAgICBtYXkgcmVxdWlyZSBhZGRpdGlvbmFsIG1ldGFkYXRhLiAg Rm9yIGV4YW1wbGUsIHRoZSBFdGhlcm5ldC84MDIuMVEgDQogICAgSW50ZXJmYWNlIExGQiByZXF1 aXJlcyBhbiBvdXRnb2luZyBNQUMgZGVzdGluYXRpb24gYWRkcmVzcyB0byANCiAgICBnZW5lcmF0 ZSBhbiBvdXRnb2luZyBFdGhlcm5ldCBoZWFkZXIuIA0KICAgICANCiAgICBUaGUgTDIgaW50ZXJm YWNlIG1hbmFnZW1lbnQgZnVuY3Rpb24gaXMgc2VwYXJhdGVkIGludG8gYSBkaXN0aW5jdCANCiAg ICBMRkIgZnJvbSB0aGUgUG9ydCBMRkIgYmVjYXVzZSBMMiBlbmNhcHN1bGF0aW9ucyBjYW4gYmUg bmVzdGVkIA0KICAgIHdpdGhpbiBmcmFtZXM7IGUuZy4sIFBQUC1vdmVyLUV0aGVybmV0LW92ZXIt QVRNIEFBTDUgKFBQUG9Fb0EpLiANCiAgICAgDQogMS4zLiBJUCBpbnRlcmZhY2UgTEZCIA0KICAg ICANCiAgICBUaGUgSVAgSW50ZXJmYWNlIExGQiBtb2RlbHMgYSBjb250YWluZXIgZm9yIElQIGlu dGVyZmFjZS1zcGVjaWZpYyANCiAgICBhdHRyaWJ1dGVzLiAgVGhlc2UgbWF5IGluY2x1ZGU6IA0K ICAgICAgIC4gSVAgcHJvdG9jb2xzIHN1cHBvcnRlZCAoSVB2NCBhbmQvb3IgSVB2NikgDQogICAg ICAgLiBJUCBNVFUgDQogICAgICAgLiBpbnRlcmZhY2UgTUlCIGNvdW50ZXJzIA0KICAgICAgIC4g dGFibGUgbWV0YWRhdGEgZm9yIGFzc29jaWF0ZWQgZm9yd2FyZGluZyB0YWJsZXMgKExQTSwgDQog ICAgICAgICBtdWx0aWNhc3QpIA0KICAgICAgIC4gdGFibGUgbWV0YWRhdGEgZm9yIGFzc29jaWF0 ZWQgY2xhc3NpZmljYXRpb24gdGFibGVzLiANCiAgICBUaGUgSVAgSW50ZXJmYWNlIExGQiBhbHNv IHBlcmZvcm1zIGJhc2ljIHByb3RvY29sLXNwZWNpZmljIHBhY2tldCANCiAgICBoZWFkZXIgdmFs aWRhdGlvbiBmdW5jdGlvbnMgKGUuZy4sIElQIHZlcnNpb24sIElQdjQgaGVhZGVyIGxlbmd0aCwg DQogICAgSVB2NCBoZWFkZXIgY2hlY2tzdW0sIE1UVSwgVFRMPTAsIGV0Yy4pLiAgVGhlIElQIElu dGVyZmFjZSBMRkIgDQogICAgY2xhc3Mgc3VwcG9ydHMgdGhyZWUgZGlmZmVyZW50IEwzIHByb3Rv Y29sczogSVB2NCwgSVB2NiwgYW5kIE1QTFMsIA0KICAgIGFsdGhvdWdoIGluZGl2aWR1YWwgTEZC IGluc3RhbmNlcyBtaWdodCBzdXBwb3J0IGEgc3Vic2V0IG9mIHRoZXNlIA0KICAgIHByb3RvY29s cywgY29uZmlndXJhYmxlIG9uIGVhY2ggaW50ZXJmYWNlIGF0dHJpYnV0ZS4gDQogICAgIA0KICAg IEFzIHdpdGggdGhlIEwyIEludGVyZmFjZSBMRkIsIHRoZSBJUCBJbnRlcmZhY2UgTEZCIHN1cHBv cnRzIHR3byANCiAgICBtb2RlcyBvZiBvcGVyYXRpb246IG9uZSBuZWVkZWQgb24gdGhlIHJlY2Vp dmUgc2lkZSBvZiBhbiBGRSwgYW5kIA0KICAgIG9uZSBvbiB0aGUgdHJhbnNtaXQgc2lkZSwgdXNp bmcgc2VwYXJhdGUgc2V0cyBvZiBMRkIgaW5wdXRzIGFuZCANCiAgICBvdXRwdXRzLiAgSW4gdGhl IGZpcnN0IG1vZGUgb2Ygb3BlcmF0aW9uIChmb3IgRkUgcmVjZWl2ZSANCiAgICBwcm9jZXNzaW5n KSwgdGhlIElQIEludGVyZmFjZSBMRkIgYWNjZXB0cyBJUCBwYWNrZXRzIGFsb25nIHdpdGggDQog ICAgZnJhbWUgbGVuZ3RoLCBMMyBwcm90b2NvbCB0eXBlLCBhbmQgaW50ZXJmYWNlIG1ldGFkYXRh IChwb3NzaWJseSANCgwgICAgaW5jbHVkaW5nIGFkZGl0aW9uYWwgbWV0YWRhdGEgaXRlbXMgc3Vj aCBhcyBMMi1kZXJpdmVkIGNsYXNzIA0KICAgIG1ldGFkYXRhKS4gIFRoZSBpbnRlcmZhY2UgbWV0 YWRhdGEgaXMgdXNlZCB0byBzZWxlY3QgYW4gaW50ZXJmYWNlIA0KICAgIGF0dHJpYnV0ZSwgYW5k IHRoZSBwcm90b2NvbCB0eXBlIGlzIGNoZWNrZWQgYWdhaW5zdCB0aGUgcHJvdG9jb2xzIA0KICAg IHN1cHBvcnRlZCBmb3IgdGhpcyBpbnRlcmZhY2UuICBFcnJvciBjaGVja3MgYXJlIGFwcGxpZWQs IGluY2x1ZGluZyANCiAgICB3aGV0aGVyIHRoZSBwYXJ0aWN1bGFyIHByb3RvY29sIHR5cGUgaXMg c3VwcG9ydGVkIG9uIHRoaXMgDQogICAgaW50ZXJmYWNlLCBhbmQgaWYgbm8gZXJyb3JzIG9jY3Vy LCB0aGUgYXBwcm9wcmlhdGUgY291bnRlcnMgYXJlIA0KICAgIGluY3JlbWVudGVkIGFuZCB0aGUg cHJvdG9jb2wgdHlwZSBpcyB1c2VkIHRvIHNlbGVjdCB0aGUgb3V0Z29pbmcgDQogICAgTEZCIG91 dHB1dCBmcm9tIGEgc2V0IGRlZGljYXRlZCB0byB0aGUgZmlyc3QgbW9kZSBvZiBvcGVyYXRpb24u ICANCiAgICBUaGUgSVAgaGVhZGVyIHByb3RvY29sIHR5cGUvbmV4dCBoZWFkZXIgZmllbGQgbWF5 IGFsc28gYmUgdXNlZCB0byANCiAgICBzZWxlY3QgYW4gTEZCIG91dHB1dDsgZm9yIGV4YW1wbGUs IElQdjQgcGFja2V0cyB3aXRoIEFIIGhlYWRlciBtYXkgDQogICAgYmUgZGlyZWN0ZWQgdG8gYSBw YXJ0aWN1bGFyIG5leHQgTEZCLCBvciBJUHY2IHBhY2tldHMgd2l0aCBIb3AtYnktDQogICAgSG9w IE9wdGlvbnMuICBJZiBlcnJvcnMgZG8gb2NjdXIsIHRoZSBhcHByb3ByaWF0ZSBlcnJvciBjb3Vu dGVycyANCiAgICBhcmUgaW5jcmVtZW50ZWQsIGFuZCB0aGUgZXJyb3IgdHlwZSBpcyB1c2VkIHRv IHNlbGVjdCBhIHNwZWNpZmljIA0KICAgIGV4Y2VwdGlvbiBMRkIgb3V0cHV0LiANCiAgICAgDQog ICAgSW4gdGhlIHNlY29uZCBtb2RlIG9mIG9wZXJhdGlvbiAoZm9yIEZFIHRyYW5zbWl0IHByb2Nl c3NpbmcpLCB0aGUgDQogICAgSVAgSW50ZXJmYWNlIExGQiBhY2NlcHRzIGFuIElQIHBhY2tldCBh bG9uZyB3aXRoIGZyYW1lIGxlbmd0aCwgDQogICAgcHJvdG9jb2wgdHlwZSwgYW5kIGludGVyZmFj ZSBtZXRhZGF0YS4gIEFnYWluLCB0aGUgaW50ZXJmYWNlIA0KICAgIG1ldGFkYXRhIGlzIHVzZWQg dG8gc2VsZWN0IGFuIGludGVyZmFjZSBhdHRyaWJ1dGUuICBUaGUgaW50ZXJmYWNlIA0KICAgIGF0 dHJpYnV0ZSBzdG9yZXMgdGhlIG91dGdvaW5nIEwyIG9yIElQIGludGVyZmFjZSAoZS5nLiwgdHVu bmVsKSANCiAgICBpbnRlcmZhY2UgbWV0YWRhdGEuICBUaGUgSVAgTVRVIG9mIHRoZSBvdXRnb2lu ZyBpbnRlcmZhY2UgaXMgDQogICAgY2hlY2tlZCwgYWxvbmcgd2l0aCB0aGUgcHJvdG9jb2wgdHlw ZSBvZiB0aGUgcGFja2V0LiAgSWYgbm8gZXJyb3JzIA0KICAgIG9jY3VyLCB0aGUgYXBwcm9wcmlh dGUgY291bnRlcnMgYXJlIGluY3JlbWVudGVkLCBhbmQgdGhlIG5leHQgbGV2ZWwgDQogICAgaW50 ZXJmYWNlIG1ldGFkYXRhIG1heSBiZSB1c2VkIHRvIHNlbGVjdCBhbiBJUCBJbnRlcmZhY2UgTEZC IG91dHB1dCANCiAgICBkZWRpY2F0ZWQgdG8gdGhlIHNlY29uZCBtb2RlIG9mIG9wZXJhdGlvbi4g IE90aGVyd2lzZSwgdGhlIA0KICAgIGFwcHJvcHJpYXRlIGVycm9yIGNvdW50ZXJzIGFyZSBpbmNy ZW1lbnRlZCwgYW5kIHRoZSBlcnJvciB0eXBlIGlzIA0KICAgIHVzZWQgdG8gc2VsZWN0IGFuIGV4 Y2VwdGlvbiBvdXRwdXQuIA0KICAgICANCiAgICBCZWNhdXNlIHRoZSBJUCBJbnRlcmZhY2UgTEZC IGlzIHRoZSByZXBvc2l0b3J5IGZvciB0aGUgaW50ZXJmYWNlIA0KICAgIE1JQiBjb3VudGVycywg dHdvIHNwZWNpYWwgcGFpcnMgb2YgaW5wdXRzIGFyZSBwcm92aWRlZCBmb3IgcGFja2V0cyANCiAg ICB3aGljaCBoYXZlIGJlZW4gc2VsZWN0ZWQgdG8gYmUgZGlzY2FyZGVkIGZ1cnRoZXIgZG93bnN0 cmVhbSAob25lIA0KICAgIGVhY2ggZm9yIHRoZSByZWNlaXZlIGFuZCB0cmFuc21pdCBjb3VudGVy cykuICBQYWNrZXRzIGFycml2aW5nIG9uIA0KICAgIHRoZXNlIExGQiBpbnB1dHMgbXVzdCBiZSBh Y2NvbXBhbmllZCBieSBmcmFtZSBsZW5ndGggYW5kIEwzIA0KICAgIGludGVyZmFjZSBtZXRhZGF0 YS4gIEFuIGV4Y2VwdGlvbiBvdXRwdXQgb24gdGhlIExGQiBzaG91bGQgYmUgDQogICAgY29ubmVj dGVkIHRvIGEgZHJvcHBlciBMRkIuIA0KICAgICANCiAxLjQuIENsYXNzaWZpZXIgTEZCIA0KICAg ICAgICAgIA0KICAgIFRoZSBmdW5jdGlvbiBvZiBjbGFzc2lmaWNhdGlvbiBpcyB0byBsb2dpY2Fs bHkgcGFydGl0aW9uIHBhY2tldHMgDQogICAgaW50byBvbmUgb2YgTiBkaWZmZXJlbnQgY2xhc3Nl cywgYmFzZWQgb24gc29tZSBzZXF1ZW5jZSBvZiBvbmUgb3IgDQogICAgbW9yZSBtYXRoZW1hdGlj YWwgb3BlcmF0aW9ucyBhcHBsaWVkIHRvIHRoZSBwYWNrZXQgYW5kIGl0cyANCiAgICBhc3NvY2lh dGVkIG1ldGFkYXRhLiAgVmFyaW91cyBMRkJzIHBlcmZvcm0gYW4gaW50cmluc2ljIA0KICAgIGNs YXNzaWZpY2F0aW9uIGZ1bmN0aW9uLiAgV2hlcmUgdGhpcyBmdW5jdGlvbiBpcyBhIHdlbGwtZGVm aW5lZCANCiAgICBwcm90b2NvbCBvcGVyYXRpb24sIGEgc2VwYXJhdGUgTEZCIG1heSBiZSBkZWZp bmVkIChlLmcuLCBJUCANCiAgICBJbnRlcmZhY2UgTEZCLCB3aGljaCBwZXJmb3JtcyBoZWFkZXIg dmVyaWZpY2F0aW9uKS4gICANCiAgICAgDQogICAgU2V2ZXJhbCBjb21tb24gYXBwbGljYXRpb25z IG5lZWQgdG8gY2xhc3NpZnkgcGFja2V0cyB1c2luZyBhIA0KICAgIHBhcnRpY3VsYXIgbWF0aGVt YXRpY2FsIG9wZXJhdGlvbiAoZS5nLiwgbG9uZ2VzdCBwcmVmaXggbWF0Y2ggKExQTSkgDQogICAg b3IgdGVybmFyeSBtYXRjaCkgYWdhaW5zdCBhIGZpeGVkIHNldCBvZiBmaWVsZHMgaW4gYSBwYWNr ZXQncyANCiAgICBoZWFkZXIgcGx1cyBtZXRhZGF0YSwgb3IgYW4gZWFzaWx5IHJlY29nbml6ZWQg cGFydCBvZiB0aGUgcGFja2V0IA0KICAgIHBheWxvYWQuICBUd28gZXhhbXBsZSBhcHBsaWNhdGlv bnMgYXJlIGNsYXNzaWZpY2F0aW9uIGZvciANCiAgICBEaWZmZXJlbnRpYXRlZCBTZXJ2aWNlcyBv ciBmb3Igc2VjdXJpdHkgcHJvY2Vzc2luZy4gIFR5cGljYWxseSB0aGUgDQoMICAgIHBhY2tldCBp cyBldmFsdWF0ZWQgYWdhaW5zdCBhIHBvdGVudGlhbGx5IGxhcmdlIHNldCBvZiBydWxlcyANCiAg ICAoY2FsbGVkICJmaWx0ZXJzIiksIHdoaWNoIGFyZSBwcm9jZXNzZWQgaW4gYSBwYXJ0aWN1bGFy IG9yZGVyIHRvIA0KICAgIGVuc3VyZSBhIGRldGVybWluaXN0aWMgcmVzdWx0LiAgVGhpcyBzb3J0 IG9mIGNsYXNzaWZpY2F0aW9uIA0KICAgIGZ1bmN0aW9uYWxpdHkgaXMgbW9kZWxlZCBieSB0aGUg Q2xhc3NpZmllciBMRkIuIA0KICAgICANCiAgICBUaGUgQ2xhc3NpZmllciBMRkIgYWNjZXB0cyBh biBpbnB1dCBwYWNrZXQgYW5kIG1ldGFkYXRhLCBhbmQgDQogICAgcHJvZHVjZXMgdGhlIHVubW9k aWZpZWQgcGFja2V0IGFsb25nIHdpdGggYSBjbGFzcyBtZXRhZGF0YSwgd2hpY2ggDQogICAgbWF5 IGJlIHVzZWQgdG8gbWFwIHRoZSBwYWNrZXQgdG8gYSBwYXJ0aWN1bGFyIExGQiBvdXRwdXQuIA0K ICAgICANCiAgICBUaGUgQ2xhc3NpZmllciBMRkIgc3VwcG9ydHMgbXVsdGlwbGUgY2xhc3NpZmll ciBhdHRyaWJ1dGVzLiAgRWFjaCANCiAgICBjbGFzc2lmaWVyIGlzIHBhcmFtZXRlcml6ZWQgYnkg b25lIG9yIG1vcmUgZmlsdGVycy4gIENsYXNzaWZpY2F0aW9uIA0KICAgIGlzIHBlcmZvcm1lZCBi eSBzZWxlY3RpbmcgdGhlIGNsYXNzaWZpZXIgdG8gdXNlIG9uIGEgcGFydGljdWxhciANCiAgICBw YWNrZXQgKGUuZy4sIGJ5IG1ldGFkYXRhIGxvb2t1cCBvbiBhIGNvbmZpZ3VyYWJsZSBtZXRhZGF0 YSBpdGVtKSwgDQogICAgYW5kIGJ5IGV2YWx1YXRpbmcgdGhlIHNlbGVjdGVkIGNvbnRlbnRzIG9m IHRoZSBhY2NlcHRlZCBwYWNrZXQgDQogICAgYWdhaW5zdCB0aGF0IGNsYXNzaWZpZXIncyBmaWx0 ZXJzLiAgQSBmaWx0ZXIgZGVjaWRlcyBpZiB0aGUgaW5wdXQgDQogICAgcGFja2V0IHNhdGlzZmll cyBwYXJ0aWN1bGFyIGNyaXRlcmlhLiAgQWNjb3JkaW5nIHRvIFtEaWZmU2Vydl0sICJhIA0KICAg IGZpbHRlciBjb25zaXN0cyBvZiBhIHNldCBvZiBjb25kaXRpb25zIG9uIHRoZSBjb21wb25lbnQg dmFsdWVzIG9mIGEgDQogICAgcGFja2V0J3MgY2xhc3NpZmljYXRpb24ga2V5ICh0aGUgaGVhZGVy IHZhbHVlcywgY29udGVudHMsIGFuZCANCiAgICBhdHRyaWJ1dGVzIHJlbGV2YW50IGZvciBjbGFz c2lmaWNhdGlvbikiLiAgDQogICAgICAgICAgDQogICAgTm90ZSB0aGF0IG90aGVyIExGQnMgbWF5 IHBlcmZvcm0gc2ltcGxlIGNsYXNzaWZpY2F0aW9uIG9uIHRoZSANCiAgICBwYWNrZXQgb3IgaXRz IG1ldGFkYXRhLiAgVGhlIHB1cnBvc2Ugb2YgdGhlIENsYXNzaWZpZXIgTEZCIGlzIHRvIA0KICAg IG1vZGVsIGFuIExGQiB0aGF0ICJkaWdlc3RzIiBsYXJnZSBhbW91bnRzIG9mIGlucHV0IGRhdGEg KHBhY2tldCwgDQogICAgbWV0YWRhdGEpLCB0byBwcm9kdWNlIGEgInN1bW1hcnkiIG9mIHRoZSBj bGFzc2lmaWNhdGlvbiByZXN1bHRzLCBpbiANCiAgICB0aGUgZm9ybSBvZiBhZGRpdGlvbmFsIChv ciBtb2RpZmllZCkgbWV0YWRhdGEuICBPdGhlciBMRkJzIGNhbiB0aGVuIA0KICAgIHVzZSB0aGlz IHN1bW1hcnkgaW5mb3JtYXRpb24gdG8gcXVpY2tseSBhbmQgc2ltcGx5IHBlcmZvcm0gdHJpdmlh bCANCiAgICBjbGFzc2lmaWNhdGlvbiBvcGVyYXRpb25zLiAgDQogICAgIA0KICAgIFRoZSBDbGFz c2lmaWVyIExGQiBjYW4gYmUgc3ViLWNsYXNzZWQgaW50byBzZXZlcmFsIGZ1bmN0aW9uLQ0KICAg IHNwZWNpZmljIExGQiBjbGFzc2VzIHdoaWNoIHBlcmZvcm0gY29tbW9uIGNsYXNzaWZpY2F0aW9u IGZ1bmN0aW9ucy4gIA0KICAgIFRoZXNlIG1heSBpbmNsdWRlOiANCiAgICAgICAuIExvbmdlc3Qg UHJlZml4IE1hdGNoIChMUE0pIA0KICAgICAgIC4gSVAgTXVsdGljYXN0IGxvb2t1cCAoUyxHKSAN CiAgICAgICAuIE11bHRpZmllbGQgRXhhY3QgTWF0Y2ggDQogICAgICAgLiBNdWx0aWZpZWxkIFRl cm5hcnkgTWF0Y2guIA0KICAgICANCiAxLjUuIE5leHQgSG9wIExGQiANCiAgICAgDQogICAgVGhl IE5leHQgSG9wIExGQiBpcyB1c2VkIHRvIHJlc29sdmUgbmV4dCBob3AgaW5mb3JtYXRpb24gZm9s bG93aW5nIA0KICAgIGEgZm9yd2FyZGluZyBsb29rdXAuICBOZXh0IEhvcCBpbmZvcm1hdGlvbiBu b3JtYWxseSBpbmNsdWRlcyB0aGUgDQogICAgb3V0Z29pbmcgaW50ZXJmYWNlIChvciBpbnRlcmZh Y2VzLCBpbiB0aGUgY2FzZSBvZiBtdWx0aWNhc3QpLCBhcyANCiAgICB3ZWxsIGFzIHRoZSBvdXRn b2luZyBJUCBhZGRyZXNzKGVzKS4gIFRoaXMgbmV4dCBob3AgaW5mb3JtYXRpb24gDQogICAgYXNz b2NpYXRlZCB3aXRoIGEgZm9yd2FyZGluZyBwcmVmaXggb3IgY2xhc3NpZmljYXRpb24gcnVsZSBp cyBvZnRlbiANCiAgICBzZXBhcmF0ZWQgaW50byBhIHNlcGFyYXRlIGRhdGEgc3RydWN0dXJlIGlu IGltcGxlbWVudGF0aW9ucyB0byANCiAgICBhbGxvdyB0aGUgdHdvIHBpZWNlcyBvZiBpbmZvcm1h dGlvbiB0byBiZSBkZWNvdXBsZWQsIGJlY2F1c2UgdGhlcmUgDQogICAgaXMgZnJlcXVlbnRseSBh IGZhbi1pbiByZWxhdGlvbnNoaXAgYmV0d2VlbiBmb3J3YXJkaW5nIHByZWZpeC9ydWxlIA0KICAg IGVudHJpZXMgYW5kIG5leHQgaG9wIGluZm9ybWF0aW9uLCBhbmQgZGVjb3VwbGluZyB0aGVtIGNh biBwZXJtaXQgDQogICAgbW9yZSBlZmZpY2llbnQgZGF0YSBzdHJ1Y3R1cmUgbWFuYWdlbWVudC4g ICANCiAgICAgICAgDQogICAgVGhlIE5leHQgSG9wIExGQiBtYWludGFpbnMgbmV4dCBob3AgYXR0 cmlidXRlcyBvcmdhbml6ZWQgaW50byANCiAgICBtdWx0aXBsZSBuZXh0IGhvcCB0YWJsZXMuICBU aGUgcmVsZXZhbnQgdGFibGUgZm9yIGEgcGFja2V0IGlzIA0KDCAgICBzZWxlY3RlZCBiYXNlZCBv biBuZXh0IGhvcCB0YWJsZSBtZXRhZGF0YS4gIEEgc2V0IG9mIG9uZSBvciBtb3JlIA0KICAgIG5l eHQgaG9wIGF0dHJpYnV0ZXMgaXMgc2VsZWN0ZWQgYmFzZWQgb24gbmV4dCBob3AgaW5kZXggbWV0 YWRhdGEuIA0KICAgIEVhY2ggbmV4dCBob3AgYXR0cmlidXRlIHN0b3JlcyB0aGUgZm9sbG93aW5n IGluZm9ybWF0aW9uOiANCiAgICAgICAuIGEgbGlzdCBvZiBvbmUgb3IgbW9yZSBvdXRnb2luZyBp bnRlcmZhY2VzICANCiAgICAgICAuIG5leHQgaG9wIElQIGFkZHJlc3Nlcywgb3IsIGFuIGluZGV4 IHRvIGEgdGFibGUgb2YgdGhpcyANCiAgICAgICAgIGluZm9ybWF0aW9uICANCiAgICAgICAuIHRo YXQgaXMgbWFpbnRhaW5lZCBhdCBhIGRvd25zdHJlYW0gTEZCIA0KICAgICAgIC4gYSBsaXN0IG9m IG91dGdvaW5nIE1UVXMgDQogICAgICAgLiBUVEwgZGVjcmVtZW50IHZhbHVlIA0KICAgICANCiAg ICBUaGUgTmV4dCBIb3AgTEZCIGhhcyB0d28gcHJpbWFyeSBvcGVyYXRpb25zLiAgVGhlIGZpcnN0 IGlzIHRvIG1hcCANCiAgICB0aGUgaW5jb21pbmcgbmV4dCBob3AgdGFibGUgYW5kIG5leHQgaG9w IGluZGV4IG1ldGFkYXRhIGludG8gYSANCiAgICBjb25maWd1cmFibGUgbmV4dCBob3AgYXR0cmli dXRlLiAgVGhpcyBtYXBwaW5nIG1heSBiZSBkaXJlY3QgKG9uZSANCiAgICBtZXRhZGF0YSBwYWly IHRvIG9uZSBuZXh0IGhvcCBhdHRyaWJ1dGUpLiAgSWYgdGhlIG5leHQgaG9wIGluZGV4IA0KICAg IG1ldGFkYXRhIHNlbGVjdHMgYSBzZXQgb2YgbmV4dCBob3AgYXR0cmlidXRlcywgZmluYWwgYXR0 cmlidXRlIA0KICAgIHJlc29sdXRpb24gZGVwZW5kcyBvbiBhIHNlbGVjdGlvbiBhbGdvcml0aG0g dGhhdCB1c2VzIHNvbWUgDQogICAgYWRkaXRpb25hbCBtZXRhZGF0YSwgb3IgYW4gaW50ZXJuYWwg Y2xhc3NpZmljYXRpb24gb3BlcmF0aW9uLCB0byANCiAgICBzZWxlY3QgYW1vbmcgYSBzZXQgb2Yg cG9zc2libGUgbmV4dCBob3AgYXR0cmlidXRlcy4gIE9uZSBleGFtcGxlIGlzIA0KICAgIHdlaWdo dGVkIG5leHQgaG9wIHNlbGVjdGlvbiwgd2hlcmUgaW5kaXZpZHVhbCBwYWNrZXRzIGFyZSBtYXBw ZWQgdG8gDQogICAgcGFydGljdWxhciBuZXh0IGhvcCBhdHRyaWJ1dGVzIGluIHRoZSBzZXQgYWNj b3JkaW5nIHRvIHdlaWdodHMgYW5kIA0KICAgIHRvIHNvbWUgZmxvdyBvcmRlci1wcmVzZXJ2aW5n IGZ1bmN0aW9uIChlLmcuLCBzdWNoIGFzIGFuIGFkZHJlc3MgDQogICAgcGFpciBoYXNoKS4gIEFu b3RoZXIgYWx0ZXJuYXRpdmUgaXMgY2xhc3MtYmFzZWQgbmV4dCBob3Agc2VsZWN0aW9uLCANCiAg ICBiYXNlZCBvbiBzb21lIGNsYXNzIG1ldGFkYXRhLiANCiAgICAgDQogICAgVGhlIHNlY29uZCBv cGVyYXRpb24gaXMgYSBkZXJpdmF0aXZlIG9mIHRoZSBmaXJzdC4gIFRoZSBuZXh0IGhvcCANCiAg ICB0YWJsZSBhbmQgbmV4dCBob3AgaW5kZXggbWV0YWRhdGEgYXJlIHVzZWQgdG8gc2VsZWN0IGEg c2V0IG9mIG9uZSANCiAgICBvciBtb3JlIG5leHQgaG9wIGF0dHJpYnV0ZXMuICBUaGVuIHRoZSBv dXRnb2luZyBpbnRlcmZhY2UgdmFsdWVzIA0KICAgIHN0b3JlZCBpbiB0aG9zZSBhdHRyaWJ1dGVz IGFyZSBjb21wYXJlZCBhZ2FpbnN0IHRoZSBpbmNvbWluZyANCiAgICBpbnRlcmZhY2UgbWV0YWRh dGEgcHJvdmlkZWQgdG8gdGhlIE5leHQgSG9wIExGQiwgdG8gZGV0ZXJtaW5lIA0KICAgIHdoZXRo ZXIgdGhlIGluY29taW5nIGludGVyZmFjZSBpcyBpbiB0aGUgc2V0LiAgVGhpcyBvcGVyYXRpb24s IGluIA0KICAgIGNvbWJpbmF0aW9uIHdpdGggYSBJUCBzb3VyY2UgYWRkcmVzcyBmb3J3YXJkaW5n IGxvb2t1cCAod2hpY2ggDQogICAgcHJvdmlkZXMgdGhlIG5leHQgaG9wIHRhYmxlL2luZGV4IG1l dGFkYXRhKSwgY2FuIGJlIHVzZWQgdG8gcGVyZm9ybSANCiAgICBhIHJldmVyc2UgcGF0aCBmb3J3 YXJkaW5nIChSUEYpIGNoZWNrLiANCiAgICAgDQogICAgVGhlIE5leHQgSG9wIExGQiBoYXMgdHdv IGlucHV0czogb25lIGZvciBub3JtYWwgbmV4dCBob3AgDQogICAgcmVzb2x1dGlvbiwgYW5kIG9u ZSBmb3IgdGhlIGluY29taW5nIGludGVyZmFjZSBtZXRhZGF0YSB0ZXN0IChlLmcuLCANCiAgICBS UEYpLiAgVGhlIExGQiByZXF1aXJlcyBpbmNvbWluZyBpbnRlcmZhY2UsIGZyYW1lIGxlbmd0aCwg bmV4dCBob3AgDQogICAgdGFibGUsIGFuZCBuZXh0IGhvcCBpbmRleCBtZXRhZGF0YS4gIFRoZXJl IGFyZSB0d28gbm9ybWFsIG91dHB1dCANCiAgICBncm91cHMsIG9uZSBmb3IgdGhlIG5vcm1hbCBu ZXh0IGhvcCByZXNvbHV0aW9uLCBhbmQgYW5vdGhlciBmb3IgdGhlIA0KICAgIFJQRiBjaGVjay4g IE5vIGFkZGl0aW9uYWwgbWV0YWRhdGEgaXMgcHJvZHVjZWQgZm9yIHRoZSBsYXR0ZXIsIGJ1dCAN CiAgICBmb3IgdGhlIGZvcm1lciwgdGhlIGZvbGxvd2luZyBtZXRhZGF0YSBtYXkgYmUgcHJvZHVj ZWQ6IA0KICAgICAgIC4gb3V0Z29pbmcgaW50ZXJmYWNlKHMpIA0KICAgICAgIC4gbmV4dCBob3Ag SVAgYWRkcmVzcyhlcykgDQogICAgICAgLiBUVEwgZGVjcmVtZW50IHZhbHVlIChpZiBUVEwgZGVj cmVtZW50IGlzIG5vdCBwZXJmb3JtZWQgYnkgdGhlIA0KICAgICAgICAgTmV4dCBIb3AgTEZCKSAN CiAgICBBbiBhbHRlcm5hdGl2ZSBtb2RlIG9mIG9wZXJhdGlvbiBwcm9kdWNlcyBpbmRleCBtZXRh ZGF0YSBpbnN0ZWFkIG9mIA0KICAgIG91dGdvaW5nIGludGVyZmFjZSBhbmQgbmV4dCBob3AgSVAg YWRkcmVzcyBtZXRhZGF0YS4gIFRoaXMgaW5kZXggDQogICAgbWV0YWRhdGEgaXMgdXNlZCB0byBh Y2Nlc3MgYSBjYWNoZSBvZiB0aGUgb3V0Z29pbmcgaW50ZXJmYWNlIGFuZCANCiAgICBuZXh0IGhv cCBJUCBhZGRyZXNzIHRoYXQgbWF5IGJlIHN0b3JlZCBvbiB0aGUgZWdyZXNzIEZFICh0aGlzIA0K ICAgIHBlcm1pdHMgbW9yZSBlZmZpY2llbnQgY29tbXVuaWNhdGlvbiBhY3Jvc3MgdGhlIEZFIGlu dGVyZmFjZSkuICANCiAgICBUaGlzIGluZGV4IG1ldGFkYXRhIGNhbiBhbHNvIGJlIHVzZWQgYXMg aW5wdXQgbWV0YWRhdGEgdG8gYSBNUExTIA0KICAgIEVuY2Fwc3VsYXRpb24gTEZCLiAgIA0KDCAg ICAgDQogICAgVGhlIE5leHQgSG9wIExGQiBzdXBwb3J0cyBhbiBleGNlcHRpb24gb3V0cHV0IHBv cnQgZ3JvdXAuICANCiAgICBFeGNlcHRpb24gY29uZGl0aW9ucyBpbmNsdWRlOiANCiAgICAgICAu IFJQRiB0ZXN0IGZhaWxlZCANCiAgICAgICAuIE5vIHJvdXRlIHRvIGhvc3QgDQogICAgICAgLiBO byByb3V0ZSB0byBuZXR3b3JrIA0KICAgICAgIC4gUGFja2V0IHRvbyBiaWcgDQogICAgICAgLiBU VEwgZXhwaXJlZCANCiAgICBUaGUgbWFwcGluZyBiZXR3ZWVuIGV4Y2VwdGlvbiBjb25kaXRpb25z IGFuZCBleGNlcHRpb24gb3V0cHV0cyBpcyANCiAgICBjb25maWd1cmFibGUsIGFuZCBhbiBleGNl cHRpb24gY29kZSBtZXRhZGF0YSBpcyBwcm9kdWNlZCBvbiB0aGVzZSANCiAgICBvdXRwdXRzLiAN CiAgICAgDQogMS42LiBSYXRlIE1ldGVyIExGQiANCiAgICAgICAgIA0KICAgIFRoZSBSYXRlIE1l dGVyIExGQiBpcyB1c2VkIHRvIG1ldGVyIHRoZSBwYWNrZXQgZmxvdyB0aHJvdWdoIHRoZSBMRkIg DQogICAgYWNjb3JkaW5nIHRvIGEgcmF0ZS0gYW5kIHRpbWUtZGVwZW5kZW50IGZ1bmN0aW9uLiAg UGFja2V0cyBhcmUgDQogICAgcHJvdmlkZWQgdG8gdGhlIFJhdGUgTWV0ZXIgTEZCIGFsb25nIHdp dGggcGFja2V0IGxlbmd0aCBtZXRhZGF0YSANCiAgICAoYW5kIG9wdGlvbmFsIGNvbG9yIG1ldGFk YXRhKSBhbmQgYXJlIGFzc29jaWF0ZWQgd2l0aCBhIG1ldGVyIA0KICAgIGF0dHJpYnV0ZSBlaXRo ZXIgc3RhdGljYWxseSAoYmFzZWQgb24gTEZCIGlucHV0KSBvciB2aWEgc29tZSBvdGhlciANCiAg ICBjb25maWd1cmFibGUgbWV0YWRhdGEgaXRlbS4gIFRoZSBtZXRlcmluZyBhbGdvcml0aG0gb2Yg dGhlIA0KICAgIGFzc29jaWF0ZWQgbWV0ZXIgYXR0cmlidXRlIGlzIGFwcGxpZWQgdG8gdGhlIHBh Y2tldCwgdXNpbmcgdGhlIA0KICAgIHBhY2tldCBsZW5ndGggYW5kIHRoZSBjdXJyZW50IHRpbWUg YXMgaW5wdXRzLCBhbG9uZyB3aXRoIHByZXZpb3VzIA0KICAgIHN0YXRlIG1haW50YWluZWQgYnkg dGhlIGF0dHJpYnV0ZS4gIEEgY29sb3IgbWV0YWRhdGEgaXMgYXNzb2NpYXRlZCANCiAgICB3aXRo IHRoZSBwYWNrZXQgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBtZXRlcmluZyBhbGdvcml0aG0gdXNl ZC4gIA0KICAgIFRoZSBjb2xvciBtZXRhZGF0YSBpcyBvcHRpb25hbGx5IGVtaXR0ZWQgd2l0aCB0 aGUgcGFja2V0LCBvciB1c2VkIA0KICAgIHRvIG1hcCB0aGUgcGFja2V0IHRvIGEgcGFydGljdWxh ciBMRkIgb3V0cHV0LiAgQ29sb3ItYXdhcmUgbWV0ZXJpbmcgDQogICAgYWxnb3JpdGhtcyB1c2Ug Y29sb3IgbWV0YWRhdGEgaWYgcHJvdmlkZWQgd2l0aCB0aGUgcGFja2V0IChlLmcuLCBieSANCiAg ICBhIENsYXNzaWZpZXIgTEZCKSwgb3IgYXNzdW1lIGEgZGVmYXVsdCBjb2xvciB2YWx1ZS4gDQog ICAgICAgICANCiAgICBUaGUgUmF0ZSBNZXRlciBMRkIgc3VwcG9ydHMgYSBudW1iZXIgb2Ygc3Rh dGljIGF0dHJpYnV0ZXMsIA0KICAgIGluY2x1ZGluZzogDQogICAgICAgLiBzdXBwb3J0ZWQgbWV0 ZXJpbmcgYWxnb3JpdGhtcyANCiAgICAgICAuIG1heGltdW0gbnVtYmVyIG9mIG1ldGVyIGF0dHJp YnV0ZXMgDQogICAgIA0KICAgIFRoZSBSYXRlIE1ldGVyIExGQiBzdXBwb3J0cyBhIG51bWJlciBv ZiBjb25maWd1cmFibGUgYXR0cmlidXRlcywgDQogICAgaW5jbHVkaW5nOiANCiAgICAgICAuIG51 bWJlciBvZiBMRkIgaW5wdXRzIA0KICAgICAgIC4gbnVtYmVyIG9mIExGQiBvdXRwdXRzIA0KICAg ICAgIC4gbWFwcGluZyBvZiBMRkIgaW5wdXQgdG8gbWV0ZXIgYXR0cmlidXRlICh3aGVuIG1hcHBl ZCANCiAgICAgICAgIHN0YXRpY2FsbHkpIA0KICAgICAgIC4gbWV0YWRhdGEgaXRlbSB0byBzZWxl Y3QgZm9yIG1hcHBpbmcgdG8gbWV0ZXIgYXR0cmlidXRlIA0KICAgICAgIC4gbWFwcGluZyBvZiBt ZXRhZGF0YSB2YWx1ZSB0byBtZXRlciBhdHRyaWJ1dGUgDQogICAgICAgLiBkZWZhdWx0IG1ldGVy IGF0dHJpYnV0ZSAod2hlbiBub3QgbWFwcGVkIHN0YXRpY2FsbHkgb3IgdmlhIA0KICAgICAgICAg Y29ycmVjdCANCiAgICAgICAuIG1ldGFkYXRhKSANCiAgICAgICAuIHBlci1hdHRyaWJ1dGUgbWV0 ZXJpbmcgYWxnb3JpdGhtIA0KICAgICAgIC4gcGVyLWF0dHJpYnV0ZSBtZXRlcmluZyBwYXJhbWV0 ZXJzLCBpbmNsdWRpbmc6IA0KICAgICAgIC4gbWluaW11bSByYXRlIA0KICAgICAgIC4gbWF4aW11 bSByYXRlIA0KICAgICAgIC4gYnVyc3Qgc2l6ZSANCiAgICAgICAuIGNvbG9yIG1ldGFkYXRhIGVu YWJsZSANCiAgICAgICAuIG1hcHBpbmcgb2YgcGFja2V0IGNvbG9yIHRvIExGQiBvdXRwdXQgDQoM ICAgICANCiAgICBBIFJhdGUgTWV0ZXIgTEZCIGNhbiBiZSB1c2VkIHRvIGltcGxlbWVudCBhIHBv bGljaW5nIGZ1bmN0aW9uLCBieSANCiAgICBjb25uZWN0aW5nIGEgTEZCIG91dHB1dCBkaXJlY3Rs eSB0byBhIERyb3BwZXIgTEZCLCBhbmQgbWFwcGluZyBub24tIA0KICAgIGNvbmZvcm1pbmcgKGUu Zy4sICJyZWQiKSB0cmFmZmljIHRvIHRoYXQgb3V0cHV0LiANCiAgICAgICAgICANCiAxLjcuIFJl ZGlyZWN0b3IgKGRlLU1VWCkgTEZCICANCiAgICAgICANCiAgICBUaGUgUmVkaXJlY3RvciBMRkIg aXMgdXNlZCB0byBzZWxlY3QgYmV0d2VlbiBhbHRlcm5hdGl2ZSBkYXRhcGF0aHMgDQogICAgYmFz ZWQgb24gdGhlIHZhbHVlIG9mIHNvbWUgbWV0YWRhdGEgaXRlbS4gIFRoZSBSZWRpcmVjdG9yIExG QiANCiAgICBhY2NlcHRzIGFuIGlucHV0IHBhY2tldCBQLCBhbmQgdXNlcyBhc3NvY2lhdGVkIG1l dGFkYXRhIGl0ZW0gTSB0byANCiAgICBkZW11bHRpcGxleCB0aGF0IHBhY2tldCBvbnRvIG9uZSBv ZiBOIG91dHB1dHM7IGUuZy4sIHVuaWNhc3QgDQogICAgZm9yd2FyZGluZywgbXVsdGljYXN0LCBv ciBicm9hZGNhc3QuICBDb25maWd1cmFibGUgYXR0cmlidXRlcyANCiAgICBpbmNsdWRlOiANCiAg ICAgICAuIG51bWJlciBvZiBMRkIgb3V0cHV0IHBvcnRzIChOKSANCiAgICAgICAuIG1ldGFkYXRh IGl0ZW0gdG8gZGVtdWx0aXBsZXggb24gKE0pIA0KICAgICAgIC4gbWFwcGluZyBvZiBtZXRhZGF0 YSB2YWx1ZSB0byBvdXRwdXQgcG9ydCANCiAgICAgICAuIGRlZmF1bHQgb3V0cHV0IHBvcnQgKGZv ciB1bi1tYXRjaGVkIGlucHV0IG1ldGFkYXRhIHZhbHVlcykuIA0KICAgICAgICAgIA0KICAgIE5v dGUgdGhhdCBvdGhlciBMRkJzIG1heSBpbmNsdWRlIGRlbXVsdGlwbGV4aW5nIGZ1bmN0aW9uYWxp dHkgDQogICAgKGkuZS4sIGlmIHRoZXkgaGF2ZSBtdWx0aXBsZSBvdXRwdXRzIGluIGFuIG91dHB1 dCBncm91cCkuICBUaGUgDQogICAgUmVkaXJlY3RvciBMRkIgaXMgZXNwZWNpYWxseSB1c2VmdWwg Zm9yIGRlbXVsdGlwbGV4aW5nIGJhc2VkIG9uIA0KICAgIG1ldGFkYXRhIGl0ZW1zIHRoYXQgYXJl IG5vdCBnZW5lcmF0ZWQgb3IgbW9kaWZpZWQgYnkgYW4gaW1tZWRpYXRlIA0KICAgIHVwc3RyZWFt IExGQi4gDQogICAgIA0KIDEuOC4gUGFja2V0IEhlYWRlciBSZXdyaXRlciBMRkIgDQogICAgICAg ICAgDQogICAgVGhlIFBhY2tldCBIZWFkZXIgUmV3cml0ZXIgTEZCIGlzIHVzZWQgdG8gcmUtd3Jp dGUgZmllbGRzIGluIGEgDQogICAgcGFja2V0J3MgaGVhZGVyLiAgRnVuY3Rpb24tc3BlY2lmaWMg c3ViLWNsYXNzZXMgb2YgdGhlIFBhY2tldCANCiAgICBIZWFkZXIgUmV3cml0ZXIgTEZCIG1heSBi ZSBzcGVjaWZpZWQgYXMgc3ViLWNsYXNzZXMgb2YgdGhlIE1vZGlmaWVyIA0KICAgIExGQi4gIFRo ZXNlIG1heSBpbmNsdWRlOiANCiAgICAgICAuIElQdjQgVFRML0lQdjYgSG9wIENvdW50IA0KICAg ICAgIC4gSVB2NCBoZWFkZXIgY2hlY2tzdW0gDQogICAgICAgLiBEU0NQIA0KICAgICAgIC4gSVB2 NCBOQVQgDQogICAgIA0KICAgIFRoZSBwcmVjaXNlIG1lYW5zIGJ5IHdoaWNoIHRoZSBwYWNrZXQg aGVhZGVyIHJld3JpdGluZyBmdW5jdGlvbnMgDQogICAgd2lsbCBiZSBzcGVjaWZpZWQgaXMgVEJE LiANCiAgICAgDQogMS45LiBDb3VudGVyIExGQiAgDQogICAgICAgICAgDQogICAgVGhlIENvdW50 ZXIgTEZCIGlzIHVzZWQgdG8gbWFpbnRhaW4gcGFja2V0IGFuZC9vciBieXRlIHN0YXRpc3RpY3Mg DQogICAgb24gdGhlIHBhY2tldCBmbG93IHRocm91Z2ggdGhlIExGQi4gIFBhY2tldHMgYXJlIHBy b3ZpZGVkIHRvIHRoZSANCiAgICBDb3VudGVyIExGQiBvbiBhbiBMRkIgaW5wdXQgYWxvbmcgd2l0 aCBwYWNrZXQgbGVuZ3RoIG1ldGFkYXRhIGFuZCANCiAgICBhcmUgYXNzb2NpYXRlZCB3aXRoIGEg Y291bnQgYXR0cmlidXRlIGVpdGhlciBzdGF0aWNhbGx5IChiYXNlZCBvbiANCiAgICB0aGUgTEZC IGlucHV0KSBvciB2aWEgc29tZSBvdGhlciBjb25maWd1cmFibGUgbWV0YWRhdGEgaXRlbS4gIFRo ZSANCiAgICBDb3VudGVyIExGQiBtb2RpZmllcyBuZWl0aGVyIHRoZSBwYWNrZXQgbm9yIGFueSBh c3NvY2lhdGVkIA0KICAgIG1ldGFkYXRhLiANCiAgICAgDQogICAgVGhlIENvdW50ZXIgTEZCIHN1 cHBvcnRzIGEgbnVtYmVyIG9mIHN0YXRpYyBhdHRyaWJ1dGVzLCBpbmNsdWRpbmc6IA0KICAgICAg IC4gc3VwcG9ydGVkIGNvdW50aW5nIG1vZGVzIChlLmcuLCBieXRlLCBwYWNrZXQsIGJvdGgpIA0K ICAgICAgIC4gc3VwcG9ydGVkIGxvZ2dpbmcgbW9kZXMgKGUuZy4sIGxhc3QgcmVjb3JkZWQgcGFj a2V0IHRpbWUpIA0KICAgICAgIC4gbWF4aW11bSBudW1iZXIgb2YgY291bnQgYXR0cmlidXRlcyAN CgwgICAgIA0KICAgIFRoZSBDb3VudGVyIExGQiBzdXBwb3J0cyBhIG51bWJlciBvZiBjb25maWd1 cmFibGUgYXR0cmlidXRlcywgDQogICAgaW5jbHVkaW5nOiANCiAgICAgICAuIG51bWJlciBvZiBM RkIgaW5wdXRzIA0KICAgICAgIC4gbWFwcGluZyBvZiBMRkIgaW5wdXQgdG8gY291bnQgYXR0cmli dXRlICh3aGVuIG1hcHBlZCANCiAgICAgICAgIHN0YXRpY2FsbHkpIA0KICAgICAgIC4gbWV0YWRh dGEgaXRlbSB0byBzZWxlY3QgZm9yIG1hcHBpbmcgdG8gY291bnQgYXR0cmlidXRlIA0KICAgICAg IC4gbWFwcGluZyBvZiBtZXRhZGF0YSB2YWx1ZSB0byBjb3VudCBhdHRyaWJ1dGUgDQogICAgICAg LiBkZWZhdWx0IGNvdW50IGF0dHJpYnV0ZSAod2hlbiBub3QgbWFwcGVkIHN0YXRpY2FsbHkgb3Ig dmlhIA0KICAgICAgICAgY29ycmVjdCANCiAgICAgICAuIG1ldGFkYXRhKSANCiAgICAgICAuIGNv dW50aW5nIG1vZGUgcGVyLWF0dHJpYnV0ZSANCiAgICAgICAuIGxvZ2dpbmcgbW9kZSBwZXItYXR0 cmlidXRlIA0KICAgICANCiAgICBUaGUgQ291bnRlciBMRkIgZG9lcyBub3QgcGVyZm9ybSBhbnkg dGltZS1kZXBlbmRlbnQgY291bnRpbmcuICBUaGUgDQogICAgdGltZSBhdCB3aGljaCBhIGNvdW50 IGlzIG1hZGUgbWF5LCBob3dldmVyLCBiZSBsb2dnZWQgYXMgcGFydCBvZiANCiAgICB0aGUgY291 bnQgYXR0cmlidXRlLiAgDQogICAgIA0KICAgIE90aGVyIExGQnMgbWF5IG1haW50YWluIGludGVy bmFsIHN0YXRpc3RpY3MgKGUuZy4sIGludGVyZmFjZSBMRkJzKS4gDQogICAgVGhlIENvdW50ZXIg TEZCIGlzIGVzcGVjaWFsbHkgdXNlZnVsIHRvIG1haW50YWluIGNvdW50cyBhc3NvY2lhdGVkIA0K ICAgIHdpdGggUW9TIHBvbGljeS4gDQogICAgIA0KIDEuMTAuIERyb3BwZXIgTEZCICANCiAgICAg ICAgICANCiAgICBBIERyb3BwZXIgTEZCIGhhcyBvbmUgaW5wdXQsIGFuZCBubyBvdXRwdXRzLiAg SXQgZGlzY2FyZHMgYWxsIA0KICAgIHBhY2tldHMgdGhhdCBpdCBhY2NlcHRzIHdpdGhvdXQgYW55 IG1vZGlmaWNhdGlvbiBvciBleGFtaW5hdGlvbiBvZiANCiAgICB0aG9zZSBwYWNrZXRzLiAgDQog ICAgICAgICAgDQogICAgVGhlIHB1cnBvc2Ugb2YgYSBEcm9wcGVyIExGQiBpcyB0byBhbGxvdyB0 aGUgZGVzY3JpcHRpb24gb2YgInNpbmtzIiANCiAgICB3aXRoaW4gdGhlIG1vZGVsLCB3aGVyZSB0 aG9zZSBzaW5rcyBkbyBub3QgcmVzdWx0IGluIHRoZSBwYWNrZXQgDQogICAgYmVpbmcgc2VudCBp bnRvIGFueSBvYmplY3QgZXh0ZXJuYWwgdG8gdGhlIG1vZGVsLiAgDQogICAgIA0KICAgIFRoZSBE cm9wcGVyIExGQiBoYXMgbm8gY29uZmlndXJhYmxlIGF0dHJpYnV0ZXMuIA0KICAgICANCiAxLjEx LiBJUHY0IEZyYWdtZW50ZXIgTEZCIA0KICAgICANCiAgICBUaGUgSVB2NCBGcmFnbWVudGVyIExG QiBmcmFnbWVudHMgSVB2NCBwYWNrZXRzIGFjY29yZGluZyB0byB0aGUgTVRVIA0KICAgIG9mIHRo ZSBvdXRnb2luZyBpbnRlcmZhY2UuICBUaGUgSVB2NCBGcmFnbWVudGVyIExGQiBhY2NlcHRzIHBh Y2tldHMgDQogICAgd2l0aCBmcmFtZSBsZW5ndGggYW5kIE1UVSBtZXRhZGF0YSwgYW5kIHByb2R1 Y2VzIGEgc2VxdWVuY2Ugb2Ygb25lIA0KICAgIG9yIG1vcmUgdmFsaWQgSVB2NCBwYWNrZXRzIHBy b3Blcmx5IGZyYWdtZW50ZWQsIGVhY2ggYWxvbmcgd2l0aCANCiAgICBjb3JyZWN0ZWQgZnJhbWUg bGVuZ3RoIG1ldGFkYXRhLiANCiAgICAgDQogICAgVGhlIHNvdXJjZSBvZiB0aGUgb3V0Z29pbmcg aW50ZXJmYWNlIE1UVSBpcyBUQkQuICBUaGUgSVB2NCANCiAgICBmcmFnbWVudGF0aW9uIGZ1bmN0 aW9uIGlzIG5vdCBpbmNvcnBvcmF0ZWQgaW50byB0aGUgSVAgSW50ZXJmYWNlIA0KICAgIExGQiBi ZWNhdXNlIGZvcndhcmRpbmcgaW1wbGVtZW50YXRpb25zIG1heSBpbmNsdWRlIGFkZGl0aW9uYWwg DQogICAgZm9yd2FyZGluZyBmdW5jdGlvbnMgYmV0d2VlbiBmcmFnbWVudGF0aW9uIGFuZCBmaW5h bCBvdXRwdXQgDQogICAgaW50ZXJmYWNlIHByb2Nlc3NpbmcuIA0KICAgICANCiAxLjEyLiBMMiBB ZGRyZXNzIFJlc29sdXRpb24gTEZCIA0KICAgICANCiAgICBUaGUgTDIgQWRkcmVzcyBSZXNvbHV0 aW9uIExGQiBpcyB1c2VkIHRvIG1hcCBhIG5leHQgaG9wIElQIGFkZHJlc3MgDQogICAgaW50byBh biBMMiBhZGRyZXNzLiAgVGhlIExGQiBhY2NlcHRzIHBhY2tldHMgd2l0aCBvdXRwdXQgTDIgDQoM ICAgIGludGVyZmFjZSBhbmQgbmV4dCBob3AgSVAgYWRkcmVzcyBtZXRhZGF0YSwgYW5kIHByb2R1 Y2VzIHRoZSBwYWNrZXQgDQogICAgYWxvbmcgd2l0aCB0aGUgY29ycmVjdCBMMiBkZXN0aW5hdGlv biBhZGRyZXNzLiAgVGhlIEwyIEFkZHJlc3MgDQogICAgUmVzb2x1dGlvbiBMRkIgbWFpbnRhaW5z IG11bHRpcGxlIGFkZHJlc3MgcmVzb2x1dGlvbiB0YWJsZSANCiAgICBhdHRyaWJ1dGVzIGFjY2Vz c2VkIGJ5IHRoZSBvdXRwdXQgTDIgaW50ZXJmYWNlIG1ldGFkYXRhLiAgRWFjaCANCiAgICB0YWJs ZSBhdHRyaWJ1dGUgbWFpbnRhaW5zIGEgc2V0IG9mIGNvbmZpZ3VyYWJsZSBMMiBhZGRyZXNzIA0K ICAgIGF0dHJpYnV0ZXMsIGFjY2Vzc2VkIGJ5IHRoZSBuZXh0IGhvcCBJUCBhZGRyZXNzLiANCiAg ICAgDQogICAgVGhlIEwyIEFkZHJlc3MgUmVzb2x1dGlvbiBMRkIgaGFzIGEgbm9ybWFsIG91dHB1 dCBncm91cCwgd2hpY2ggDQogICAgcHJvZHVjZXMgdGhlIEwyIGRlc3RpbmF0aW9uIGFkZHJlc3Mg bWV0YWRhdGEgYXMgd2VsbCBhcyBhbiANCiAgICBleGNlcHRpb24gb3V0cHV0LiBUaGlzIGV4Y2Vw dGlvbiBvdXRwdXQgY2FuIGJlIHVzZWQgdG8gZGl2ZXJ0IHRoZSANCiAgICBwYWNrZXQgdG8gYW5v dGhlciBMRkIgKGUuZy4sIGFuIEFSUC9ORCBQcm90b2NvbCBMRkIsIG9yIGEgUG9ydCBMRkIgDQog ICAgdXNlZCB0byByZWFjaCB0aGUgQ0UpIGZvciBhZGRyZXNzIHJlc29sdXRpb24uIA0KICAgICAg ICAgIA0KIDEuMTMuIFF1ZXVlIExGQiAgDQogICAgICAgICAgDQogICAgVGhlIFF1ZXVlIExGQiBp cyB1c2VkIHRvIHJlcHJlc2VudCBxdWV1ZWluZyBwb2ludHMgaW4gdGhlIHBhY2tldCANCiAgICBk YXRhcGF0aC4gIEl0IGlzIGFsd2F5cyB1c2VkIGluIGNvbWJpbmF0aW9uIHdpdGggb25lIG9yIG1v cmUgDQogICAgU2NoZWR1bGVyIExGQnMuICBUaGUgUXVldWUgTEZCIG1hbmFnZXMgb25lIG9yIG1v cmUgRklGTyBwYWNrZXQgDQogICAgcXVldWVzIGFzIGNvbmZpZ3VyYWJsZSBhdHRyaWJ1dGVzLiAg VGhlIFF1ZXVlIExGQiBwcm92aWRlcyBvbmUgb3IgDQogICAgbW9yZSBMRkIgaW5wdXRzLCBhbmQg cGFja2V0cyBhcmUgbWFwcGVkIGZyb20gTEZCIGlucHV0cyB0byBxdWV1ZXMsIA0KICAgIGVpdGhl ciBzdGF0aWNhbGx5LCBvciB2aWEgcXVldWUgbWV0YWRhdGEuICBFYWNoIHF1ZXVlIGF0dHJpYnV0 ZSBpcyANCiAgICBtYXBwZWQgb25lLXRvLW9uZSB3aXRoIGEgc2NoZWR1bGluZyBpbnB1dCBvbiBh IGRvd25zdHJlYW0gU2NoZWR1bGVyIA0KICAgIExGQi4gIFRoZSBRdWV1ZSBMRkIgcHJvdmlkZXMg b25lIG9yIG1vcmUgTEZCIG91dHB1dHMsIGFsb25nIHdpdGggDQogICAgb3B0aW9uYWwgc2NoZWR1 bGluZyBpbnB1dCBtZXRhZGF0YS4gDQogICAgIA0KICAgIEFkZGl0aW9uYWwgcGVyLXF1ZXVlIGNv bmZpZ3VyYWJsZSBhdHRyaWJ1dGVzIGluY2x1ZGUgdGhlIGZvbGxvd2luZzogDQogICAgICAgLiBt YXhpbXVtIGRlcHRoIGRpc2NhcmQgYmVoYXZpb3IgKHRhaWwgZHJvcC9oZWFkIGRyb3AvQWN0aXZl IA0KICAgICAgICAgUXVldWUgTWFuYWdlbWVudCAoQVFNKSkgDQogICAgICAgLiBBUU0gcGFyYW1l dGVycyAoc3BlY2lmaWMgdG8gdGhlIEFRTSBhbGdvcml0aG07IGUuZy4sIFJFRCkgDQogICAgICAg LiBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSBlbmFibGUgDQogICAgIA0K ICAgIFBhY2tldHMgYXJlIHByb3ZpZGVkIHRvIHRoZSBRdWV1ZSBMRkIgYWxvbmcgd2l0aCBhIHBh Y2tldCBsZW5ndGggDQogICAgbWV0YWRhdGEgYW5kIGFuIG9wdGlvbmFsIHF1ZXVlIG1ldGFkYXRh LiAgQmVjYXVzZSB0aGUgUXVldWUgTEZCIGNhbiANCiAgICBtb2RlbCBzb3BoaXN0aWNhdGVkIEFR TSBtZWNoYW5pc21zIHN1Y2ggYXMgcGVyLWNvbG9yIG1hcmtpbmcgDQogICAgdGhyZXNob2xkcyAo ZS5nLiwgV2VpZ2h0ZWQgUkVEKSwgcGFja2V0cyBtYXkgYWxzbyBiZSBhY2NvbXBhbmllZCANCiAg ICB3aXRoIGNvbG9yIG1ldGFkYXRhLiANCiAgICAgDQogICAgSWYgRUNOIGlzIGVuYWJsZWQgb24g YSBxdWV1ZSBzZXJ2aW5nIElQIHBhY2tldHMsIHRoZW4gdGhlIElQIHBhY2tldCANCiAgICBoZWFk ZXIgaXMgbW9kaWZpZWQgaWYgY29uZ2VzdGlvbiBpcyBtYXJrZWQuICBBIHByb3RvY29sIHR5cGUg DQogICAgbWV0YWRhdGEgbXVzdCBhY2NvbXBhbnkgdGhlIHBhY2tldCB0byBpbmRpY2F0ZSB0aGUg cGFja2V0IHByb3RvY29sIA0KICAgIChlLmcuLCBJUHY0LCBJUHY2LCBFdGhlcm5ldCksIHNvIHRo YXQgdGhlIGltcGxlbWVudGF0aW9uIGNhbiANCiAgICBkZXRlcm1pbmUgdGhlIGxvY2F0aW9uIG9m IHRoZSBFQ04gYml0cyBpbiB0aGUgaGVhZGVyIFtSRkMzMTY4XS4gIEluIA0KICAgIHRoZSBjYXNl IG9mIElQdjQsIGlmIGNvbmdlc3Rpb24gaXMgc2lnbmFsZWQsIHRoZSBoZWFkZXIgY2hlY2tzdW0g DQogICAgbXVzdCBiZSBtb2RpZmllZC4gIFRoZSBRdWV1ZSBMRkIgc3VwcG9ydHMgYSBjYXBhYmls aXR5IHRvIGluZGljYXRlIA0KICAgIHdoZXRoZXIgaXQgY29ycmVjdHMgdGhlIElQdjQgaGVhZGVy IGNoZWNrc3VtIGFmdGVyIG1hcmtpbmcgDQogICAgY29uZ2VzdGlvbiBleHBlcmllbmNlZC4gIFN1 cHBvcnQgZm9yIHRoZSBjaGVja3N1bSBmaXh1cCBpcyBub3QgDQogICAgbWFuZGF0b3J5IHNpbmNl IHRoZSBjaGVja3N1bSBtYXkgYmUgcmVjYWxjdWxhdGVkIGluIGFub3RoZXIgTEZCIA0KICAgIGZ1 cnRoZXIgZG93bnN0cmVhbS4gDQogICAgIA0KIDEuMTQuIFNjaGVkdWxlciBMRkIgIA0KICAgICAg ICAgIA0KDCAgICBUaGUgU2NoZWR1bGVyIExGQiBpcyB1c2VkIHRvIHBlcmZvcm0gcGFja2V0IHNj aGVkdWxpbmcgYXQgcXVldWVpbmcgDQogICAgcG9pbnRzIGluIHRoZSBwYWNrZXQgZGF0YXBhdGgs IGFuZCBoZW5jZSBpcyBhbHdheXMgdXNlZCBpbiANCiAgICBjb21iaW5hdGlvbiB3aXRoIG9uZSBv ciBtb3JlIHVwc3RyZWFtIFF1ZXVlIG9yIFNjaGVkdWxlciBMRkJzLiAgVGhlIA0KICAgIFNjaGVk dWxlciBMRkIgc3VwcG9ydHMgb25lIG9yIG1vcmUgbG9naWNhbCBzY2hlZHVsaW5nIGlucHV0cy4g IEEgDQogICAgc2NoZWR1bGluZyBpbnB1dCBjYW4gYmUgbWFwcGVkIG9uZS10by1vbmUgdG8gYSBT Y2hlZHVsZXIgTEZCIGlucHV0LCANCiAgICBvciB0aGUgc2NoZWR1bGluZyBpbnB1dCBjYW4gYmUg c2VsZWN0ZWQgdmlhIG1ldGFkYXRhIChhbmQgYm90aCANCiAgICBtZWNoYW5pc21zIG1heSBiZSB1 c2VkIGluIGNvbWJpbmF0aW9uKS4gDQogICAgIA0KICAgIFRoZSBTY2hlZHVsZXIgTEZCIG11bHRp cGxleGVzIGl0cyBzY2hlZHVsaW5nIGlucHV0cyBvbnRvIGEgc2luZ2xlICANCiAgICBMRkIgb3V0 cHV0LCBiYXNlZCBvbiBpdHMgc2NoZWR1bGluZyBhbGdvcml0aG0gYWxvbmcgd2l0aCB0aGUgcGVy LQ0KICAgIGlucHV0IHNjaGVkdWxpbmcgY29uZmlndXJhdGlvbi4gIFRoZSBwYWNrZXQgaXMgbm90 IG1vZGlmaWVkIGR1cmluZyAgDQogICAgdGhlIHNjaGVkdWxpbmcgcHJvY2Vzcy4gDQogICAgIA0K ICAgIFBhY2tldHMgYXJlIHByb3ZpZGVkIHRvIHRoZSBTY2hlZHVsZXIgTEZCIGFsb25nIHdpdGgg YSBwYWNrZXQgDQogICAgbGVuZ3RoIG1ldGFkYXRhIGFuZCBhbiBvcHRpb25hbCBzY2hlZHVsaW5n IGlucHV0IG1ldGFkYXRhLiAgDQogICAgIA0KICAgIENvbmZpZ3VyYWJsZSBhdHRyaWJ1dGVzIGlu Y2x1ZGU6IA0KICAgICAgIC4gbnVtYmVyIG9mIGxvZ2ljYWwgc2NoZWR1bGVyIGlucHV0cyANCiAg ICAgICAuIG51bWJlciBvZiBMRkIgaW5wdXRzIA0KICAgICAgIC4gbWFwcGluZyBvZiBMRkIgaW5w dXQgdG8gc2NoZWR1bGVyIGlucHV0IA0KICAgICAgIC4gc2NoZWR1bGluZyBhbGdvcml0aG0gDQog ICAgICAgLiBwZXItaW5wdXQgc2NoZWR1bGluZyBwYXJhbWV0ZXJzLCBpbmNsdWRpbmc6IA0KICAg ICAgIC4gcHJpb3JpdHkgDQogICAgICAgLiBtaW5pbXVtIHNlcnZpY2UgcmF0ZSANCiAgICAgICAu IG1heGltdW0gc2VydmljZSByYXRlIA0KICAgICAgIC4gYnVyc3QgZHVyYXRpb24gKGF0IG1heGlt dW0gc2VydmljZSByYXRlKSANCiAgICAgDQogICAgSGllcmFyY2hpY2FsIHNjaGVkdWxpbmcgY29u ZmlndXJhdGlvbnMgY2FuIGJlIGNyZWF0ZWQgYnkgY2FzY2FkaW5nIA0KICAgIHR3byBvciBtb3Jl IFNjaGVkdWxlciBMRkJzLiANCiAgICAgICAgICANCiAxLjE1LiBNUExTIElMTS9EZWNhcHN1bGF0 aW9uIExGQiANCiAgICAgDQogICAgVGhlIE1QTFMgSW5jb21pbmcgTGFiZWwgTWFwIChJTE0pL0Rl Y2Fwc3VsYXRpb24gTEZCIGFjY2VwdHMgTVBMUy0NCiAgICBlbmNhcHN1bGF0ZWQgcGFja2V0cywg ZXhhbWluZXMgKGFuZCBwb3NzaWJseSByZW1vdmVzKSB0aGUgdG9wLW1vc3QgDQogICAgbGFiZWws IGFuZCBlbWl0cyB0aGUgcGFja2V0IG9uIG9uZSBvdXRwdXQgd2l0aGluIGFuIG91dHB1dCBncm91 cCwgDQogICAgYWxvbmcgd2l0aCBjb25maWd1cmFibGUgaW5kZXggYW5kIGNsYXNzIG1ldGFkYXRh LiAgVGhlIGNvbmZpZ3VyYWJsZSANCiAgICBtZXRhZGF0YSBjYW4gYmUgdXNlZCBhcyBpbnB1dCBm b3IgYW4gSVAgSW50ZXJmYWNlIExGQiwgYSBOZXh0IEhvcCANCiAgICBMRkIsIG9yIHRoZSBzYW1l IChvciBhbm90aGVyKSBNUExTIElMTS9EZWNhcHN1bGF0aW9uIExGQi4gIFRoaXMgDQogICAgYWxs b3dzIHRoZSBGRSB0byB0ZXJtaW5hdGUsIGZvcndhcmQsIG9yICJwb3AgYW5kIGxvb2t1cCIgb24g dGhlIA0KICAgIHZhbHVlIG9mIHRoZSB0b3AtbW9zdCBsYWJlbC4gIFRoZSBMRkIgbWFpbnRhaW5z IGEgc2V0IG9mIElMTSB0YWJsZSANCiAgICBhdHRyaWJ1dGVzIGluZGV4ZWQgYnkgaW5jb21pbmcg SVAgaW50ZXJmYWNlIG1ldGFkYXRhLiAgRWFjaCBJTE0gDQogICAgdGFibGUgZW50cnkgaXMgYW4g YXR0cmlidXRlIHNwZWNpZnlpbmcgd2hldGhlciB0byByZW1vdmUgdGhlIGxhYmVsLCANCiAgICBh bmQgd2hpY2ggb3V0cHV0IHBvcnQgdG8gZW1pdCB0aGUgcGFja2V0IG9uLiAgQW4gZXhjZXB0aW9u IG91dHB1dCANCiAgICBpcyBwcm92aWRlZCBmb3IgcGFja2V0cyB3aXRoIGV4cGlyZWQgVFRMLiAN CiAgICAgDQogMS4xNi4gTVBMUyBFbmNhcHN1bGF0aW9uIExGQiANCiAgICAgDQogICAgVGhlIE1Q TFMgRW5jYXBzdWxhdGlvbiBMRkIgYWNjZXB0cyBJUCBvciBNUExTLWVuY2Fwc3VsYXRlZCBwYWNr ZXRzIA0KICAgIGFuZCBhcHBlbmRzIGFuIE1QTFMgbGFiZWwgc3RhY2ssIHdoaWNoIGlzIHNlbGVj dGVkIGJ5IG91dHB1dCANCiAgICBpbnRlcmZhY2UgYW5kIGNvbmZpZ3VyYWJsZSBpbmRleCBtZXRh ZGF0YS4gIFRoZSBUVEwgb2YgdGhlIGFjY2VwdGVkIA0KICAgIHBhY2tldCBpcyBjb3BpZWQgZnJv bSB0aGUgb3V0ZXJtb3N0IGhlYWRlciBpbnRvIHRoZSBsYWJlbHMgaW4gdGhlIA0KICAgIGxhYmVs IHN0YWNrLCBhbmQgdGhlIFMgYml0IGlzIHNldCBvbiB0aGUgYm90dG9tIGxhYmVsIGlmIHRoZSAN CgwgICAgYWNjZXB0ZWQgcGFja2V0IGlzIElQLiAgVGhlIE1QTFMgRVhQIGJpdHMgYXJlIGNvcGll ZCAob3IgbWFwcGVkKSANCiAgICBhY2NvcmRpbmcgdG8gcGVyLXN0YWNrIGF0dHJpYnV0ZXMuIA0K ICAgICANCiAgICBUaGUgTVBMUyBFbmNhcHN1bGF0aW9uIExGQiBtYWludGFpbnMgbXVsdGlwbGUg c3RhY2sgdGFibGUgDQogICAgYXR0cmlidXRlcyBpbmRleGVkIGJ5IG91dHB1dCBpbnRlcmZhY2Ug bWV0YWRhdGEuICBFbnRyeSBhdHRyaWJ1dGVzIA0KICAgIHdpdGhpbiBhIHRhYmxlIGFyZSBpbmRl eGVkIGJ5IGNvbmZpZ3VyYWJsZSBpbmRleCBtZXRhZGF0YS4gIEVhY2ggDQogICAgZW50cnkgYXR0 cmlidXRlIG1haW50YWlucyBhIGxhYmVsIHN0YWNrLCBhbG9uZyB3aXRoIGEgY29uZmlndXJhYmxl IA0KICAgIGF0dHJpYnV0ZSBmb3IgRVhQIGJpdCBoYW5kbGluZywgYW5kIHBvc3NpYmx5IGNsYXNz IGFuZC9vciBxdWV1ZSANCiAgICBtZXRhZGF0YSB0byBlbWl0IHdpdGggdGhlIHBhY2tldC4gDQog ICAgIA0KICAgIE1QTFMgSUxNL2RlY2Fwc3VsYXRpb24gYW5kIGVuY2Fwc3VsYXRpb24gZnVuY3Rp b25zIGFyZSBtb2RlbGVkIGluIA0KICAgIHNlcGFyYXRlIExGQnMgYmVjYXVzZSBzb21lIGltcGxl bWVudGF0aW9ucyBzcGxpdCB0aGVzZSBvcGVyYXRpb25zIA0KICAgIGFjcm9zcyBGRXMuIA0KICAg ICANCiAxLjE3LiBUdW5uZWwgRW5jYXBzdWxhdGlvbi9EZWNhcHN1bGF0aW9uIExGQiANCiAgICAg IA0KICAgIFRoZSBUdW5uZWwgRW5jYXBzdWxhdGlvbi9EZWNhcHN1bGF0aW9uIExGQiBtb2RlbHMg dHVubmVsIGhlYWRlciANCiAgICBlbmNhcHN1bGF0aW9uIGFuZCBkZWNhcHN1bGF0aW9uL2RlbXVs dGlwbGV4aW5nLiAgVGhlIExGQiBtYWludGFpbnMgDQogICAgc2VwYXJhdGUgZW5jYXBzdWxhdGlv biBhbmQgZGVjYXBzdWxhdGlvbiBpbnB1dCBhbmQgb3V0cHV0IGdyb3Vwcy4gDQogICAgVGhlIGVu Y2Fwc3VsYXRpb24gaW5wdXQgZ3JvdXAgYWNjZXB0cyBwYWNrZXRzIHdpdGggdHVubmVsIG1ldGFk YXRhLCANCiAgICBhcHBlbmRzIGEgdHVubmVsIGhlYWRlciB0aGF0IGlzIHN0b3JlZCBpbiBhIGNv bmZpZ3VyYWJsZSBhdHRyaWJ1dGUgDQogICAgaW5kZXhlZCBieSB0aGUgdHVubmVsIG1ldGFkYXRh LCBhbmQgZW1pdHMgdGhlIHBhY2tldCBvbiBhbiANCiAgICBlbmNhcHN1bGF0aW9uIG91dHB1dC4g IFRoZSBkZWNhcHN1bGF0aW9uIGlucHV0IGdyb3VwIGFjY2VwdHMgDQogICAgcGFja2V0cyBlbmNh cHN1bGF0ZWQgd2l0aCBhIHR1bm5lbCBoZWFkZXIgYWxvbmcgd2l0aCB0dW5uZWwgDQogICAgbWV0 YWRhdGEsIHJlbW92ZXMgdGhlIHR1bm5lbCBoZWFkZXIgKHBlcmZvcm1pbmcgYW55IHR1bm5lbC0N CiAgICBwcm90b2NvbC1zcGVjaWZpYyBjbGFzc2lmaWNhdGlvbikgYWNjb3JkaW5nIHRvIGF0dHJp YnV0ZXMgDQogICAgY29uZmlndXJlZCBvbiBhIHBlci10dW5uZWwgYmFzaXMgYW5kIGFjY2Vzc2Vk IHZpYSB0aGUgdHVubmVsIA0KICAgIG1ldGFkYXRhLCBhbmQgZW1pdHMgdGhlIHBhY2tldCBhbG9u ZyB3aXRoIGNvbmZpZ3VyYWJsZSBtZXRhZGF0YS4gDQogICAgRm9yIGV4YW1wbGUsIHRoZSBjb25m aWd1cmFibGUgbWV0YWRhdGEgdGhhdCBpcyBvdXRwdXQgbWF5IGJlIHVzZWQgDQogICAgYXMgaW5w dXQgaW50ZXJmYWNlIG1ldGFkYXRhIGJ5IGEgZG93bnN0cmVhbSBJUCBvciBMMiBJbnRlcmZhY2Ug TEZCLiAgDQogICAgQSBkZWNhcHN1bGF0aW9uIGV4Y2VwdGlvbiBvdXRwdXQgaXMgYXZhaWxhYmxl IGFuZCBpcyB1c2VkIGluIHRoZSANCiAgICBldmVudCB0aGF0IGRlY2Fwc3VsYXRpb24gZmFpbHMu IA0KICAgICANCiAgICBUaGUgVHVubmVsIEVuY2Fwc3VsYXRpb24vRGVjYXBzdWxhdGlvbiBMRkIg bWF5IGJlIHN1Yi1jbGFzc2VkIGludG8gDQogICAgdHVubmVsLXByb3RvY29sLXNwZWNpZmljIExG QnMsIGluY2x1ZGluZzogDQogICAgICAgLiBJUC1JUCANCiAgICAgICAuIEdSRSANCiAgICAgICAu IEwyVFAgDQogICAgICAgLiBHZW5lcmljIElQdjYgVHVubmVscyANCiAgICAgDQogMS4xOC4gUmVw bGljYXRvciBMRkIgDQogICAgIA0KICAgIFRoZSBSZXBsaWNhdG9yIExGQiBpcyB1c2VkIHRvIHJl cGxpY2F0ZSBhY2NlcHRlZCBwYWNrZXRzIGFuZCBlbWl0IA0KICAgIHRoZW0gb24gb25lIG9yIG1v cmUgb3V0cHV0cyBpbiBhbiBvdXRwdXQgZ3JvdXAuICBQYWNrZXRzIGFyZSANCiAgICBhY2NlcHRl ZCBhbG9uZyB3aXRoIHJlcGxpY2F0b3IgaW5kZXggbWV0YWRhdGEuICBUaGUgTEZCIG1haW50YWlu cyANCiAgICBhbiBhdHRyaWJ1dGUgdGFibGUgaW5kZXhlZCBieSB0aGlzIG1ldGFkYXRhLiAgRWFj aCB0YWJsZSBlbnRyeSANCiAgICBhdHRyaWJ1dGUgc3BlY2lmaWVzIHRoZSBudW1iZXIgb2YgdGlt ZXMgdGhlIHBhY2tldCBtdXN0IGJlIA0KICAgIHJlcGxpY2F0ZWQsIHRoZSBvdXRwdXRzICh3aXRo aW4gdGhlIG91dHB1dCBncm91cCkgdGhhdCBlYWNoIA0KICAgIHJlcGxpY2F0ZWQgcGFja2V0IHNo b3VsZCBiZSBlbWl0dGVkIG9uLCBhbmQgY29uZmlndXJhYmxlIG1ldGFkYXRhIA0KICAgIHRvIGJl IGFzc29jaWF0ZWQgd2l0aCBlYWNoIHJlcGxpY2F0ZWQgcGFja2V0LiANCiAgICAgDQoMICAgIFRo ZSBSZXBsaWNhdG9yIExGQiBjYW4gYmUgdXNlZCBmb3IgbXVsdGljYXN0IHJlcGxpY2F0aW9uLCBv ciBmb3IgDQogICAgdHJhbnNwYXJlbnQgcGFja2V0IGludGVyY2VwdGlvbi4gDQogICAgIA0KICAg ICANCiAgDQoM ------_=_NextPart_001_01C4E1FB.D69BCA1C-- From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 15 06:41: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 GAA22234 for ; Wed, 15 Dec 2004 06:41:26 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeXfK-0002nA-IK for forces-archive@IETF.ORG; Wed, 15 Dec 2004 06:49:59 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00F0F471@cherry.ease.lsoft.com>; Wed, 15 Dec 2004 6:41:27 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49231410 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Dec 2004 06:41:26 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 14 Dec 2004 22:04:06 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121419072869:65888 ; Tue, 14 Dec 2004 19:07:28 -0800 References: <468F3FDA28AA87429AD807992E22D07E039B6B8C@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/14/2004 07:07:29 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/14/2004 07:07:30 PM, Serialize complete at 12/14/2004 07:07:30 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103079843.1078.13.camel@jzny.localdomain> Date: Tue, 14 Dec 2004 22:04:03 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LFB Class text extracted from the ForCES FE Model Draft To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E039B6B8C@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Out of curiosity: What is the charter limit in regards to LFBs? For some reason in my mind i thought we stop at qos/diffserv (+IPV4/6 forwarding and whatever peripheral LFBs such as port/interface). Is this not the case anymore? Wheres the line - I cant seem to find such details in the charter. cheers, jamal On Tue, 2004-12-14 at 11:43, Deleganes, Ellen M wrote: > Here is the LFB Class text extracted from the original ForCES FE Model > Draft to start to build the LFB Class definitions. > > > > Regards, > > Ellen > > From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 15 08:50: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 IAA01128 for ; Wed, 15 Dec 2004 08:50:45 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeZgS-00062K-Nv for forces-archive@IETF.ORG; Wed, 15 Dec 2004 08:59:18 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00F0F716@cherry.ease.lsoft.com>; Wed, 15 Dec 2004 8:50:44 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49247721 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Dec 2004 08:50:36 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 15 Dec 2004 08:39:25 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121505424801:67128 ; Wed, 15 Dec 2004 05:42:48 -0800 References: <468F3FDA28AA87429AD807992E22D07E039B6B8C@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/15/2004 05:42:48 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/15/2004 05:42:49 AM, Serialize complete at 12/15/2004 05:42:49 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103117962.1078.42.camel@jzny.localdomain> Date: Wed, 15 Dec 2004 08:39:22 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LFB Class text extracted from the ForCES FE Model Draft To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E039B6B8C@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit On Tue, 2004-12-14 at 11:43, Deleganes, Ellen M wrote: > Here is the LFB Class text extracted from the original ForCES FE Model > Draft to start to build the LFB Class definitions. I am making certain observations (I suppose i never paid good attention to this text before); So lets start with section 1.3. "IP interface LFB" (more comments later). 1.3 has a statement that this is the repository for interface MIB counters. This is news to me. What i have seen as standard practise is that those counters can exist on a port which has no L3 protocol address at all - pick an ethernet port in a bridge for example, or a PPPOE interface in which both PPP(which would have the attached IPV4 address) and the parent ethernet device have those counters. Is there some RFC (SNMP or otherwise) that defines this? Also is this LFB seen as the mother of LPM? i.e is it the general IPv4/6 forwarding LFB? It seems to do some IP validation - which to me appears to be a cosmetic effort to just make it do some packet processing just because;-> Which brings forward the question: do we need to have LFBs always process packets if they are associated with the data path? The way i would model a port with an IP address attached is to describe it as a port LFB with an attached Protocol address LFB (what you refer to as the IP interface LFB). The Protocol Address LFB is merely a management peripheral LFB and by itself does not process packets; rather it is used by other LFBs in the LFB topology as a reference on how to process a packet (example the IPV4 Forwarding LPM would both at the ingress and egress). cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 15 17:40: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 RAA25280 for ; Wed, 15 Dec 2004 17:40:00 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cehwk-00062H-Dx for forces-archive@IETF.ORG; Wed, 15 Dec 2004 17:48:39 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00F1031C@cherry.ease.lsoft.com>; Wed, 15 Dec 2004 17:39:55 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49321805 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Dec 2004 17:39:53 -0500 Approved-By: david.putzolu@INTEL.COM Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 15 Dec 2004 17:37:21 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBFMbLOd002923 for ; Wed, 15 Dec 2004 22:37:21 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBFMb4Ls016179 for ; Wed, 15 Dec 2004 22:37:21 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 M2004121514372004872 for ; Wed, 15 Dec 2004 14:37:20 -0800 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Dec 2004 14:37:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thread-Topic: Issue Resolution - Issue #1: Feedback, protocol section 6.2 Thread-Index: AcTi9qONVR+JvWrFTeiujG2NU9+dhw== X-OriginalArrivalTime: 15 Dec 2004 22:37:21.0031 (UTC) FILETIME=[A3BFE170:01C4E2F6] X-Scanned-By: MIMEDefang 2.44 Message-ID: Date: Wed, 15 Dec 2004 14:37:20 -0800 Reply-To: "Putzolu, David" Sender: Forwarding and Control Element Separation From: "Putzolu, David" Subject: Issue Resolution - Issue #1: Feedback, protocol section 6.2 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Per the procedural email sent last week (see=20 http://peach.ease.lsoft.com/scripts/wa.exe?A2=3Dind0412&L=3Dforces&T=3D0&= F=3D&S=3D &P=3D1053), I would like to begin working through and closing, if possible, the=20 remaining issues with the protocol draft. The first issue to resolve is #1, which is described at: http://www.mip4.org/issues/tracker/forces/issue1 According to the process email, the first step in resolving=20 this will be determining whether it is a new feature or a=20 change request. My reading of the issue is that it is a change request. Is this correct? If it is a change request, I would ask that WG participants who have been following this topic please weigh in on the need for whether a change is needed or not, including reasoning and proposed resolution. Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 15 18:09: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 SAA28120 for ; Wed, 15 Dec 2004 18:09:43 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CeiPK-0006mp-IF for forces-archive@IETF.ORG; Wed, 15 Dec 2004 18:18:22 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F1042B@cherry.ease.lsoft.com>; Wed, 15 Dec 2004 18:09:30 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49324296 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Dec 2004 18:09:30 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 15 Dec 2004 18:06:38 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8271207 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Dec 2004 18:06:37 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041215175629.02ae5cd0@localhost> Date: Wed, 15 Dec 2004 18:05:43 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 From my reading of this issue, there are two or three different things tied up here. 1) It has been agreed that operations against LFB components are to be nested inside LFB selection TLVs. 2) I am not sure what the Show / Advertise operations are intended to reflect. Those may be Gets, or they may be something else that requires elucidation. 3) There is an ongoing debate about whether FE/CE level interactions such as heartbeat should be addressed to LFBs or to the CE /FE. There is an elegant consistency in protocol structure if they are addressed to LFBs, but there is a lack of generality as well in that it appears to require special operaions within the LFB targetting. This discussion is ongoing. it is also possible that there are aspects Jamal intended for this issue. Yours, Joel M. Halpern At 05:37 PM 12/15/2004, Putzolu, David wrote: >Per the procedural email sent last week (see >http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0412&L=forces&T=0&F=&S= >&P=1053), >I would like to begin working through and closing, if possible, the >remaining issues with the protocol draft. > >The first issue to resolve is #1, which is described at: >http://www.mip4.org/issues/tracker/forces/issue1 > >According to the process email, the first step in resolving >this will be determining whether it is a new feature or a >change request. > >My reading of the issue is that it is a change request. Is this >correct? > >If it is a change request, I would ask that WG participants who >have been following this topic please weigh in on the need for >whether a change is needed or not, including reasoning and proposed >resolution. > >Thanks, >David From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 15 19:13: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 TAA03705 for ; Wed, 15 Dec 2004 19:13:41 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CejPQ-00089U-MV for forces-archive@IETF.ORG; Wed, 15 Dec 2004 19:22:21 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F10381@cherry.ease.lsoft.com>; Wed, 15 Dec 2004 19:13:43 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49330865 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Dec 2004 19:13:39 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 15 Dec 2004 19:12:56 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBG0CGSg029118; Thu, 16 Dec 2004 00:12:16 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBG0C8Yd004078; Thu, 16 Dec 2004 00:12:16 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 M2004121516121612730 ; Wed, 15 Dec 2004 16:12:16 -0800 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, 15 Dec 2004 16:12:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] [issue1] Feedback: Section 6.2 Thread-Index: AcTAMfgx9RhOMdtEScyz9k9Gjd4wjwiy7maw X-OriginalArrivalTime: 16 Dec 2004 00:12:15.0749 (UTC) FILETIME=[E610E350:01C4E303] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03A2CA73@orsmsx408> Date: Wed, 15 Dec 2004 16:12:14 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue1] Feedback: Section 6.2 Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable On issue 1, its mostly editorial changes in my opinion. See some of my comments below.. -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim More: 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. [Yes, we could have LFBInstance =3D 0x1 in the figure] + 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.=20 [Sounds good...will you send a note to Avri to change Message Type to Message command in main header ?] + comment on SHOW applies here as well [will do] + "HBI will be exchanged with the CE using this LFB" ???=20 [yes, HBI is part of the FE object LFB] + Length should specify what length is covered by the TLV. -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" ??? [HBI is part of the LFB] + Type =3D T.reason ? [It would be good if this could be part of the = LFB operation as well..let me know your thoughts?] This brings up that we need the following speacial TLVs. FORCES_REASON, FORCES_RESULT, FORCES_NAME. [HK] I think we should try to avoid this. If we can convey the same info using FE object LFBs then that approach should be used...I am sure you will agree. Thus no changes to the protocol grammar are needed. The Result can be conveyed as part of the Operation TLV inside LFB TLV as in the case of Config messages. Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 15 19:20: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 TAA04206 for ; Wed, 15 Dec 2004 19:20:44 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CejWG-0008Jf-24 for forces-archive@IETF.ORG; Wed, 15 Dec 2004 19:29:24 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00F1045A@cherry.ease.lsoft.com>; Wed, 15 Dec 2004 19:20:46 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49331335 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Dec 2004 19:20:46 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 15 Dec 2004 19:20:23 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBG0Jjwh024671; Thu, 16 Dec 2004 00:19:45 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBG0JiLc030738; Thu, 16 Dec 2004 00:19:44 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 M2004121516194426592 ; Wed, 15 Dec 2004 16:19:44 -0800 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, 15 Dec 2004 16:19:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] [issue2] feedback on section 6.3 Thread-Index: AcTAMgGqxD4NIwM7R0KBhFUGBQiIJAi0gNKQ X-OriginalArrivalTime: 16 Dec 2004 00:19:24.0215 (UTC) FILETIME=[E5739C70:01C4E304] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03A2CA9B@orsmsx408> Date: Wed, 15 Dec 2004 16:19:21 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue2] feedback on section 6.3 Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Issue 2 is also editorial changes...pls see my comments below, -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim - 6.3.1 Config Message + "Config data" should be "Config data and path" [will do] + Type is bad to describe operations. That should be operations [Type=3DOperations, since it's a nested TLV] + UPDATE/REPLACE, DEL ALL are really flag extensions which will become clear once we have path-data noise cleared. Suggest you remove.=20 [these are basic operations that we agreed on, not sure how path-data affects them...but we can remove at later point if they are not needed] + What is PACKET SUBSCRIBE/UNSUBSCRIBE? [this will be removed] - 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? [yes] + 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.=20 [ok, will make this change] regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 15 19:54: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 TAA06299 for ; Wed, 15 Dec 2004 19:54:19 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cek2i-0000Zn-VV for forces-archive@IETF.ORG; Wed, 15 Dec 2004 20:02:58 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00F10729@cherry.ease.lsoft.com>; Wed, 15 Dec 2004 19:54:19 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49333548 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Dec 2004 19:54:15 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 15 Dec 2004 19:36:44 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBG0a9Od021878; Thu, 16 Dec 2004 00:36:09 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBG0ZLMa009481; Thu, 16 Dec 2004 00:36:08 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 M2004121516360629667 ; Wed, 15 Dec 2004 16:36:06 -0800 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, 15 Dec 2004 16:36:05 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] [issue3] feedback section 6.4 Thread-Index: AcTAMgi5Ja2GDdPwTJ+7IAVSIiG7Igi07CLA X-OriginalArrivalTime: 16 Dec 2004 00:36:05.0809 (UTC) FILETIME=[3A72BA10:01C4E307] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03A2CAFD@orsmsx408> Date: Wed, 15 Dec 2004 16:36:04 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue3] feedback section 6.4 Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable My comments on this one below...=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim "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? [Agreed] - 6.4.1 Query Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D GET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path(or Attribute ID?) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query Data | . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should really be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D GET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path to queried data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Yes, in general...except in case of content/key based quering...in that case you need some additional data...may be its part of the path, not sure about that ?] - 6.4.2 Query Response Message I think the deviation from the norm in laying out the response will make it more programming work.=20 Looking at main header one should be able to tell how to parse the=20 contents and what they mean. [I don't think there is any deviation here, its just needs to be written in a consistent fashion...Weiming what do you think? This is just editorial change I think] Regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 15 20:04: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 UAA07066 for ; Wed, 15 Dec 2004 20:04:27 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CekCX-0000rV-PB for forces-archive@IETF.ORG; Wed, 15 Dec 2004 20:13:06 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F10497@cherry.ease.lsoft.com>; Wed, 15 Dec 2004 20:04:28 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49334484 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Dec 2004 20:04:27 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 15 Dec 2004 20:03:16 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBG12hwh010322; Thu, 16 Dec 2004 01:02:43 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBG12fYX011485; Thu, 16 Dec 2004 01:02:41 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 M2004121517014302191 ; Wed, 15 Dec 2004 17:01:46 -0800 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, 15 Dec 2004 17:01:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] [issue5] feedback on section 6.5 Thread-Index: AcTAMhuCGI+fOivdRjC+JAJjZrG5xgi1TRCw X-OriginalArrivalTime: 16 Dec 2004 01:01:30.0937 (UTC) FILETIME=[C77ECA90:01C4E30A] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03A2CB89@orsmsx408> Date: Wed, 15 Dec 2004 17:01:29 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue5] feedback on section 6.5 Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable My comments inline below...=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of 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. [Agreed] - 6.5.1 Event Notification Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type =3D REPORT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path(or Event ID?) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Data | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPER =3D REPORT | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path and Data | . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [I think both these are equivalent, the above one seems more detailed...what would you say is the main difference between these two ?] Regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 15 20:23: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 UAA08542 for ; Wed, 15 Dec 2004 20:23:16 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CekUj-0001Kq-78 for forces-archive@IETF.ORG; Wed, 15 Dec 2004 20:31:55 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F1062F@cherry.ease.lsoft.com>; Wed, 15 Dec 2004 20:23:15 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49335615 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Dec 2004 20:23:15 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 15 Dec 2004 20:22:26 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBG1LoL5012833; Thu, 16 Dec 2004 01:21:50 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBG1LHYv025923; Thu, 16 Dec 2004 01:21:48 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 M2004121517164208184 ; Wed, 15 Dec 2004 17:16:44 -0800 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, 15 Dec 2004 17:16:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] [issue4] feedback on rest of section 6 Thread-Index: AcTAMgppSc2/HdxmRkiQ2cFM1nm6dwi2O2Jg X-OriginalArrivalTime: 16 Dec 2004 01:16:36.0310 (UTC) FILETIME=[E323BF60:01C4E30C] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03A2CBD1@orsmsx408> Date: Wed, 15 Dec 2004 17:16:35 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue4] feedback on rest of section 6 Comments: To: Forces issue tracker To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable My comments inline below....=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim 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. [ok, feel free to start the discussion] 3) Section 6.7 - heartbeat section; seems to be missing some things. Double check please. [looks fine to me. I think you have elaborated on this now [issue7] so I know what you mean, but it wasn't clear from this comment] Regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 15 20:36: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 UAA09702 for ; Wed, 15 Dec 2004 20:36:50 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cekht-0001hA-Gp for forces-archive@IETF.ORG; Wed, 15 Dec 2004 20:45:29 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F10721@cherry.ease.lsoft.com>; Wed, 15 Dec 2004 20:36:51 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49336693 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 15 Dec 2004 20:36:51 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.18 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 15 Dec 2004 20:32:08 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr004.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBG1W7wh021716 for ; Thu, 16 Dec 2004 01:32:07 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBG1VrYh001181 for ; Thu, 16 Dec 2004 01:32:07 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 M2004121517274711383 for ; Wed, 15 Dec 2004 17:27:49 -0800 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, 15 Dec 2004 17:26:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] [issue 7] HB msg Thread-Index: AcTfggnwwYZy4sDEREag6As/aFpIkQDiubYw X-OriginalArrivalTime: 16 Dec 2004 01:26:51.0773 (UTC) FILETIME=[51FBF2D0:01C4E30E] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03A2CBF5@orsmsx408> Date: Wed, 15 Dec 2004 17:26:50 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue 7] HB msg To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > You definitely have a different opinion on this from what we have in the > draft Why would we be discussing it otherwise??? my recollection is _you_ put it in the draft with intent we will revisit and disscuss. I sent the attached document back in October to accelerate the changes to the original draft. Look at section 6.7 - I gave you a clear opportunity to discuss this and didnt impose. Now its in the draft, is the implication that it no longer holds?? Sounds almost like a lawyer sneaking in fine print. [HK] Jamal, lets not get personal here. This issue has been discussed by the protocol team in context with the attached document that you sent out in October. The emails that I forwarded previously (also exchanged in October) were pertaining to that discussion. Based on that email discussion, I was under the impression that this issue is resolved >> go with the old approach for HB msg that we had in the draft. Anyways, you are free to revisit issues...hopefully we will eventually reach some resolution :) There hasn't been much response yet, expect from Joel. Regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Thu Dec 16 07:42: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 HAA18600 for ; Thu, 16 Dec 2004 07:42:01 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cev5g-00083i-Ez for forces-archive@IETF.ORG; Thu, 16 Dec 2004 07:50:46 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00F11438@cherry.ease.lsoft.com>; Thu, 16 Dec 2004 7:42:00 -0500 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 49420600 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 16 Dec 2004 07:41:57 -0500 Approved-By: wmwang@MAIL.HZIC.EDU.CN Received: from 202.96.99.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 16 Dec 2004 07:39:07 -0500 Received: from [202.96.99.59] by 202.96.99.56 with StormMail ESMTP id 80694.804536222; Thu, 16 Dec 2004 21:05:04 +0800 (CST) Received: from WWM (unverified [202.96.99.60]) by mail.gsu.cn (Rockliffe SMTPRA 6.0.11) with ESMTP id for ; Thu, 16 Dec 2004 20:38:55 +0800 References: 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 Message-ID: <03bf01c4e36b$c564a610$845c21d2@Necom.hzic.edu.cn> Date: Thu, 16 Dec 2004 20:35:48 +0800 Reply-To: "Wang,Weiming" Sender: Forwarding and Control Element Separation From: "Wang,Weiming" Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 I just have a general comment triggered by this issue: 1. I see the LFBclass ID and InstanceID in the Association Setup/Teardown messages really redundant here. We know we do this is try to keep the consistency of LFB targeted message format, but my view is it seems not so valuable to sacrifice to keep this consistency. The same question is actually firstly from the Heartbeat message. I remembered we had a long discussion on the necessity for a specific HB message. The conclusion reached was we needed it because we then can take a specific very bit-saved format for it ( only with the message header for the message). Now, if we low down the HB as a general LFB targeted message format, we actually don't need the message anymore. It just plays the role of no more than one general event message. 2. Taking the thought that we don't try to keep the LFB target structure, I think the Association Setup/Teardown messages can be simplified much. Note that some of the parameters related to the Setup can be accessed by CE later based on general LFB targeting(to FE protocol object or FE object) operations after the association is setup, while let the Setup message only do setup. One comment to the suggestion to change 'Message Type' to 'Command' is I am not sure if it also applies to Event message or HB message well. One more thing is it seems we have already be accustomed to call protocol messages as 'Messages' instead of 'Commands'. Thanks, Weiming ----- Original Message ----- From: "Putzolu, David" To: Sent: Thursday, December 16, 2004 6:37 AM Subject: Issue Resolution - Issue #1: Feedback, protocol section 6.2 Per the procedural email sent last week (see http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0412&L=forces&T=0&F=&S= &P=1053), I would like to begin working through and closing, if possible, the remaining issues with the protocol draft. The first issue to resolve is #1, which is described at: http://www.mip4.org/issues/tracker/forces/issue1 According to the process email, the first step in resolving this will be determining whether it is a new feature or a change request. My reading of the issue is that it is a change request. Is this correct? If it is a change request, I would ask that WG participants who have been following this topic please weigh in on the need for whether a change is needed or not, including reasoning and proposed resolution. Thanks, David From owner-forces@PEACH.EASE.LSOFT.COM Thu Dec 16 14:26: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 OAA28449 for ; Thu, 16 Dec 2004 14:26:23 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cf1P4-0004wN-9w for forces-archive@IETF.ORG; Thu, 16 Dec 2004 14:35:11 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00F11D9C@cherry.ease.lsoft.com>; Thu, 16 Dec 2004 14:26:22 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49467833 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 16 Dec 2004 14:26:21 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 16 Dec 2004 14:25:49 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBGJPkSV015937; Thu, 16 Dec 2004 19:25:46 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBGJPL9j018384; Thu, 16 Dec 2004 19:25:46 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 M2004121611254530241 ; Thu, 16 Dec 2004 11:25:45 -0800 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, 16 Dec 2004 11:25:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Issue Resolution - Issue #1: Feedback, protocol section 6.2 Thread-Index: AcTjbKdn2iLG1akfSBq8VanxQn4k9gANr/zA X-OriginalArrivalTime: 16 Dec 2004 19:25:44.0078 (UTC) FILETIME=[0971D2E0:01C4E3A5] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03A2D430@orsmsx408> Date: Thu, 16 Dec 2004 11:25:42 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 Comments: To: "Wang,Weiming" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Weiming, Thanks for the response! Pls see my comments below... -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming 1. I see the LFBclass ID and InstanceID in the Association Setup/Teardown messages really redundant here. We know we do this is try to keep the consistency of LFB targeted message format, but my view is it seems not so valuable to sacrifice to keep this consistency. The same question is actually firstly from the Heartbeat message. I remembered we had a long discussion on the necessity for a specific HB message. The conclusion reached was we needed it because we then can take a specific very bit-saved format for it ( only with the message header for the message).=20 [HK] Yes that is correct, I am glad you recall the discussion :)=20 We didn't combine HB msg with events because we saw it as an exception. 2. Taking the thought that we don't try to keep the LFB target structure, I think the Association Setup/Teardown messages can be simplified much. Note that some of the parameters related to the Setup can be accessed by CE later based on general LFB targeting(to FE protocol object or FE object) operations after the association is setup, while let the Setup message only do setup. [HK] If I understand you correctly, you would like to see an exception for Association Setup/Teardown msgs as well ? Could you draw your proposed protocol messages ? That would make it more clear. I thought Jamal also wanted an exception based on his comments on issue 1 (FORCES_REASON, FORCES_RESULT, FORCES_NAME), but not sure about this. One comment to the suggestion to change 'Message Type' to 'Command' is I am not sure if it also applies to Event message or HB message well. One more thing is it seems we have already be accustomed to call protocol messages as 'Messages' instead of 'Commands'. [HK] I am fine either ways on this..its just a terminology issue. Regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 15: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 PAA29909 for ; Fri, 17 Dec 2004 15:23:08 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfOll-0001tB-Bf for forces-archive@IETF.ORG; Fri, 17 Dec 2004 15:32:10 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00F1388B@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 15:23:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49615446 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 15:23:02 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 15:08:49 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121712121015:80221 ; Fri, 17 Dec 2004 12:12:10 -0800 References: <6.1.2.0.0.20041215175629.02ae5cd0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:12:10 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:12:12 PM, Serialize complete at 12/17/2004 12:12:12 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103314126.1024.88.camel@jzny.localdomain> Date: Fri, 17 Dec 2004 15:08:46 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041215175629.02ae5cd0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit On Wed, 2004-12-15 at 18:05, Joel M. Halpern wrote: > From my reading of this issue, there are two or three different things > tied up here. > > 1) It has been agreed that operations against LFB components are to be > nested inside LFB selection TLVs. > > 2) I am not sure what the Show / Advertise operations are intended to > reflect. Those may be Gets, or they may be something else that requires > elucidation. The Name "advertised" by the FE is infact the attribute "FEName" - to be found in the FEObject LFB instance. The ASSOCIATION message can be viewed being equivalent to a event equivalent to a query response on the FEObject. >From a semantic view, there is a fit for the ASSOCIATION message to transport the FEs name when joining (in a similar fashion it transports or requests to be told what its FEID). It is also ok for the CE to ask it to change its name. We should carry the name somewhere in the path-data. i.e there should be no need to create extra operations like Show/Advertise. i.e it should look like: main hdr (type = ASSOCIATION) | | +--- T = LFBselect | +-- LFBCLASSID = 0x1 | | +-- LFBInstance = 0x1 | +-- T = GET //operation | +-- // path and data to FEName > 3) There is an ongoing debate about whether FE/CE level interactions such > as heartbeat should be addressed to LFBs or to the CE /FE. There is an > elegant consistency in protocol structure if they are addressed to LFBs, > but there is a lack of generality as well in that it appears to require > special operaions within the LFB targetting. This discussion is ongoing. > > it is also possible that there are aspects Jamal intended for this issue. > Elegance and simplicity of coding/parsing are my main drivers. The coding piece: I know because we have implemented both schemes. Elegance, look at the output of the BNF grammar in the case where theres exceptions - It is larger. Bandwidth - i wouldnt even consider it an issue to just add an extra LFB selector. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 15:24: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 PAA00065 for ; Fri, 17 Dec 2004 15:24:07 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfOmi-0001wR-FI for forces-archive@IETF.ORG; Fri, 17 Dec 2004 15:33:08 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F13878@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 15:24:07 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49615532 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 15:24:06 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 15:15:28 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121712185026:80229 ; Fri, 17 Dec 2004 12:18:50 -0800 References: <468F3FDA28AA87429AD807992E22D07E03A2CA73@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:18:50 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:18:51 PM, Serialize complete at 12/17/2004 12:18:51 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103314526.1023.111.camel@jzny.localdomain> Date: Fri, 17 Dec 2004 15:15:26 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [issue1] Feedback: Section 6.2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03A2CA73@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit On Wed, 2004-12-15 at 19:12, Khosravi, Hormuzd M wrote: > On issue 1, its mostly editorial changes in my opinion. > See some of my comments below.. > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > More: > 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. [Yes, we could have LFBInstance = 0x1 in the figure] Should be more readable i believe. How are we keeping track of this? Avri, you awake? > + 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. > [Sounds good...will you send a note to Avri to change Message Type to > Message command in main header ?] > > + comment on SHOW applies here as well [will do] Refer to my comment to Joel on this. We may not need a SHO command just so we can do this. > + "HBI will be exchanged with the CE using this LFB" ??? > [yes, HBI is part of the FE object LFB] You mean FE _protocol_ object? In which case that HBI should go. > + Length should specify what length is covered by the TLV. > > -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" ??? [HBI is part of > the LFB] Refer to comment above - Protocol object is more like it. > + Type = T.reason ? [It would be good if this could be part of the LFB > operation as well..let me know your thoughts?] > > This brings up that we need the following speacial TLVs. > > FORCES_REASON, FORCES_RESULT, FORCES_NAME. > > [HK] I think we should try to avoid this. If we can convey the same info > using FE object LFBs then that approach should be used...I am sure you > will agree. I do. > Thus no changes to the protocol grammar are needed. The > Result can be conveyed as part of the Operation TLV inside LFB TLV as in > the case of Config messages. Ok, agreed. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 15:24: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 PAA00200 for ; Fri, 17 Dec 2004 15:24:57 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfOnX-0001xv-3h for forces-archive@IETF.ORG; Fri, 17 Dec 2004 15:33:59 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00F13893@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 15:24:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49615592 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 15:24:57 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 15:19:46 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121712230835:80237 ; Fri, 17 Dec 2004 12:23:08 -0800 References: <468F3FDA28AA87429AD807992E22D07E03A2CA9B@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:23:08 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:23:09 PM, Serialize complete at 12/17/2004 12:23:09 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103314784.1025.125.camel@jzny.localdomain> Date: Fri, 17 Dec 2004 15:19:45 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [issue2] feedback on section 6.3 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03A2CA9B@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit On Wed, 2004-12-15 at 19:19, Khosravi, Hormuzd M wrote: > Issue 2 is also editorial changes...pls see my comments below, > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > - 6.3.1 Config Message > > + "Config data" should be "Config data and path" [will do] > > + Type is bad to describe operations. That should be operations > [Type=Operations, since it's a nested TLV] I think more readable to say operation = XXXX > > + 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 that we agreed on, not sure how path-data > affects them...but we can remove at later point if they are not needed] > > + What is PACKET SUBSCRIBE/UNSUBSCRIBE? [this will be removed] > > - 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? [yes] > > + 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. > [ok, will make this change] ok. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 15:31: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 PAA00850 for ; Fri, 17 Dec 2004 15:31:49 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfOuA-00028y-51 for forces-archive@IETF.ORG; Fri, 17 Dec 2004 15:40:51 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00F13A69@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 15:31:49 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49617201 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 15:31:48 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 15:22:06 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121712252721:80241 ; Fri, 17 Dec 2004 12:25:27 -0800 References: <468F3FDA28AA87429AD807992E22D07E03A2CAFD@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:25:27 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:25:29 PM, Serialize complete at 12/17/2004 12:25:29 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103314923.1023.133.camel@jzny.localdomain> Date: Fri, 17 Dec 2004 15:22:03 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [issue3] feedback section 6.4 Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03A2CAFD@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit On Wed, 2004-12-15 at 19:36, Khosravi, Hormuzd M wrote: > - 6.4.1 Query Message > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = GET | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path(or Attribute ID?) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Query Data | > . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Should really be: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = GET | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path to queried data | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > [Yes, in general...except in case of content/key based quering...in that > case you need some additional data...may be its part of the path, not > sure about that ?] "Path to queried data" should cover all sorts of querying schemes (including content based). Actually, instead of Type = GET i think it should read Operation = GET Or maybe even Operation/Type = GET. This applies to all sections in 6.2.x > - 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. > > [I don't think there is any deviation here, its just needs to be written > in a consistent fashion...Weiming what do you think? This is just > editorial change I think] > Response oughta be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type/Operation = GET | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We should be able to safely assume we are going to resolve how path-data looks like and not have any place holders here. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 15:33: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 PAA01045 for ; Fri, 17 Dec 2004 15:33:45 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfOw3-0002Dw-0u for forces-archive@IETF.ORG; Fri, 17 Dec 2004 15:42:47 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F13A29@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 15:33:45 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49617828 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 15:33:44 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 15:22:13 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121712253450:80243 ; Fri, 17 Dec 2004 12:25:34 -0800 References: <468F3FDA28AA87429AD807992E22D07E03A2CB89@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:25:34 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:25:36 PM, Serialize complete at 12/17/2004 12:25:36 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103314930.1023.135.camel@jzny.localdomain> Date: Fri, 17 Dec 2004 15:22:11 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [issue5] feedback on section 6.5 Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03A2CB89@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit On Wed, 2004-12-15 at 20:01, Khosravi, Hormuzd M wrote: BTW, I am hoping Avri is noting this - or we should somehow be sending this to the tracker. > > - 6.5.1 Event Notification Message > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type = REPORT | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path(or Event ID?) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Event Data | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Should be: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPER = REPORT | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Path and Data | > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > [I think both these are equivalent, the above one seems more > detailed...what would you say is the main difference between these two > ?] The second one has path and data without trying to describe how it looks like. Thats still an issue under discussion,. The comment about type/operation=REPORT applies Also, is "REPORT" really needed? We already have the main header saying this is an event. Why wouldnt be the real operation that happened be used here? Example ADD/DEL etc? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 15:33: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 PAA01068 for ; Fri, 17 Dec 2004 15:33:54 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfOwB-0002EF-Rk for forces-archive@IETF.ORG; Fri, 17 Dec 2004 15:42:56 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F13883@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 15:33:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49617858 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 15:33:54 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 15:22:46 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121712260726:80245 ; Fri, 17 Dec 2004 12:26:07 -0800 References: <468F3FDA28AA87429AD807992E22D07E03A2CBD1@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:26:07 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:26:08 PM, Serialize complete at 12/17/2004 12:26:08 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103314963.1024.138.camel@jzny.localdomain> Date: Fri, 17 Dec 2004 15:22:43 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: [issue4] feedback on rest of section 6 Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03A2CBD1@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit On Wed, 2004-12-15 at 20:16, Khosravi, Hormuzd M wrote: > My comments inline below.... > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > 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. [ok, feel free to start the > discussion] Actually this was before the last IETF. We now seem to be in agreement that the LFB schema needs to define what items/atributes are events. So i withdraw that comment - it is now obsoleted. > 3) Section 6.7 - heartbeat section; seems to be missing some things. > Double check please. [looks fine to me. I think you have elaborated on > this now [issue7] so I know what you mean, but it wasn't clear from this > comment] No problem. cheers, jamal > > Regards > Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 15:38: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 PAA01456 for ; Fri, 17 Dec 2004 15:38:03 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfP0D-0002LJ-8N for forces-archive@IETF.ORG; Fri, 17 Dec 2004 15:47:05 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00F139D3@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 15:38:04 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49618264 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 15:38:03 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 15:33:29 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121712365023:80258 ; Fri, 17 Dec 2004 12:36:50 -0800 References: <468F3FDA28AA87429AD807992E22D07E03A2D430@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:36:50 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 12:36:51 PM, Serialize complete at 12/17/2004 12:36:51 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103315606.1024.149.camel@jzny.localdomain> Date: Fri, 17 Dec 2004 15:33:26 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 Comments: To: "Khosravi, Hormuzd M" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03A2D430@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit On Thu, 2004-12-16 at 14:25, Khosravi, Hormuzd M wrote: > Weiming, > > Thanks for the response! Pls see my comments below... > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Wang,Weiming > > 1. I see the LFBclass ID and InstanceID in the Association > Setup/Teardown > messages really redundant here. We know we do this is try to keep the > consistency of LFB targeted message format, but my view is it seems not > so > valuable to sacrifice to keep this consistency. The same question is > actually > firstly from the Heartbeat message. I remembered we had a long > discussion on the > necessity for a specific HB message. The conclusion reached was we > needed it > because we then can take a specific very bit-saved format for it ( only > with the > message header for the message). > [HK] Yes that is correct, I am glad you recall the discussion :) > We didn't combine HB msg with events because we saw it as an exception. > That discussion happened before draft zero went out. The issue with heartbeats was whether there was any other LFB that could receive heartbeats at all - and there didnt seem to be any. The messages lay out has changed _totaly_ since. Before then we had no concept of saying everything goes to an LFB - that view came later after San Diego. > 2. Taking the thought that we don't try to keep the LFB target > structure, I > think the Association Setup/Teardown messages can be simplified much. > Note that > some of the parameters related to the Setup can be accessed by CE later > based on > general LFB targeting(to FE protocol object or FE object) operations > after the > association is setup, while let the Setup message only do setup. > [HK] If I understand you correctly, you would like to see an exception > for Association Setup/Teardown msgs as well ? Could you draw your > proposed protocol messages ? That would make it more clear. I thought > Jamal also wanted an exception based on his comments on issue 1 > (FORCES_REASON, FORCES_RESULT, FORCES_NAME), but not sure about this. The FORCES_REASON, FORCES_RESULT, FORCES_NAME etc seemed valid then - they are obsolete now - so just ignore them. I dont agree that you save anything worthful by leaving out the LFBSelector. You loose in consistency/elegance and you have to write more code. > One comment to the suggestion to change 'Message Type' to 'Command' is I > am not > sure if it also applies to Event message or HB message well. One more > thing is > it seems we have already be accustomed to call protocol messages as > 'Messages' > instead of 'Commands'. > [HK] I am fine either ways on this..its just a terminology issue. > Should apply to Events as well - but i am indifferent as well. cheers, jamal > Regards > Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 16:11: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 QAA07758 for ; Fri, 17 Dec 2004 16:11:04 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfPW6-0004lb-Vq for forces-archive@IETF.ORG; Fri, 17 Dec 2004 16:20:06 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F13AC5@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 16:11:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49620347 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 16:10:47 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 16:10:13 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121713133470:80313 ; Fri, 17 Dec 2004 13:13:34 -0800 Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 01:13:34 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 01:13:36 PM, Serialize complete at 12/17/2004 01:13:36 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103317810.1023.179.camel@jzny.localdomain> Date: Fri, 17 Dec 2004 16:10:10 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: LFB data sharing proposal/suggestion/discussion To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Folks, Steve/Zsolt wrote a draft on this topic - and Steve presented on it; so i wont go justfiying its need[1]. Summary: LFB instances may need to share attributes. A simple example: - A nexthop id in a LPM LFB instance pointing to a NH table entry in the NH LFB instance in the same LFB instance topology. My recommendation is to change the LFB schema a little to allow soft links (like unix file symbolic links thought mentioned in the draft for simplicity sake). As in symbolic links: a) multiple links (from one or more LFB instances) can point to the real data/attribute. b) you need permission to read/write the data; the ACLs we use may have to be modified a little to allow for multi user access control. c) The data is held and owned by one LFB instance. d) The data may be deleted at the owner LFB instance location and leave dangling links. This has repurcasssions: I think you could use bidirectional pointers (such as those used in SNMP port stacking) but the complexity is not worth it IMO. So heres how this works: - "participating" attributes/data are going to be either "shared" or an "alias". **This is the first change needed to the schema**. Example the nhid in a LPM LFB instance pointing to a NH table entry would be marked as aliased and the real data in the NH LFB would be tagged as "shared". An attribute not tagged with either shared/alias is essentially local to the LFB instance (and not "exported/imported"). ACL on the attribute would further refine how shareable it is. The tagging of whether they can be shared or aliased is done at xml definition time. +A shared attribute may need to have some user(reference)count if you want to do it sanely - although i dont think it is necessary since this, like the port stacking approach, would add a lot more complexity. + An alias would have a alias-path constituting a LFBSelector:path combination to where the real shared attribute sits. So for example if a NH entry being refered to is to be found in NH LFB instance 10, path = { 1.2.3.4} then the LPM NHindex alias would refer to: NH:10:{ 1,2,3,4} Essentially it is a pointer to the real data. I left out specifying an FEID because this would be a violation of layering as well as what we are doing/chartered. A speacial section is needed in the LFB template to have these translation tables. **This is the second change needed for LFB schema**. The alias-path is set by the CE at runtime upon policy setup i.e linking together of LFB instances. This detail is implementation specific. Please comment since I need this soon. I would be more than happy to discuss/consider any other sanely implementable schemes. I will also send the schema changes once i get feedback on the idea. cheers, jamal [1] http://www.sstanamera.com/~forces/Old/draft-blake-forces-attrib-00.txt On the 3 issues the draft raises - I only wish to solve the shared attribute challenge. This allows for to reduce the data replication clog by referencing attributes instead of copying them (as well as the good reasons outlined in that draft). Bundling (of LFB instances in a topology) i believe is a policy issue - and the protocol already allows for it if you ask it. Inter-LFB control comes out to me as an implementatio detail. From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 16:34: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 QAA13548 for ; Fri, 17 Dec 2004 16:34:49 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfPso-0006fE-FV for forces-archive@IETF.ORG; Fri, 17 Dec 2004 16:43:52 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00F13B31@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 16:34:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49622095 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 16:34:27 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 16:32:55 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8297738 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 16:32:53 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1103317810.1023.179.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041217162507.03eb0808@localhost> Date: Fri, 17 Dec 2004 16:32:36 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB data sharing proposal/suggestion/discussion To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1103317810.1023.179.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This looks like a good solution. I don't think the problem will come up very often, but it will arise. I think that there is one constraint, and a clarification / implication that needs to be spelled out, and one way to simplify further the notion of what is being referenced: The constraint is that an alias variable still needs a type. And the both the CE and FE are required to ensure that when creating a soft link it points to an instance variable of the right type. (One could go further and have the LFB variable target declared at declaration time, but I think that might be too restrictive in some cases. With that constraint, then we can easily follow paths. When following an LFB select path, if one arrives at an alias variable, and one has not exhausted the path, then one follows the alias. This leaves open the case when the path references the alias variable. Rather than making special case rules about ~if read, follow the alias, if write then replace the alias~ how about just using one of the flags associated with the path. The flag is only meaningful if the path terminates at an alias variable. If unset, the alias is followed. If set, the variable itself (the alias path) is returned. We will need to define a type construct in the XML library for an alias path descriptor. Yours, Joel PS: The "shared" attribute is presumably a hint to the FE that the given variable is likely to be referenced by other things. At 04:10 PM 12/17/2004, Jamal Hadi Salim wrote: >My recommendation is to change the LFB schema a little to allow soft >links (like unix file symbolic links thought mentioned in the draft for >simplicity sake). >As in symbolic links: >a) multiple links (from one or more LFB instances) can point to the real >data/attribute. >b) you need permission to read/write the data; the ACLs we use may have >to be modified a little to allow for multi user access control. >c) The data is held and owned by one LFB instance. >d) The data may be deleted at the owner LFB instance location and leave >dangling links. This has repurcasssions: I think you could use >bidirectional pointers (such as those used in SNMP port stacking) but >the complexity is not worth it IMO. > >So heres how this works: >- "participating" attributes/data are going to be either "shared" or an >"alias". **This is the first change needed to the schema**. > >Example the nhid in a LPM LFB instance pointing to a NH table entry >would be marked as aliased and the real data in the NH LFB would be >tagged as "shared". >An attribute not tagged with either shared/alias is essentially local to >the LFB instance (and not "exported/imported"). >ACL on the attribute would further refine how shareable it is. The >tagging of whether they can be shared or aliased is done at xml >definition time. From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 16:52: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 QAA15856 for ; Fri, 17 Dec 2004 16:52:39 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfQAO-0007SN-12 for forces-archive@IETF.ORG; Fri, 17 Dec 2004 17:01:42 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00F13B9B@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 16:52:38 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49623264 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 16:52:37 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 16:51:56 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBHLptbp003631; Fri, 17 Dec 2004 21:51:55 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBHLps8t017135; Fri, 17 Dec 2004 21:51: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 M2004121713515502236 ; Fri, 17 Dec 2004 13:51:55 -0800 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, 17 Dec 2004 13:51:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Issue resolution text changes Thread-Index: AcTkd7bcTnTg4lCzTU6QDqKN9PvHXwACi4dw X-OriginalArrivalTime: 17 Dec 2004 21:51:48.0326 (UTC) FILETIME=[9BC1B060:01C4E482] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03A6E3A7@orsmsx408> Date: Fri, 17 Dec 2004 13:51:47 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Issue resolution text changes Comments: To: hadi@znyx.com Comments: cc: avri@psg.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Jamal,=20 -----Original Message----- BTW, I am hoping Avri is noting this - or we should somehow be sending this to the tracker. [HK] I will be sending Avri a note for the text changes pertaining to my sections once we resolve the issue on this list. I will copy the entire protocol team, chairs on that email. I think that should be sufficient. Let me know if you have any other suggestions on this ? BTW, seems like we are making good progress on most of the outstanding issues. We should probably have them resolved by next week if we continue at this pace. Thanks Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 17:13: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 RAA18050 for ; Fri, 17 Dec 2004 17:13:23 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfQUS-0008J7-MS for forces-archive@IETF.ORG; Fri, 17 Dec 2004 17:22:26 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F13B56@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 17:13:19 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49626628 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 17:13:16 -0500 Approved-By: avri@PSG.COM Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 17:05:45 -0500 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 iBHLXCep010522; Fri, 17 Dec 2004 22:33:14 +0100 References: <468F3FDA28AA87429AD807992E22D07E03A6E3A7@orsmsx408> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.619) Message-ID: Date: Fri, 17 Dec 2004 17:05:34 -0500 Reply-To: avri@PSG.COM Sender: Forwarding and Control Element Separation From: avri@PSG.COM Subject: Re: Issue resolution text changes Comments: To: "Khosravi, Hormuzd M" Comments: cc: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03A6E3A7@orsmsx408> Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Yes, I am paying attention. Though I would appreciate change notes from people on the sections they contributed. And I think it is good to get resolutions in the tracker so that it there for all to see and there as a record. I will put time in the next few weeks on getting a revised version of the draft out. thanks a. On 17 dec 2004, at 16.51, Khosravi, Hormuzd M wrote: > Jamal, > > -----Original Message----- > BTW, I am hoping Avri is noting this - or we should somehow be sending > this to the tracker. > > [HK] I will be sending Avri a note for the text changes pertaining to > my > sections once we resolve the issue on this list. I will copy the entire > protocol team, chairs on that email. I think that should be sufficient. > Let me know if you have any other suggestions on this ? > > BTW, seems like we are making good progress on most of the outstanding > issues. We should probably have them resolved by next week if we > continue at this pace. > > Thanks > Hormuzd > From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 18:02: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 SAA26157 for ; Fri, 17 Dec 2004 18:02:04 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfRFZ-0002pR-Kq for forces-archive@IETF.ORG; Fri, 17 Dec 2004 18:11:08 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F13C9E@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 18:02:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49631238 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 18:01:51 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 18:00:09 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121715033008:80497 ; Fri, 17 Dec 2004 15:03:30 -0800 References: <1103317810.1023.179.camel@jzny.localdomain> <6.1.2.0.0.20041217162507.03eb0808@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 03:03:30 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 03:03:32 PM, Serialize complete at 12/17/2004 03:03:32 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103324405.1049.36.camel@jzny.localdomain> Date: Fri, 17 Dec 2004 18:00:05 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LFB data sharing proposal/suggestion/discussion To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041217162507.03eb0808@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit On Fri, 2004-12-17 at 16:32, Joel M. Halpern wrote: [..] > The constraint is that an alias variable still needs a type. And the both > the CE and FE are required to ensure that when creating a soft link it > points to an instance variable of the right type. (One could go further > and have the LFB variable target declared at declaration time, but I think > that might be too restrictive in some cases. I cant come up with a scenario where a shared attribute will be of different type relative to alias(es). What do you have in mind? > > With that constraint, then we can easily follow paths. > When following an LFB select path, if one arrives at an alias variable, and > one has not exhausted the path, then one follows the alias. > nod. > This leaves open the case when the path references the alias > variable. You mean path termininating at the variable i think? > Rather than making special case rules about ~if read, follow the > alias, if write then replace the alias~ how about just using one of the > flags associated with the path. The flag is only meaningful if the path > terminates at an alias variable. If unset, the alias is followed. If set, > the variable itself (the alias path) is returned. Sounds reasonable to me. This should probably apply as well to the first (non-terminal) case, no? When you say "replace the alias" you mean the LFBSelect:path or the data value at the remote location (as opposed to at the aliased location)? > We will need to define a type construct in the XML library for an alias > path descriptor. > PS: The "shared" attribute is presumably a hint to the FE that the given > variable is likely to be referenced by other things. Are you thinking that "shared" doesnt need any construct in the xml? Also the other thing is i thought there may be need for is a LFBClassDef "alias transalation table". From what i read above you seem to be suggesting putting the alias path within the attribute - which is also fine if it doesnt complicate things. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 18:03: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 SAA26841 for ; Fri, 17 Dec 2004 18:03:04 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfRGX-00034p-HE for forces-archive@IETF.ORG; Fri, 17 Dec 2004 18:12:06 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00F13E49@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 18:03:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49631396 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 18:03:01 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 18:00:16 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004121715033811:80498 ; Fri, 17 Dec 2004 15:03:38 -0800 References: <468F3FDA28AA87429AD807992E22D07E03A6E3A7@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 03:03:38 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/17/2004 03:03:39 PM, Serialize complete at 12/17/2004 03:03:39 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103324409.1050.38.camel@jzny.localdomain> Date: Fri, 17 Dec 2004 18:00:14 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Issue resolution text changes To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E03A6E3A7@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hormuzd, On Fri, 2004-12-17 at 16:51, Khosravi, Hormuzd M wrote: > BTW, seems like we are making good progress on most of the outstanding > issues. We should probably have them resolved by next week if we > continue at this pace. I think so. Theres one issue i posted on: Subject: Issue: Atomicity, batching and config result message Date: Sat, 11 Dec 2004 11:57:50 -0500 On which i received only a response from Joel. I should open a tracker issue if its not resolved this weekend. More seriously the path-data issue with Joel + Weiming needs resolution. Weiming seems to be busy for us to get a timely resolution and close it. This also needs to go on the database. From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 18:11: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 SAA28253 for ; Fri, 17 Dec 2004 18:11:24 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfROd-0003Um-Gm for forces-archive@IETF.ORG; Fri, 17 Dec 2004 18:20:28 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F13C62@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 18:11:25 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49631859 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 18:11:24 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 18:10:32 -0500 Received: from orsfmr101.jf.intel.com (orsfmr101.jf.intel.com [10.7.209.17]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBHNAVrL017390; Fri, 17 Dec 2004 23:10:31 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr101.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBHNA7EJ016001; Fri, 17 Dec 2004 23:10:31 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 M2004121715103116682 ; Fri, 17 Dec 2004 15:10:31 -0800 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, 17 Dec 2004 15:10:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Issue resolution text changes Thread-Index: AcTkjL9RieXH4xDCS2CifMIlqlD98wAAKdIQ X-OriginalArrivalTime: 17 Dec 2004 23:10:31.0204 (UTC) FILETIME=[9ACFAE40:01C4E48D] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E03AB56C0@orsmsx408> Date: Fri, 17 Dec 2004 15:10:29 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Issue resolution text changes Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Jamal, I plan to respond to these issues over the weekend, or early next week (latest). So hopefully that will help, regards Hormuzd=20 -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Friday, December 17, 2004 3:00 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Issue resolution text changes Hormuzd, On Fri, 2004-12-17 at 16:51, Khosravi, Hormuzd M wrote: > BTW, seems like we are making good progress on most of the outstanding > issues. We should probably have them resolved by next week if we > continue at this pace. I think so. Theres one issue i posted on: Subject:=20 Issue: Atomicity, batching and config result message Date:=20 Sat, 11 Dec 2004 11:57:50 -0500 On which i received only a response from Joel. I should open a tracker issue if its not resolved this weekend. More seriously the path-data issue with Joel + Weiming needs resolution. Weiming seems to be busy for us to get a timely resolution and close it. This also needs to go on the database. From owner-forces@PEACH.EASE.LSOFT.COM Fri Dec 17 20:01: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 UAA12522 for ; Fri, 17 Dec 2004 20:01:16 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfT6l-0008CW-Dt for forces-archive@IETF.ORG; Fri, 17 Dec 2004 20:10:21 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00F140DC@cherry.ease.lsoft.com>; Fri, 17 Dec 2004 20:01:03 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49640234 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 20:01:02 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 17 Dec 2004 19:57:37 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8299198 for FORCES@PEACH.EASE.LSOFT.COM; Fri, 17 Dec 2004 19:57:37 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1103317810.1023.179.camel@jzny.localdomain> <6.1.2.0.0.20041217162507.03eb0808@localhost> <1103324405.1049.36.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041217195130.03f3bdf0@localhost> Date: Fri, 17 Dec 2004 19:56:27 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB data sharing proposal/suggestion/discussion To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1103324405.1049.36.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc We may have different declaration models in our heads. I am imagining that some structure is declared, looking like: struct foo field1: type1 field2: type2 field3: alias tpe3 end This means that when the struct foo is used in some lfb, or in some table in some lfb, that field3 will always be an alias that points to something else. However, the constraint is that whatever field3 points to, it must be of type type3. I think this is an easily met constraint, and result what one might call type-sensible behavior. But since it was not spelled out, I thought I should state it. Then, operationally, when I want to set field3 (i.e. create the alias) I issue a PUT, with the "set alias" flag set, and with the path pointing to the field3 instance I want to set. Normally, I will reference field3 (or fields nested within whatever type field3 has been declared to be) with normal paths with the flag bit not set, in which case the FE controller will follow the alias to find the value to be fetched or replaced. In this model, a shared declaration amounts to saying "this variable can be referenced by aliases, as long has they have a suitable type." While this may a mildly useful hint, I am not sure it is worth it. Yours, Joel At 06:00 PM 12/17/2004, Jamal Hadi Salim wrote: >On Fri, 2004-12-17 at 16:32, Joel M. Halpern wrote: >[..] > > The constraint is that an alias variable still needs a type. And the both > > the CE and FE are required to ensure that when creating a soft link it > > points to an instance variable of the right type. (One could go further > > and have the LFB variable target declared at declaration time, but I think > > that might be too restrictive in some cases. > >I cant come up with a scenario where a shared attribute will be of >different type relative to alias(es). What do you have in mind? > > > > > With that constraint, then we can easily follow paths. > > When following an LFB select path, if one arrives at an alias variable, > and > > one has not exhausted the path, then one follows the alias. > > > >nod. > > > This leaves open the case when the path references the alias > > variable. > >You mean path termininating at the variable i think? > > > Rather than making special case rules about ~if read, follow the > > alias, if write then replace the alias~ how about just using one of the > > flags associated with the path. The flag is only meaningful if the path > > terminates at an alias variable. If unset, the alias is followed. If > set, > > the variable itself (the alias path) is returned. > >Sounds reasonable to me. This should probably apply as well to the first >(non-terminal) case, no? >When you say "replace the alias" you mean the LFBSelect:path or the data >value at the remote location (as opposed to at the aliased location)? > > > We will need to define a type construct in the XML library for an alias > > path descriptor. > > PS: The "shared" attribute is presumably a hint to the FE that the given > > variable is likely to be referenced by other things. > >Are you thinking that "shared" doesnt need any construct in the xml? >Also the other thing is i thought there may be need for is a LFBClassDef >"alias transalation table". From what i read above you seem to be >suggesting putting the alias path within the attribute - which is also >fine if it doesnt complicate things. > >cheers, >jamal From nv33134@yahoo.com Sun Dec 19 06:37: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 GAA25345; Sun, 19 Dec 2004 06:37:23 -0500 (EST) Date: Sun, 19 Dec 2004 06:37:23 -0500 (EST) Message-Id: <200412191137.GAA25345@ietf.org> Received: from [218.12.34.234] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CfzWN-0007eZ-OF; Sun, 19 Dec 2004 06:46:47 -0500 From: "Dr. Plinio" To: PresenteDeNatal@ns.cnri.reston.va.us Subject: Um cordial presente de Natal e Ano Novo X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 MIME-Version: 1.0 Content-Type: text/html X-Spam-Score: 26.9 (++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da c0412pcoMail

Caros amigos,

Lhes enviamos -como um simples, mas cordial presente de Natal e Ano Novo- alguns trechos do artigo "Parai e vede", escrito por Plinio Corrêa de Oliveira. Aqueles que desejarem receber por e-mail, gratuitamente, a íntegra deste artigo, mais o texto do mesmo autor "A ti, caro ateu", simplesmente cliquem em: DrPlinio:DoisTextosGratuitos.

Um feliz Natal e Ano Novo 2005 lhes deseja, atenciosamente,

Ferreira Passos, Atualidade Brasileira / Rio de Janeiro

Parai e vede

Sede espiritual de almas exaustas

Em torno de mim noto uma sede espiritual mal saciada, um desejo mudo e talvez até subconsciente, de reencontrar um pouco da verdadeira alegria do verdadeiro Natal: no olhar de muitos dos conhecidos e desconhecidos com que cruzo pelas ruas, no reflexo dos amigos ao lado dos quais luto e trabalho e dos íntimos cuja amizade me tem acompanhado ao longo dos anos que se vão.

É uma ocasião para lembrar tantas recordações áureas, e aplacar a sede de maravilhoso, de doce, de sacrossanto, de que reluz o Natal.

Por alguns instantes, abramo-nos à luz do Natal, a fim de que se reanimem as nossas almas exaustas e desoladas. Depois, retomaremos com maior coragem o fardo quase insuportável do dia-a-dia.

Luz, paz, alento...

Morreu o Natal autêntico? Com um pouco de exagero, poder-se-ia dizer que sim. Morreu na alma metalizada de tantos milhões de homens. Morreu até em certos presepes. Sim, nos presepes progressistas, que nos exibem a Sagrada Família com os traços e a fisionomia desfigurados pela arte moderna, e até com conotações que induzem à revolução social.

Mas, se há algum exagero em dizer que o Natal morreu, é verdade que alguns lampejos de vida ele ainda conserva. Vamos à procura deles.

Encontrá-lo-emos antes de tudo - e borbulhantes - no próprio fato de ser dia de Natal. Queiram ou não queiram os homens, a graça lhes bate às portas da alma, mais sublime, mais meiga, mais insistente, nestes dias de Natal. Dir-se-ia que, apesar de tudo, paira nos ares uma luz, uma paz, um alento, uma força de idealismo e dedicação, que é difícil não perceber.

Deus, ei-Lo exorável e ao nosso alcance, feito homem como nós, tendo junto de Si a Mãe perfeita. Mãe dEle mas também nossa. Por meio dEla, até os piores pecadores tudo podem pedir e esperar.

As almas crispadas se distendem

Ao contemplar isto, nossas almas crispadas se distendem. Nossos egoísmos se desarmam. A paz penetra em nós e em torno de nós. Sentimos que em nosso vizinho algo também está enobrecido e dulcificado. Florescem os dons de alma. O dom do afeto. O dom do perdão. E, como símbolo, a oferta delicada e desinteressada de algum presente.

Para que nada falte, o irmão corpo - como dizia São Francisco - também tem sua parte na alegria. Feita a oração junto ao presepe, sentam-se todos à mesma mesa.

Alegria de Natal? Sim. Mas muito mais do que isto. Alegria dos 365 dias do ano, para o católico verdadeiro. Pois na alma em que, pela graça, habita o Salvador, esta alegria dura sempre e jamais se apaga. Nem a dor, nem a luta, nem a doença e nem a morte a eliminam. É a alegria da fé e do sobrenatural.

Não há alegria igual

Oh vós que andais pelo caminho, parai e vede se há uma dor semelhante à minha, exclamou Isaías profeta, antevendo a Paixão do Salvador e a compaixão de Maria.

Mas ele também poderia ter dito, profetizando as alegrias cristãs perenes e indestrutíveis que o Natal leva a seu auge: oh vós que passais pelo caminho, parai e vede se há alegria semelhante à minha.

-- Oh vós que viveis para o ouro, oh vós que viveis tolamente para a vanglória, oh vós que viveis torpemente para a sensualidade, oh vós que viveis diabolicamente para a revolta e para o crime: parai e vede as almas verdadeiramente católicas, iluminadas pela alegria do Natal: o que é a vossa alegria comparada à delas?

Não vejais nestas palavras provocação, nem desdém. Elas são muito mais do que isto.

São um convite para o Natal perene, que é a vida do verdadeiro fiel: "Christianus alter Christus" - o cristão é um outro Jesus Cristo.

Não, não há alegria igual. Até mesmo quando o católico está, como Jesus Nosso Senhor, cravado na cruz...

LINKS:

* Para receber o texto completo deste artigo, clique em:

DrPlinio:TextoGratuitoCompleto

* Para receber outros artigos do mesmo autor:

DrPlinio:ProximosArtigos

* Para receber mais informação sobre o autor:

DrPlinioMaisInfo

* Para enviar sua valiosa opinião:

MinhaOpiniao

* Para ser retirado imediatamente de nosso AddressBook:

Retirar

From owner-forces*forces-archive**IETF*-ORG@PEACH.EASE.LSOFT.COM Sun Dec 19 17:58: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 RAA17425 for ; Sun, 19 Dec 2004 17:58:03 -0500 (EST) Received: from grape.ease.lsoft.com ([209.119.1.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgA9D-0005Ye-BZ for forces-archive@IETF.ORG; Sun, 19 Dec 2004 18:07:33 -0500 Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <7.0052AAC5@grape.ease.lsoft.com>; Sun, 19 Dec 2004 17:58:01 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49880308 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 19 Dec 2004 17:58:00 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.16 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 19 Dec 2004 17:53:21 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr002.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBJMrI1j031456; Sun, 19 Dec 2004 22:53:18 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBJMrINf030748; Sun, 19 Dec 2004 22:53: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 M2004121914531704519 ; Sun, 19 Dec 2004 14:53:17 -0800 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, 19 Dec 2004 14:53:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Issue: Atomicity, batching and config result message Thread-Index: AcThHdmJa71LgqhpT3a4XIORF9iFAgE/lk1g X-OriginalArrivalTime: 19 Dec 2004 22:53:18.0278 (UTC) FILETIME=[87F72E60:01C4E61D] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E025792A7@orsmsx408> Date: Sun, 19 Dec 2004 14:52:55 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Issue: Atomicity, batching and config result message Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Jamal, -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim It seems to me the 3 modes can be selected from a global flag level (we need two bits). For default we can have mode 2. Does this sound reasonable? So in summary: Global flags, - 2 for selecting the 3 modes. Global Types/commands: - 2 one for "DONE" and another one for "START" DONE is also =3D=3D UNLOCK, START =3D=3D LOCK used only in 2pc like = setup. [HK] Yes this sounds reasonable to me. I assume by Global flags, you mean Flags in the Main header? Then lets add the appropriate text to that section. Another point would be that atomic transactions (mode 1) can be performed in a single message, just using these flags, without the need for the 2PC commands...this option should also be explicitly mentioned. Finally I have a similar comment as Joel regarding mode 3 (what Joel called mode 4)...I haven't seen any use case of this in my experience. I am fine with having it in, may be just add some text to describe a use case for it? In regards to Config response. It does seem to me to be a source of a lot of noise if i have to send back the full message everytime. I should be able to say "I want this config in all-or-none mode and just send me a NACK with global reason when a failure happens". This has been restricting how we batch in our implementation. [HK] This is already possible.... Flags(32 bits): Identified so far: - ACK indicator(2 bit) The description for using the two bits is: 'NoACK' (00) 'SuccessACK'(01) 'UnsuccessACK'(10)->> You can use this Flag in the main header for that. 'ACKAll' (11) So I would consider this topic as resolved...the appropriate text needs to be supplied to Avri. Regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Sun Dec 19 18:41: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 SAA21014 for ; Sun, 19 Dec 2004 18:41:48 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgApa-0006Sa-Qh for forces-archive@IETF.ORG; Sun, 19 Dec 2004 18:51:19 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00F169DB@cherry.ease.lsoft.com>; 19 Dec 2004 18:41:50 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49882853 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 19 Dec 2004 18:41:49 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.6 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 19 Dec 2004 18:41:28 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) 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 iBJNktZl003594; Sun, 19 Dec 2004 23:46:55 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBJNfRNf014201; Sun, 19 Dec 2004 23:41:27 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 M2004121915412607664 ; Sun, 19 Dec 2004 15:41:26 -0800 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, 19 Dec 2004 15:41:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Issue Resolution - Issue #1: Feedback, protocol section 6.2 Thread-Index: AcTkdjjsO9ZJSfjzTi2aF3PX620vJgBrJoRA X-OriginalArrivalTime: 19 Dec 2004 23:41:26.0996 (UTC) FILETIME=[41C69140:01C4E624] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E025792A8@orsmsx408> Date: Sun, 19 Dec 2004 15:41:10 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Jamal, Pls see my comments below... -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim >=20 > 2) I am not sure what the Show / Advertise operations are intended to > reflect. Those may be Gets, or they may be something else that requires > elucidation. The Name "advertised" by the FE is infact the attribute "FEName" - to be found in the FEObject LFB instance. [HK] I think we have some misunderstanding here, not sure what gave you this impression, but the "advertise" operation is used to advertise the entire FE protocol object to the CE in the Association message, not just the FE Name. The idea is that the CE learns the FE protocol attributes/parameters via this message and can reject an FE based on this information, if it so desires. The ASSOCIATION message can be viewed being equivalent to a event equivalent to a query response on the FEObject.=20 [HK] That's not the case, pls see my previous comments. Let me know how you would like to resolve this? Any suggestions would be welcome. One more thing, you had asked for a special TLV -> FORCES_REASON for the Teardown msg. Since we would both like to avoid this, any suggestions on how this can be accommodated via FE LFBs? May be we remove the Reason completely from the Teardown msg?...let me know your thoughts? Regards Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Sun Dec 19 18:53: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 SAA22588 for ; Sun, 19 Dec 2004 18:53:58 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgB1M-0006zy-QU for forces-archive@IETF.ORG; Sun, 19 Dec 2004 19:03:29 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00F16B46@cherry.ease.lsoft.com>; 19 Dec 2004 18:54:00 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49883613 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 19 Dec 2004 18:53:59 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 19 Dec 2004 18:53:35 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBJNrWsR009527; Sun, 19 Dec 2004 23:53:32 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBJNrTNf017931; Sun, 19 Dec 2004 23:53:31 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 M2004121915532908384 ; Sun, 19 Dec 2004 15:53:29 -0800 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, 19 Dec 2004 15:53:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] [issue6] Summary of Path Thread-Index: AcTQiszQ9L0ZQfMIRmWeSoRkF9B8LwVmd1mg X-OriginalArrivalTime: 19 Dec 2004 23:53:29.0183 (UTC) FILETIME=[F03B8EF0:01C4E625] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E025792AA@orsmsx408> Date: Sun, 19 Dec 2004 15:53:13 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: [issue6] Summary of Path Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Jamal, Joel, Weiming, Firstly, v. sorry about my late response on this issue. I went thru this thread, but it wasn't clear to me what the final summary was or which email I should respond to. I think this is a very important issue so if one of you could summarize this and point out the outstanding aspects, etc., it would make it easy for myself and others to comment on this. Even if you could point me to one of your previous emails that has this, it would be good.=20 Sorry for the trouble, but I would hate to respond with an inaccurate idea about where this issue currently stands. Thanks Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Sun Dec 19 18:59: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 SAA23126 for ; Sun, 19 Dec 2004 18:59:44 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgB6v-00078X-Rd for forces-archive@IETF.ORG; Sun, 19 Dec 2004 19:09:15 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F16A8B@cherry.ease.lsoft.com>; 19 Dec 2004 18:59:42 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49883833 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 19 Dec 2004 18:59:42 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 19 Dec 2004 18:44:05 -0500 Received: from [69.170.11.244] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8321587 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 19 Dec 2004 18:44:04 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E025792A7@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041219183810.039021c0@localhost> Date: Sun, 19 Dec 2004 18:43:09 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Issue: Atomicity, batching and config result message To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E025792A7@orsmsx408> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d This is an area where I have expressed disagreement in the past, and am still quite uncomfortable. In general, it seems to me that every request should receive an application level response. (Notifications over a reliable transport are a different matter.) One can try to construct a case during a multi-request atomic transaction where one would want errors during the transaction, and a success at the end. However, in order to perform 2 phase commit, one needs to actively know that the first phase has completed successfully. The lack of a NACK does not constitute sufficient knowledge. Hence, even in this case I would want individual acks. Thus, I am left confused (as I was before) as to when a CE could usefully set this to anything other than AckAll. Yours, Joel M. Halpern At 05:52 PM 12/19/2004, Khosravi, Hormuzd M wrote: >In regards to Config response. It does seem to me to be a source of a >lot of noise if i have to send back the full message everytime. I should >be able to say "I want this config in all-or-none mode and just send me >a NACK with global reason when a failure happens". This has been >restricting how we batch in our implementation. > >[HK] This is already possible.... >Flags(32 bits): > Identified so far: > - ACK indicator(2 bit) > The description for using the two bits is: > 'NoACK' (00) > 'SuccessACK'(01) > 'UnsuccessACK'(10)->> You can use this Flag in the main header for >that. > 'ACKAll' (11) > >So I would consider this topic as resolved...the appropriate text needs >to be supplied to Avri. From owner-forces@PEACH.EASE.LSOFT.COM Sun Dec 19 21:07: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 VAA01589 for ; Sun, 19 Dec 2004 21:07:33 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgD6e-0001kH-Aa for forces-archive@IETF.ORG; Sun, 19 Dec 2004 21:17:04 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <22.00F16C48@cherry.ease.lsoft.com>; 19 Dec 2004 21:07:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49890356 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 19 Dec 2004 21:07:34 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.17 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 19 Dec 2004 21:07:16 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr003.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBK27FIA032330; Mon, 20 Dec 2004 02:07:15 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBK276Nl003732; Mon, 20 Dec 2004 02:07: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 M2004121918071220143 ; Sun, 19 Dec 2004 18:07:12 -0800 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, 19 Dec 2004 18:07:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Issue: Atomicity, batching and config result message Thread-Index: AcTmJtM9VAzsFE6CQHysw8xqGIkXxAAES/gw X-OriginalArrivalTime: 20 Dec 2004 02:07:13.0173 (UTC) FILETIME=[9EE74450:01C4E638] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E025792AD@orsmsx408> Date: Sun, 19 Dec 2004 18:07:02 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Issue: Atomicity, batching and config result message Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Joel, I agree with your observations, this has been my experience as well. However, the protocol provides this flexibility/options for folks who want to use it. Jamal would probably have some good use cases for this. regards Hormuzd -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Sunday, December 19, 2004 3:43 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: [FORCES] Issue: Atomicity, batching and config result message This is an area where I have expressed disagreement in the past, and am=20 still quite uncomfortable. In general, it seems to me that every request should receive an application=20 level response. (Notifications over a reliable transport are a different=20 matter.) One can try to construct a case during a multi-request atomic transaction=20 where one would want errors during the transaction, and a success at the end. However, in order to perform 2 phase commit, one needs to actively know=20 that the first phase has completed successfully. The lack of a NACK does=20 not constitute sufficient knowledge. Hence, even in this case I would want individual acks. Thus, I am left confused (as I was before) as to when a CE could usefully=20 set this to anything other than AckAll. Yours, Joel M. Halpern At 05:52 PM 12/19/2004, Khosravi, Hormuzd M wrote: >In regards to Config response. It does seem to me to be a source of a >lot of noise if i have to send back the full message everytime. I should >be able to say "I want this config in all-or-none mode and just send me >a NACK with global reason when a failure happens". This has been >restricting how we batch in our implementation. > >[HK] This is already possible.... >Flags(32 bits): > Identified so far: > - ACK indicator(2 bit) > The description for using the two bits is: > 'NoACK' (00) > 'SuccessACK'(01) > 'UnsuccessACK'(10)->> You can use this Flag in the main header for >that. > 'ACKAll' (11) > >So I would consider this topic as resolved...the appropriate text needs >to be supplied to Avri. From owner-forces@PEACH.EASE.LSOFT.COM Sun Dec 19 21:51: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 VAA03970 for ; Sun, 19 Dec 2004 21:51:18 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgDmz-0002ev-7n for forces-archive@IETF.ORG; Sun, 19 Dec 2004 22:00:50 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F16C81@cherry.ease.lsoft.com>; 19 Dec 2004 21:51:15 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 49892539 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 19 Dec 2004 21:51:15 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 19 Dec 2004 21:50:27 -0500 Received: from [69.170.11.244] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8322682 for FORCES@PEACH.EASE.LSOFT.COM; Sun, 19 Dec 2004 21:50:26 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E025792AD@orsmsx408> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041219214850.03a592d8@localhost> Date: Sun, 19 Dec 2004 21:49:47 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Issue: Atomicity, batching and config result message To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E025792AD@orsmsx408> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f One of the things the IETF has learned over the years is that options are generally a bad thing. If there really are clear use cases, I am happy to support them. But unless they can be shown, the flexibility of controllable acks is probably a mistake. Yours, Joel At 09:07 PM 12/19/2004, Khosravi, Hormuzd M wrote: >Joel, > >I agree with your observations, this has been my experience as well. >However, the protocol provides this flexibility/options for folks who >want to use it. Jamal would probably have some good use cases for this. > >regards >Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Mon Dec 20 13:29: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 NAA21330 for ; Mon, 20 Dec 2004 13:29:49 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgSRM-00080Q-V5 for forces-archive@IETF.ORG; Mon, 20 Dec 2004 13:39:30 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00F17C5A@cherry.ease.lsoft.com>; Mon, 20 Dec 2004 13:29:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50001512 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Dec 2004 13:29:47 -0500 Approved-By: avri@PSG.COM Received: from 194.71.127.149 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Dec 2004 13:27:52 -0500 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 iBKHt0ep017239; Mon, 20 Dec 2004 18:55:01 +0100 References: <468F3FDA28AA87429AD807992E22D07E025792AD@orsmsx408> <6.1.2.0.0.20041219214850.03a592d8@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.619) Message-ID: Date: Mon, 20 Dec 2004 13:27:46 -0500 Reply-To: avri@PSG.COM Sender: Forwarding and Control Element Separation From: avri@PSG.COM Subject: Re: Issue: Atomicity, batching and config result message Comments: To: "Joel M. Halpern" To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041219214850.03a592d8@localhost> Precedence: list X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit I thought that the reason for allowing for acks to be suppressed had to do with scaling properties on the numbers of FEs that could be supported. So in those cases where there is a reliable transport then it seems acceptable to not get Ack on things that succeed, though I do believe failures should always be acked. a. On 19 dec 2004, at 21.49, Joel M. Halpern wrote: > One of the things the IETF has learned over the years is that options > are generally a bad thing. > If there really are clear use cases, I am happy to support them. > But unless they can be shown, the flexibility of controllable acks is > probably a mistake. > > Yours, > Joel > > At 09:07 PM 12/19/2004, Khosravi, Hormuzd M wrote: >> Joel, >> >> I agree with your observations, this has been my experience as well. >> However, the protocol provides this flexibility/options for folks who >> want to use it. Jamal would probably have some good use cases for >> this. >> >> regards >> Hormuzd > From owner-forces@PEACH.EASE.LSOFT.COM Mon Dec 20 14:33: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 OAA26640 for ; Mon, 20 Dec 2004 14:33:58 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgTRH-00016w-9b for forces-archive@IETF.ORG; Mon, 20 Dec 2004 14:43:37 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F17E59@cherry.ease.lsoft.com>; Mon, 20 Dec 2004 14:33:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50008313 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Dec 2004 14:33:47 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Dec 2004 14:21:18 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8331333 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Dec 2004 14:21:15 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E025792AD@orsmsx408> <6.1.2.0.0.20041219214850.03a592d8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041220141805.03ad5ba0@localhost> Date: Mon, 20 Dec 2004 14:20:40 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Issue: Atomicity, batching and config result message To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Given that the CE does not know how long the FE may take to process something, how does the CE ever know that it can count on something having been done, so that it make decisions that depend upon that. Should it assume that if more than 1 minute has gone my then no error will be forthcoming? Optimistic behavior is fine for some cases. This does not seem to be one. And, given that one is keeping the TCP connection open, the cost of processing the message is pretty small. Always ack seems a good trade for behavioral and protocol simplicity. Yours, Joel At 01:27 PM 12/20/2004, avri@psg.com wrote: >I thought that the reason for allowing for acks to be suppressed had to do >with scaling properties on the numbers of FEs that could be supported. So >in those cases where there is a reliable transport then it seems >acceptable to not get Ack on things that succeed, though I do believe >failures should always be acked. > >a. > >On 19 dec 2004, at 21.49, Joel M. Halpern wrote: > >>One of the things the IETF has learned over the years is that options are >>generally a bad thing. >>If there really are clear use cases, I am happy to support them. >>But unless they can be shown, the flexibility of controllable acks is >>probably a mistake. >> >>Yours, >>Joel >> >>At 09:07 PM 12/19/2004, Khosravi, Hormuzd M wrote: >>>Joel, >>> >>>I agree with your observations, this has been my experience as well. >>>However, the protocol provides this flexibility/options for folks who >>>want to use it. Jamal would probably have some good use cases for this. >>> >>>regards >>>Hormuzd From owner-forces@PEACH.EASE.LSOFT.COM Mon Dec 20 22:16: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 WAA09964 for ; Mon, 20 Dec 2004 22:16:35 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgafD-0006DM-40 for forces-archive@IETF.ORG; Mon, 20 Dec 2004 22:26:19 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00F18813@cherry.ease.lsoft.com>; Mon, 20 Dec 2004 22:16:33 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50049896 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Dec 2004 22:16:32 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Dec 2004 22:04:23 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122019074112:87617 ; Mon, 20 Dec 2004 19:07:41 -0800 References: <1103317810.1023.179.camel@jzny.localdomain> <6.1.2.0.0.20041217162507.03eb0808@localhost> <1103324405.1049.36.camel@jzny.localdomain> <6.1.2.0.0.20041217195130.03f3bdf0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/20/2004 07:07:41 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/20/2004 07:07:43 PM, Serialize complete at 12/20/2004 07:07:43 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103598258.1049.0.camel@jzny.localdomain> Date: Mon, 20 Dec 2004 22:04:19 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LFB data sharing proposal/suggestion/discussion To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041217195130.03f3bdf0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Joel, I think we are in agreement - the "shared" hint may not be needed. Questions/comments for you: 1) We may need a "depends on" similar to the "provides" so the CE knows if there are dependencies and what to use for aliasing. Eg a LPM LFB depends on NH LFB. 2) Can we have an update to a single alias infact translate to more than one attribute being updated in possibly more than one LFB instance? 3) Are you going to update the LFB schema with the results from this discussion? cheers, jamal On Fri, 2004-12-17 at 19:56, Joel M. Halpern wrote: > We may have different declaration models in our heads. > > I am imagining that some structure is declared, looking like: > struct foo > field1: type1 > field2: type2 > field3: alias tpe3 > end > > This means that when the struct foo is used in some lfb, or in some table > in some lfb, that field3 will always be an alias that points to something > else. However, the constraint is that whatever field3 points to, it must > be of type type3. > I think this is an easily met constraint, and result what one might call > type-sensible behavior. But since it was not spelled out, I thought I > should state it. > > Then, operationally, when I want to set field3 (i.e. create the alias) I > issue a PUT, with the "set alias" flag set, and with the path pointing to > the field3 instance I want to set. > Normally, I will reference field3 (or fields nested within whatever type > field3 has been declared to be) with normal paths with the flag bit not > set, in which case the FE controller will follow the alias to find the > value to be fetched or replaced. > > In this model, a shared declaration amounts to saying "this variable can be > referenced by aliases, as long has they have a suitable type." While this > may a mildly useful hint, I am not sure it is worth it. > > Yours, > Joel > > At 06:00 PM 12/17/2004, Jamal Hadi Salim wrote: > >On Fri, 2004-12-17 at 16:32, Joel M. Halpern wrote: > >[..] > > > The constraint is that an alias variable still needs a type. And the both > > > the CE and FE are required to ensure that when creating a soft link it > > > points to an instance variable of the right type. (One could go further > > > and have the LFB variable target declared at declaration time, but I think > > > that might be too restrictive in some cases. > > > >I cant come up with a scenario where a shared attribute will be of > >different type relative to alias(es). What do you have in mind? > > > > > > > > With that constraint, then we can easily follow paths. > > > When following an LFB select path, if one arrives at an alias variable, > > and > > > one has not exhausted the path, then one follows the alias. > > > > > > >nod. > > > > > This leaves open the case when the path references the alias > > > variable. > > > >You mean path termininating at the variable i think? > > > > > Rather than making special case rules about ~if read, follow the > > > alias, if write then replace the alias~ how about just using one of the > > > flags associated with the path. The flag is only meaningful if the path > > > terminates at an alias variable. If unset, the alias is followed. If > > set, > > > the variable itself (the alias path) is returned. > > > >Sounds reasonable to me. This should probably apply as well to the first > >(non-terminal) case, no? > >When you say "replace the alias" you mean the LFBSelect:path or the data > >value at the remote location (as opposed to at the aliased location)? > > > > > We will need to define a type construct in the XML library for an alias > > > path descriptor. > > > PS: The "shared" attribute is presumably a hint to the FE that the given > > > variable is likely to be referenced by other things. > > > >Are you thinking that "shared" doesnt need any construct in the xml? > >Also the other thing is i thought there may be need for is a LFBClassDef > >"alias transalation table". From what i read above you seem to be > >suggesting putting the alias path within the attribute - which is also > >fine if it doesnt complicate things. > > > >cheers, > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Dec 20 22:23: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 WAA10389 for ; Mon, 20 Dec 2004 22:23:15 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgalf-0006NB-Dy for forces-archive@IETF.ORG; Mon, 20 Dec 2004 22:32:59 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <19.00F1857E@cherry.ease.lsoft.com>; Mon, 20 Dec 2004 22:23:16 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50050325 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Dec 2004 22:23:15 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Dec 2004 22:22:03 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122019250142:87631 ; Mon, 20 Dec 2004 19:25:01 -0800 References: <468F3FDA28AA87429AD807992E22D07E025792AD@orsmsx408> <6.1.2.0.0.20041219214850.03a592d8@localhost> <6.1.2.0.0.20041220141805.03ad5ba0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/20/2004 07:25:02 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/20/2004 07:25:24 PM, Serialize complete at 12/20/2004 07:25:24 PM Content-Type: multipart/mixed; boundary="=-hPGsTVABcxx+lphUTro+" Message-ID: <1103599299.1046.20.camel@jzny.localdomain> Date: Mon, 20 Dec 2004 22:21:39 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Issue: Atomicity, batching and config result message To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041220141805.03ad5ba0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc --=-hPGsTVABcxx+lphUTro+ Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2004-12-20 at 14:20, Joel M. Halpern wrote: > Given that the CE does not know how long the FE may take to process > something, how does the CE ever know that it can count on something having > been done, so that it make decisions that depend upon that. Should it > assume that if more than 1 minute has gone my then no error will be > forthcoming? A unidirectional heartbeat for example doesnt need a response back. A ping needs a full response (with data). A abbreviated ping needs just an ACK back Timers apply to the last two. Essentially: Its per desire/app specifics that counts.. > Optimistic behavior is fine for some cases. This does not seem to be one. > > And, given that one is keeping the TCP connection open, the cost of > processing the message is pretty small. Always ack seems a good trade for > behavioral and protocol simplicity. I think we should leave the doors open slightly for the methods (the protocol execution part) as well[1]. I dont think that the schemes for asking the FE how to execute or report back and format sacrifice the design or make the protocol a christmas tree. I believe that in the end one method may become predominant. So lets have evolution select the surviving modes. Infact survival may become apparent after the first implementations show up. In which case we can kill things before RFC status. As example at the moment we have only implemented the all-or-none execution and full-report formating mostly because they appeared to be the safest ones to do (i.e least controvesial). We may never end up implementing anything else if its not practically needed. I have attached discussion text on this - we can revisit what you have been saying so far or we could move the text into the draft. Hormuzd, I have added your pointing of the different ACK modes (that i somehow missed). Lets get consensus first before we close this issue. At the rate its going I dont think i would need to add it to the database. cheers, jamal [1] The "opaquness" of the methods is not mandating they be used. Just like the data being operated on being unique to LFBs/apps - I think there may be specifics that would work only for certain LFBs but not others. --=-hPGsTVABcxx+lphUTro+ Content-Disposition: attachment; filename=config+response Content-Type: text/plain; name=config+response; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In the master slave-relationship the CE instructs the FE on how to execute operations and how to report back the results. Execution --------- There are 3 execution modes that could be requested for operations spanning on one or more LFB selectors: 1) "all-or-none" Atomic transaction. I believe the SNMP way of life. The FE executes operations till the first one fails. If one fails to execute all fail and any applied ones MUST be undone. A 2pc in which the first phase ensures that resources exist applies could be used. A second scheme may skip the 2pc and proceed towards configuration. This would be implementation specific. The 2pc scheme is expected to support the latter. All messages that are atomically executed will have the global ATOMIC flag on. A 2 phase commit starts with a START flag on its first ATOMIC message and terminates with an empty DONE msg type. Global flags: ATOMIC, START (used by 2PC) New msg type: DONE(used by 2PC) 2) "one of N" independent operations. In which several independent operations are targeted at one or more LFB selectors. Execution continues at the FE when one or more operations fail. This mode is signalled by a missing ATOMIC flag. 3) "go to N" loose transaction In which all operations are executed on FE sequentially until first failure. The rest of the operations are not executed but everything upto failed is not undone unlike #1. flag: GOTON (global) Multipart messages and the relationships to the above: ------------------------------------------------------ a) Multipart flags apply. I.e all messages in a transaction except for the last have a MULTIPART flag on. b) There has to be consistency across the multi parts of the messages. In other words the first message starting with mode #1 above, implies the rest do. Any incosistency implies a cancelled transaction in which all messages are dropped and the sender NACKED. Responses: ---------- The CE expects the FE to report back the execution results when it asks for them. The CE also tells the FE to format them in a certain way. The reporting and its formating are still constrained by the execution requests. These are controlled by the ACK indicators(2 bit) 1) Full response. Essentially what sent is responded to in full with status of whether it failed or succeeded. This is paranoia mode which uses a lot more bandwidth than other modes (allows sender to validate what was sent). 2) Partial: Request for a report with only a success or failure. In other words, depending on the mode - the message could ask only to be told briefly whether the operation succeeded or failed. Great on bandwidth - sensible on reliable TML. 3) errors only Asks to be told only when theres an error that happened. Flags: NACK only Useful when execution success is certain and reliable delivery An example is when you are doing periodic sync updates in which you dont care if a message or two get lost. But you care if the update didnt succeed. 4) Ask for no notification Example unidirectional heartbeat. A more involved heartbeat would occasionally ask for acknowledgement or a full response(a pong to the ping) always. --=-hPGsTVABcxx+lphUTro+-- From owner-forces@PEACH.EASE.LSOFT.COM Mon Dec 20 22:45: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 WAA11544 for ; Mon, 20 Dec 2004 22:45:56 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgb7c-0006oR-S4 for forces-archive@IETF.ORG; Mon, 20 Dec 2004 22:55:41 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00F1871B@cherry.ease.lsoft.com>; Mon, 20 Dec 2004 22:45:56 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50051767 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Dec 2004 22:45:52 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Dec 2004 22:45:09 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122019482788:87649 ; Mon, 20 Dec 2004 19:48:27 -0800 References: <468F3FDA28AA87429AD807992E22D07E025792A8@orsmsx408> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/20/2004 07:48:28 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/20/2004 07:48:29 PM, Serialize complete at 12/20/2004 07:48:29 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103600706.1046.45.camel@jzny.localdomain> Date: Mon, 20 Dec 2004 22:45:06 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <468F3FDA28AA87429AD807992E22D07E025792A8@orsmsx408> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Hormuzd, On Sun, 2004-12-19 at 18:41, Khosravi, Hormuzd M wrote: > Jamal, > > Pls see my comments below... > --Original Message-- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > > > > 2) I am not sure what the Show / Advertise operations are intended to > > reflect. Those may be Gets, or they may be something else that > requires > > elucidation. > > The Name "advertised" by the FE is infact the attribute "FEName" - to be > found in the FEObject LFB instance. > [HK] I think we have some misunderstanding here, not sure what gave you > this impression, > but the "advertise" operation is used to advertise the > entire FE protocol object Did you mean the FE Object LFB? The FEname and FEID are stored in the FEObject. Heres the way i see it: The typical path is a CE setting things in the FE Object LFB. The exceptions are things like the FEID in which the FE on association setup can announce a 0 FEID in the main header as a signal it needs to be assigned one. We also allow for it to provide one to the CE if it knows what it is (example based on a geographical chasis location you could come up with a static ID scheme). The other exception i can think of that the FE would know on bootup is its name (we could probably add vendor specific items in this list as well - eg what model it is etc). So those are the two things that belong to the FE Object that a FE can "advertise" to the CE. Both of which are infact read/write i.e can be overriden in the response (with the CE setting the values by directing them to the FE Object attribute). ** There is a scenario where an FE may actually have a lot more attributes on the FE Object populated. Such is in the case of a situation where an FE is forced to reassociate for example - maybe due to lost communication or a restart of some form. So the summary of what i am saying is the FE OBject LFB is a source as well as sink of the Association msg/response. If there are any attributes already known to the FE then it makes sense to notify the CE of their state (the name being one of them). > to the CE in the Association message, not just > the FE Name. The idea is that the CE learns the FE protocol > attributes/parameters via this message and can reject an FE based on > this information, if it so desires. Again you are refering to the FE Protocol Object above? I think that also may deserve to be in the ASSOCIATION. > The ASSOCIATION message can be viewed being equivalent to a event > equivalent to a query response on the FEObject. > [HK] That's not the case, pls see my previous comments. > Refer to my comments above. > Let me know how you would like to resolve this? Any suggestions would be > welcome. Isnt this discussion the point? If we dont get anywhere i will capture it in the tracking database. > One more thing, you had asked for a special TLV -> FORCES_REASON for the > Teardown msg. Since we would both like to avoid this, any suggestions on > how this can be accommodated via FE LFBs? May be we remove the Reason > completely from the Teardown msg?...let me know your thoughts? This is a hard one. We could send it easily (either direction) if it is an attribute. I think for logging debugging purposes we would need to know the departure reasons. But whose attribute is this? Maybe other people have opinions. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Dec 20 23:07: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 XAA12725 for ; Mon, 20 Dec 2004 23:07:11 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgbSB-0007H8-I1 for forces-archive@IETF.ORG; Mon, 20 Dec 2004 23:16:56 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F18959@cherry.ease.lsoft.com>; Mon, 20 Dec 2004 23:07:12 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50054415 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Dec 2004 23:07:11 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Dec 2004 23:06:26 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122020094492:87663 ; Mon, 20 Dec 2004 20:09:44 -0800 References: <468F3FDA28AA87429AD807992E22D07E039B6B8C@orsmsx408> <1103117962.1078.42.camel@jzny.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/20/2004 08:09:45 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/20/2004 08:09:47 PM, Serialize complete at 12/20/2004 08:09:47 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103601983.1047.68.camel@jzny.localdomain> Date: Mon, 20 Dec 2004 23:06:23 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LFB Class text extracted from the ForCES FE Model Draft To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1103117962.1078.42.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit So answering my own email (after a side discussion with Joel): On Wed, 2004-12-15 at 08:39, Jamal Hadi Salim wrote: > On Tue, 2004-12-14 at 11:43, Deleganes, Ellen M wrote: > > Here is the LFB Class text extracted from the original ForCES FE Model > > Draft to start to build the LFB Class definitions. > > I am making certain observations (I suppose i never paid good attention > to this text before); So lets start with section 1.3. "IP interface LFB" > (more comments later). > > 1.3 has a statement that this is the repository for interface MIB > counters. > This is news to me. What i have seen as standard practise is that > those counters can exist on a port which has no L3 protocol address at > all - pick an ethernet port in a bridge for example, or a PPPOE interface > in which both PPP(which would have the attached IPV4 address) and the > parent ethernet device have those counters. > Is there some RFC (SNMP or otherwise) that defines this? This still needs fixing. The counters apply to Sub-IP Interfaces as well not just to IP interfaces. > Also is this LFB seen as the mother of LPM? i.e is it the general IPv4/6 > forwarding LFB? It seems to do some IP validation - which to me appears > to be a cosmetic effort to just make it do some packet processing > just because;-> Ok, this i can now live with. Should be noted that common practise is to have IP addresses attached on top of intercaes/ports and that IP processing happens on ports which have such addresses further downstream in the LFB topology. The description in the model is better actually. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Dec 20 23:28: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 XAA13749 for ; Mon, 20 Dec 2004 23:28:38 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgbmn-0007fz-Nv for forces-archive@IETF.ORG; Mon, 20 Dec 2004 23:38:24 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00F189B6@cherry.ease.lsoft.com>; Mon, 20 Dec 2004 23:28:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50055322 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Dec 2004 23:28:27 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Dec 2004 23:21:11 -0500 Received: from [69.170.11.244] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8335636 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Dec 2004 23:21:09 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <468F3FDA28AA87429AD807992E22D07E025792AD@orsmsx408> <6.1.2.0.0.20041219214850.03a592d8@localhost> <6.1.2.0.0.20041220141805.03ad5ba0@localhost> <1103599299.1046.20.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041220231307.0390e908@localhost> Date: Mon, 20 Dec 2004 23:20:13 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Issue: Atomicity, batching and config result message To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1103599299.1046.20.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 The heartbeat is an interesting question. Also, this perspective changes the question a bit. What I am looking for is not so much an ack, as a response. I think that we can define the behavior we want, and not get into a set of bits which can be set wrong. There seem to be three cases covered below: 1) A messages, with an effect, that would not otherwise need a response. 2) A message which gets a response 3) A message wherein the delivery of the message is the goal. If an ack is defined as ~a response used when one is not defined for the message~, then the distinction between two and three goes away. The heartbeat is harder. I do note that if there is a response (ack) to the heartbeat, then we get an interesting simplification. Either side choosing to drive the heartbeat (or only one doing so) drives heartbeats for both sides. (This does not fit with the view that a heartbeat is an LFB manipulation, but then I don't take that view.) Yours, Joel At 10:21 PM 12/20/2004, Jamal Hadi Salim wrote: >On Mon, 2004-12-20 at 14:20, Joel M. Halpern wrote: > > Given that the CE does not know how long the FE may take to process > > something, how does the CE ever know that it can count on something having > > been done, so that it make decisions that depend upon that. Should it > > assume that if more than 1 minute has gone my then no error will be > > forthcoming? > >A unidirectional heartbeat for example doesnt need a response back. >A ping needs a full response (with data). >A abbreviated ping needs just an ACK back >Timers apply to the last two. >Essentially: Its per desire/app specifics that counts.. > > > Optimistic behavior is fine for some cases. This does not seem to be one. > > > > And, given that one is keeping the TCP connection open, the cost of > > processing the message is pretty small. Always ack seems a good trade for > > behavioral and protocol simplicity. > >I think we should leave the doors open slightly for the methods (the >protocol execution part) as well[1]. I dont think that the schemes for >asking the FE how to execute or report back and format sacrifice the >design or make the protocol a christmas tree. >I believe that in the end one method may become predominant. So lets >have evolution select the surviving modes. Infact survival may become >apparent after the first implementations show up. In which case we can >kill things before RFC status. As example at the moment we have only >implemented the all-or-none execution and full-report formating mostly >because they appeared to be the safest ones to do (i.e least >controvesial). We may never end up implementing anything else if its not >practically needed. > >I have attached discussion text on this - we can revisit what you have >been saying so far or we could move the text into the draft. > >Hormuzd, I have added your pointing of the different ACK modes (that i >somehow missed). Lets get consensus first before we close this issue. >At the rate its going I dont think i would need to add it to the >database. > >cheers, >jamal > >[1] The "opaquness" of the methods is not mandating they be used. Just like >the data being operated on being unique to LFBs/apps - I think there may be >specifics that would work only for certain LFBs but not others. From owner-forces@PEACH.EASE.LSOFT.COM Mon Dec 20 23:30: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 XAA13883 for ; Mon, 20 Dec 2004 23:30:52 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgbp7-0007in-Vn for forces-archive@IETF.ORG; Mon, 20 Dec 2004 23:40:38 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F18A5D@cherry.ease.lsoft.com>; Mon, 20 Dec 2004 23:30:54 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50055389 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Dec 2004 23:30:52 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 20 Dec 2004 23:28:17 -0500 Received: from [69.170.11.244] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8335678 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 20 Dec 2004 23:28:16 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1103317810.1023.179.camel@jzny.localdomain> <6.1.2.0.0.20041217162507.03eb0808@localhost> <1103324405.1049.36.camel@jzny.localdomain> <6.1.2.0.0.20041217195130.03f3bdf0@localhost> <1103598258.1049.0.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041220232217.03906988@localhost> Date: Mon, 20 Dec 2004 23:27:17 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB data sharing proposal/suggestion/discussion To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1103598258.1049.0.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Given that the CE can read the aliases, I think it gets the "depends on" automatically. The one implication is that we probably need to be clear that the follow aliases bit has no effect on non-alias variables. That way, the CE can fetch a struct which includes aliases, and decide whether it wants the alias values or the target values. Given taht several alias variables can in principle point to the same element in some LFB, I guess it follows that a write to that element through any one path will appear as a change to all the aliased elements. Zsolt and I will get this included in the Schema, if the working group agrees to it. (You, me, Zsolt, and Steve are probably not enough voices on this one.) We are working on some other issues, and we need to resolve the subscripting mechanisms before we can actually produce an update. In this particular case, I think the hard part will be the english description of the semantics. The XML is pretty easy. Even the XML for the type for an alias reference will not be particularly difficult (once we decide about subscripting). The path sequence for exaple will simply be an octet string. Yours, Joel At 10:04 PM 12/20/2004, Jamal Hadi Salim wrote: >Joel, >I think we are in agreement - the "shared" hint may not be needed. >Questions/comments for you: > >1) We may need a "depends on" similar to the "provides" so the CE >knows if there are dependencies and what to use for aliasing. Eg a LPM >LFB depends on NH LFB. >2) Can we have an update to a single alias infact translate to more than >one attribute being updated in possibly more than one LFB instance? >3) Are you going to update the LFB schema with the results from this >discussion? > >cheers, >jamal > >On Fri, 2004-12-17 at 19:56, Joel M. Halpern wrote: > > We may have different declaration models in our heads. > > > > I am imagining that some structure is declared, looking like: > > struct foo > > field1: type1 > > field2: type2 > > field3: alias tpe3 > > end > > > > This means that when the struct foo is used in some lfb, or in some table > > in some lfb, that field3 will always be an alias that points to something > > else. However, the constraint is that whatever field3 points to, it must > > be of type type3. > > I think this is an easily met constraint, and result what one might call > > type-sensible behavior. But since it was not spelled out, I thought I > > should state it. > > > > Then, operationally, when I want to set field3 (i.e. create the alias) I > > issue a PUT, with the "set alias" flag set, and with the path pointing to > > the field3 instance I want to set. > > Normally, I will reference field3 (or fields nested within whatever type > > field3 has been declared to be) with normal paths with the flag bit not > > set, in which case the FE controller will follow the alias to find the > > value to be fetched or replaced. > > > > In this model, a shared declaration amounts to saying "this variable > can be > > referenced by aliases, as long has they have a suitable type." While this > > may a mildly useful hint, I am not sure it is worth it. > > > > Yours, > > Joel > > > > At 06:00 PM 12/17/2004, Jamal Hadi Salim wrote: > > >On Fri, 2004-12-17 at 16:32, Joel M. Halpern wrote: > > >[..] > > > > The constraint is that an alias variable still needs a type. And > the both > > > > the CE and FE are required to ensure that when creating a soft link it > > > > points to an instance variable of the right type. (One could go > further > > > > and have the LFB variable target declared at declaration time, but > I think > > > > that might be too restrictive in some cases. > > > > > >I cant come up with a scenario where a shared attribute will be of > > >different type relative to alias(es). What do you have in mind? > > > > > > > > > > > With that constraint, then we can easily follow paths. > > > > When following an LFB select path, if one arrives at an alias > variable, > > > and > > > > one has not exhausted the path, then one follows the alias. > > > > > > > > > >nod. > > > > > > > This leaves open the case when the path references the alias > > > > variable. > > > > > >You mean path termininating at the variable i think? > > > > > > > Rather than making special case rules about ~if read, follow the > > > > alias, if write then replace the alias~ how about just using one of the > > > > flags associated with the path. The flag is only meaningful if the > path > > > > terminates at an alias variable. If unset, the alias is followed. If > > > set, > > > > the variable itself (the alias path) is returned. > > > > > >Sounds reasonable to me. This should probably apply as well to the first > > >(non-terminal) case, no? > > >When you say "replace the alias" you mean the LFBSelect:path or the data > > >value at the remote location (as opposed to at the aliased location)? > > > > > > > We will need to define a type construct in the XML library for an alias > > > > path descriptor. > > > > PS: The "shared" attribute is presumably a hint to the FE that the > given > > > > variable is likely to be referenced by other things. > > > > > >Are you thinking that "shared" doesnt need any construct in the xml? > > >Also the other thing is i thought there may be need for is a LFBClassDef > > >"alias transalation table". From what i read above you seem to be > > >suggesting putting the alias path within the attribute - which is also > > >fine if it doesnt complicate things. > > > > > >cheers, > > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Dec 21 06:20: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 GAA26588 for ; Tue, 21 Dec 2004 06:20:27 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgiDY-0000Vs-6i for forces-archive@IETF.ORG; Tue, 21 Dec 2004 06:30:16 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F18E3C@cherry.ease.lsoft.com>; Tue, 21 Dec 2004 6:20:28 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50091624 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Dec 2004 06:20:11 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Dec 2004 06:18:15 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122103213184:88290 ; Tue, 21 Dec 2004 03:21:31 -0800 References: <468F3FDA28AA87429AD807992E22D07E025792AD@orsmsx408> <6.1.2.0.0.20041219214850.03a592d8@localhost> <6.1.2.0.0.20041220141805.03ad5ba0@localhost> <1103599299.1046.20.camel@jzny.localdomain> <6.1.2.0.0.20041220231307.0390e908@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/21/2004 03:21:32 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/21/2004 03:21:35 AM, Serialize complete at 12/21/2004 03:21:35 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103627890.1048.144.camel@jzny.localdomain> Date: Tue, 21 Dec 2004 06:18:10 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Issue: Atomicity, batching and config result message To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041220231307.0390e908@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit On Mon, 2004-12-20 at 23:20, Joel M. Halpern wrote: > The heartbeat is an interesting question. The heartbeat was something i could think of right off the bat - it is intended to be motivation that people think differently depending on the application even for something as simple as a heartbeat. One could look at the PL protocol as something of an enabler of multiple apps with slightly varying requirements ..... A variation of the heartbeat for example is: dont ask for a response back except every 10th time where you request for an ACK only (and in addition every 20th time you request for a response throw a die and if the number 6 turns up ask for a full response) etc. I am not sure if i am making my point clear. > Also, this perspective changes the question a bit. > What I am looking for is not so much an ack, as a response. > I think that we can define the behavior we want, and not get into a set of > bits which can be set wrong. > > There seem to be three cases covered below: > 1) A messages, with an effect, that would not otherwise need a response. > 2) A message which gets a response > 3) A message wherein the delivery of the message is the goal. > > If an ack is defined as ~a response used when one is not defined for the > message~, then the distinction between two and three goes away. Both 2 and 3 require reliability at the PL layer. 3 requiring more details. Details may be good in validation but consume more bits on the wire. In a reliable underlying transport, you may need just a short form of the truth a "yes all went fine" instead of a "yes, setting of attribute X on LFB selector Z and deleting entry index 10 of table foot went ok". Note in the text i attached there is one other mode: "errors only" Asks to be told only when theres an error that happened. .. Useful when execution success is certain and reliable delivery. An example is when you are doing periodic sync updates in which you dont care if a message or two get lost. But you care if the update didnt succeed. > The heartbeat is harder. I do note that if there is a response (ack) to > the heartbeat, then we get an interesting simplification. Either side > choosing to drive the heartbeat (or only one doing so) drives heartbeats > for both sides. > (This does not fit with the view that a heartbeat is an LFB manipulation, > but then I don't take that view.) Refer to my motivation above. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Dec 21 06:28: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 GAA27072 for ; Tue, 21 Dec 2004 06:28:08 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgiKz-0000ec-J7 for forces-archive@IETF.ORG; Tue, 21 Dec 2004 06:37:58 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F18EA1@cherry.ease.lsoft.com>; Tue, 21 Dec 2004 6:28:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50099682 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Dec 2004 06:28:08 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Dec 2004 06:27:08 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122103302523:88306 ; Tue, 21 Dec 2004 03:30:25 -0800 References: <1103317810.1023.179.camel@jzny.localdomain> <6.1.2.0.0.20041217162507.03eb0808@localhost> <1103324405.1049.36.camel@jzny.localdomain> <6.1.2.0.0.20041217195130.03f3bdf0@localhost> <1103598258.1049.0.camel@jzny.localdomain> <6.1.2.0.0.20041220232217.03906988@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/21/2004 03:30:26 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/21/2004 03:30:28 AM, Serialize complete at 12/21/2004 03:30:28 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103628424.1046.155.camel@jzny.localdomain> Date: Tue, 21 Dec 2004 06:27:04 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: LFB data sharing proposal/suggestion/discussion To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041220232217.03906988@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit On Mon, 2004-12-20 at 23:27, Joel M. Halpern wrote: > Given that the CE can read the aliases, I think it gets the "depends on" > automatically. The one implication is that we probably need to be clear > that the follow aliases bit has no effect on non-alias variables. That > way, the CE can fetch a struct which includes aliases, and decide whether > it wants the alias values or the target values. > Just to be sure we are on the same wavelength: I am talking essentially about "dependency resolution" of LFBs. As an example, assume the LPM LFB cant be in a policy topology without the NH LFB being in existence. So before even the CE gets to set or read aliases it would be beneficial to know the validity of a policy within a topology. You could build the dependencies as part of an operators contraints within the CE, but i see an opportunity in their explicit definition within the LFB schema. > Given taht several alias variables can in principle point to the same > element in some LFB, I guess it follows that a write to that element > through any one path will appear as a change to all the aliased elements. > I was thinking more of a "broadcast/multicast" update i.e a sort of concurent change to several instances of an LFB(s). Example: if i want to send a message from the CE to set an aliased attribute X in LFB Y, that the result of that is puking several LFB Selectors and either sending in one PL message or several PL messages ... > Zsolt and I will get this included in the Schema, if the working group > agrees to it. (You, me, Zsolt, and Steve are probably not enough voices on > this one.) We are working on some other issues, and we need to resolve the > subscripting mechanisms before we can actually produce an update. > In this particular case, I think the hard part will be the english > description of the semantics. The XML is pretty easy. Even the XML for > the type for an alias reference will not be particularly difficult (once we > decide about subscripting). The path sequence for exaple will simply be an > octet string. Sounds good. Please just keep me in the loop because we want to be implementing this piece starting first or second week of January. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Tue Dec 21 08:27: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 IAA06359 for ; Tue, 21 Dec 2004 08:27:16 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgkC6-0003IC-Ug for forces-archive@IETF.ORG; Tue, 21 Dec 2004 08:37:05 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F19276@cherry.ease.lsoft.com>; Tue, 21 Dec 2004 8:27:05 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50117634 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Dec 2004 08:26:49 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 21 Dec 2004 08:23:02 -0500 Received: from [69.170.11.244] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8340759 for FORCES@PEACH.EASE.LSOFT.COM; Tue, 21 Dec 2004 08:23:02 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1103317810.1023.179.camel@jzny.localdomain> <6.1.2.0.0.20041217162507.03eb0808@localhost> <1103324405.1049.36.camel@jzny.localdomain> <6.1.2.0.0.20041217195130.03f3bdf0@localhost> <1103598258.1049.0.camel@jzny.localdomain> <6.1.2.0.0.20041220232217.03906988@localhost> <1103628424.1046.155.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041221081534.03b32ec0@localhost> Date: Tue, 21 Dec 2004 08:21:47 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: LFB data sharing proposal/suggestion/discussion To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1103628424.1046.155.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d I doubt that there is any need for broadcast / multicast capability from a protocol point of view. If the LFB represent real things, then these aliases may get complicated to implement. However, I would expect that to be the FE controller's problem, not a protocol visible aspect. Given that the CE knows what aliases are already set up, and is setting the aliases for new variables, I think it knows the variables. Note that when necessary a CE can create an LFB(A) without linking it into the data path. Then it can create an LFB(B), set its aliases pointing to A, and put B in the data path. Then, when it is ready, the CE can insert A in the data path. So I think all dependencies can be dealt with. At the same time, I would hope that the design will be such that aliases are sparsely used. Designing the use of lots of aliases without making the CE design a nightmare seems to become more complex as the numbers go up. Part of the key is to remember (as you and I have discussed off list, but I wanted to bring up on the list) that an LFB does not need much in the way of "informational" attributes. If some value is not actually used by an LFB, there is no need for the attribute even ifwe are used to associating the two pieces of information. Yours, Joel At 06:27 AM 12/21/2004, Jamal Hadi Salim wrote: >On Mon, 2004-12-20 at 23:27, Joel M. Halpern wrote: > > Given that the CE can read the aliases, I think it gets the "depends on" > > automatically. The one implication is that we probably need to be clear > > that the follow aliases bit has no effect on non-alias variables. That > > way, the CE can fetch a struct which includes aliases, and decide whether > > it wants the alias values or the target values. > > > >Just to be sure we are on the same wavelength: >I am talking essentially about "dependency resolution" of LFBs. As an >example, assume the LPM LFB cant be in a policy topology without the NH >LFB being in existence. So before even the CE gets to set or read >aliases it would be beneficial to know the validity of a policy >within a topology. You could build the dependencies as part of an >operators contraints within the CE, but i see an opportunity in their >explicit definition within the LFB schema. > > > Given taht several alias variables can in principle point to the same > > element in some LFB, I guess it follows that a write to that element > > through any one path will appear as a change to all the aliased elements. > > > >I was thinking more of a "broadcast/multicast" update i.e a sort of >concurent change to several instances of an LFB(s). >Example: if i want to send a message from the CE to set an aliased >attribute X in LFB Y, that the result of that is puking several LFB >Selectors and either sending in one PL message or several >PL messages ... > > > Zsolt and I will get this included in the Schema, if the working group > > agrees to it. (You, me, Zsolt, and Steve are probably not enough > voices on > > this one.) We are working on some other issues, and we need to resolve > the > > subscripting mechanisms before we can actually produce an update. > > In this particular case, I think the hard part will be the english > > description of the semantics. The XML is pretty easy. Even the XML for > > the type for an alias reference will not be particularly difficult > (once we > > decide about subscripting). The path sequence for exaple will simply > be an > > octet string. > >Sounds good. Please just keep me in the loop because we want to be >implementing this piece starting first or second week of January. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 22 11:23: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 LAA08205 for ; Wed, 22 Dec 2004 11:23:42 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch9Qm-0003Ig-Ck for forces-archive@IETF.ORG; Wed, 22 Dec 2004 11:33:47 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00F1B3B5@cherry.ease.lsoft.com>; Wed, 22 Dec 2004 11:23:34 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50289664 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 11:23:34 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Dec 2004 11:22:47 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122208260565:90776 ; Wed, 22 Dec 2004 08:26:05 -0800 References: <1103317810.1023.179.camel@jzny.localdomain> <6.1.2.0.0.20041217162507.03eb0808@localhost> <1103324405.1049.36.camel@jzny.localdomain> <6.1.2.0.0.20041217195130.03f3bdf0@localhost> <1103598258.1049.0.camel@jzny.localdomain> <6.1.2.0.0.20041220232217.03906988@localhost> <1103628424.1046.155.camel@jzny.localdomain> <6.1.2.0.0.20041221081534.03b32ec0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/22/2004 08:26:05 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/22/2004 08:26:06 AM, Serialize complete at 12/22/2004 08:26:06 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103732564.1075.13.camel@jzny.localdomain> Date: Wed, 22 Dec 2004 11:22:45 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: LFB data sharing proposal/suggestion/discussion To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041221081534.03b32ec0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Ok, fine. Without going into any points in your email - for now lets just keep it simple - experience may show something else. cheers, jamal On Tue, 2004-12-21 at 08:21, Joel M. Halpern wrote: > I doubt that there is any need for broadcast / multicast capability from a > protocol point of view. > If the LFB represent real things, then these aliases may get complicated to > implement. However, I would expect that to be the FE controller's problem, > not a protocol visible aspect. > > Given that the CE knows what aliases are already set up, and is setting the > aliases for new variables, I think it knows the variables. Note that when > necessary a CE can create an LFB(A) without linking it into the data > path. Then it can create an LFB(B), set its aliases pointing to A, and put > B in the data path. Then, when it is ready, the CE can insert A in the > data path. So I think all dependencies can be dealt with. > > At the same time, I would hope that the design will be such that aliases > are sparsely used. Designing the use of lots of aliases without making > the CE design a nightmare seems to become more complex as the numbers go up. > > Part of the key is to remember (as you and I have discussed off list, but I > wanted to bring up on the list) that an LFB does not need much in the way > of "informational" attributes. If some value is not actually used by an > LFB, there is no need for the attribute even ifwe are used to associating > the two pieces of information. > > Yours, > Joel > > At 06:27 AM 12/21/2004, Jamal Hadi Salim wrote: > >On Mon, 2004-12-20 at 23:27, Joel M. Halpern wrote: > > > Given that the CE can read the aliases, I think it gets the "depends on" > > > automatically. The one implication is that we probably need to be clear > > > that the follow aliases bit has no effect on non-alias variables. That > > > way, the CE can fetch a struct which includes aliases, and decide whether > > > it wants the alias values or the target values. > > > > > > >Just to be sure we are on the same wavelength: > >I am talking essentially about "dependency resolution" of LFBs. As an > >example, assume the LPM LFB cant be in a policy topology without the NH > >LFB being in existence. So before even the CE gets to set or read > >aliases it would be beneficial to know the validity of a policy > >within a topology. You could build the dependencies as part of an > >operators contraints within the CE, but i see an opportunity in their > >explicit definition within the LFB schema. > > > > > Given taht several alias variables can in principle point to the same > > > element in some LFB, I guess it follows that a write to that element > > > through any one path will appear as a change to all the aliased elements. > > > > > > >I was thinking more of a "broadcast/multicast" update i.e a sort of > >concurent change to several instances of an LFB(s). > >Example: if i want to send a message from the CE to set an aliased > >attribute X in LFB Y, that the result of that is puking several LFB > >Selectors and either sending in one PL message or several > >PL messages ... > > > > > Zsolt and I will get this included in the Schema, if the working group > > > agrees to it. (You, me, Zsolt, and Steve are probably not enough > > voices on > > > this one.) We are working on some other issues, and we need to resolve > > the > > > subscripting mechanisms before we can actually produce an update. > > > In this particular case, I think the hard part will be the english > > > description of the semantics. The XML is pretty easy. Even the XML for > > > the type for an alias reference will not be particularly difficult > > (once we > > > decide about subscripting). The path sequence for exaple will simply > > be an > > > octet string. > > > >Sounds good. Please just keep me in the loop because we want to be > >implementing this piece starting first or second week of January. > > > >cheers, > >jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 22 11:23: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 LAA08223 for ; Wed, 22 Dec 2004 11:23:44 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch9Qp-0003Ig-Jt for forces-archive@IETF.ORG; Wed, 22 Dec 2004 11:33:49 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00F1B48D@cherry.ease.lsoft.com>; Wed, 22 Dec 2004 11:23:43 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50289679 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 11:23:43 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Dec 2004 11:20:36 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122208235295:90772 ; Wed, 22 Dec 2004 08:23:52 -0800 Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/22/2004 08:23:53 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/22/2004 08:23:55 AM, Serialize complete at 12/22/2004 08:23:55 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103732431.1075.8.camel@jzny.localdomain> Date: Wed, 22 Dec 2004 11:20:32 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Events revisted To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Does anyone see events as anything else other than change of state of attributes? Looking at the port LFB definition, I am definetely interested in more than just admin/operational attribute changes. We could add a class definition for events, but the more i think about it the more i think that we should just flag the data definitions with "event-capable" flag. Thoughts? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 22 11:30: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 LAA09732 for ; Wed, 22 Dec 2004 11:30:59 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch9Xg-0003Wo-DU for forces-archive@IETF.ORG; Wed, 22 Dec 2004 11:41:04 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <2.00F1B469@cherry.ease.lsoft.com>; Wed, 22 Dec 2004 11:30:48 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50290471 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 11:30:48 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Dec 2004 11:29:27 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8354786 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 11:29:26 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1103732431.1075.8.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041222112710.039db878@localhost> Date: Wed, 22 Dec 2004 11:29:18 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Events revisted To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1103732431.1075.8.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 If we use management protocols as exemplars, events are often thresholded changes in attributes. ~If there are more than 5 line errors in 10 seconds, generate the alarm~ kinds of things. While all of the parameters are attributes, it is not really accurate to say that any one variable is "event-capable". Also, explicitly defining the events can allow us to define what information should be sent with the events. This can help the CE quickly do the right thing. Yours, Joel At 11:20 AM 12/22/2004, Jamal Hadi Salim wrote: >Does anyone see events as anything else other than change of state of >attributes? >Looking at the port LFB definition, I am definetely interested in more >than just admin/operational attribute changes. >We could add a class definition for events, but the more i think about >it the more i think that we should just flag the data definitions with >"event-capable" flag. Thoughts? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 22 11:44: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 LAA11205 for ; Wed, 22 Dec 2004 11:44:17 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ch9kj-0003ts-1p for forces-archive@IETF.ORG; Wed, 22 Dec 2004 11:54:22 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00F1B4AE@cherry.ease.lsoft.com>; Wed, 22 Dec 2004 11:44:17 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50291683 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 11:44:16 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Dec 2004 11:41:39 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122208445693:90806 ; Wed, 22 Dec 2004 08:44:56 -0800 References: <1103732431.1075.8.camel@jzny.localdomain> <6.1.2.0.0.20041222112710.039db878@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/22/2004 08:44:57 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/22/2004 08:44:58 AM, Serialize complete at 12/22/2004 08:44:58 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103733696.1074.19.camel@jzny.localdomain> Date: Wed, 22 Dec 2004 11:41:36 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Events revisted To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041222112710.039db878@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit On Wed, 2004-12-22 at 11:29, Joel M. Halpern wrote: > If we use management protocols as exemplars, events are often thresholded > changes in attributes. ~If there are more than 5 line errors in 10 > seconds, generate the alarm~ kinds of things. While all of the parameters > are attributes, it is not really accurate to say that any one variable is > "event-capable". > > Also, explicitly defining the events can allow us to define what > information should be sent with the events. This can help the CE quickly > do the right thing. Good point. So I take it we need a class definition for events. Next step: Take a set of ports in a table in which say i am interested in 1/2 of the attributes per port type: Do you need a corresponding event table that has paths to those attributes? How do you define thresholds? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 22 14:00: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 OAA23362 for ; Wed, 22 Dec 2004 14:00:10 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChBru-000812-CU for forces-archive@IETF.ORG; Wed, 22 Dec 2004 14:10:15 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F1B414@cherry.ease.lsoft.com>; Wed, 22 Dec 2004 13:59:47 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50301325 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 13:59:46 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Dec 2004 13:59:23 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8356474 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 13:59:22 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1103732431.1075.8.camel@jzny.localdomain> <6.1.2.0.0.20041222112710.039db878@localhost> <1103733696.1074.19.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041222135811.038a1ca8@localhost> Date: Wed, 22 Dec 2004 13:59:12 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Events revisted To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1103733696.1074.19.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a The schema for defining an LFB will have to include provision for describing the events the LFB can generate. Then the LFB declaration will have to include the events that LFB can generate, and the IDs used to registor for those events. Yours, Joel At 11:41 AM 12/22/2004, Jamal Hadi Salim wrote: >On Wed, 2004-12-22 at 11:29, Joel M. Halpern wrote: > > If we use management protocols as exemplars, events are often thresholded > > changes in attributes. ~If there are more than 5 line errors in 10 > > seconds, generate the alarm~ kinds of things. While all of the parameters > > are attributes, it is not really accurate to say that any one variable is > > "event-capable". > > > > Also, explicitly defining the events can allow us to define what > > information should be sent with the events. This can help the CE quickly > > do the right thing. > >Good point. So I take it we need a class definition for events. > >Next step: >Take a set of ports in a table in which say i am interested in 1/2 of >the attributes per port type: Do you need a corresponding event table >that has paths to those attributes? >How do you define thresholds? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 22 14:31: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 OAA25609 for ; Wed, 22 Dec 2004 14:31:11 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChCMF-0000Or-AR for forces-archive@IETF.ORG; Wed, 22 Dec 2004 14:41:17 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00F1B563@cherry.ease.lsoft.com>; Wed, 22 Dec 2004 14:31:08 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50305032 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 14:31:07 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Dec 2004 14:30:37 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122211335458:91028 ; Wed, 22 Dec 2004 11:33:54 -0800 References: <1103732431.1075.8.camel@jzny.localdomain> <6.1.2.0.0.20041222112710.039db878@localhost> <1103733696.1074.19.camel@jzny.localdomain> <6.1.2.0.0.20041222135811.038a1ca8@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/22/2004 11:33:54 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/22/2004 11:33:56 AM, Serialize complete at 12/22/2004 11:33:56 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103743833.1077.31.camel@jzny.localdomain> Date: Wed, 22 Dec 2004 14:30:33 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Events revisted To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041222135811.038a1ca8@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Wed, 2004-12-22 at 13:59, Joel M. Halpern wrote: > The schema for defining an LFB will have to include provision for > describing the events the LFB can generate. Then the LFB declaration will > have to include the events that LFB can generate, and the IDs used to > registor for those events. > Most likey something along this sample: -- . . EventPortTable 3 table of Events one row per Port porteventdesc . . ----- Registration would have to explicitly mention path (to ID 3 means everything in the sample table). Events generation will also have paths + optionally data included. Thoughts? cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 22 14:53: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 OAA27064 for ; Wed, 22 Dec 2004 14:53:28 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChChm-00012C-Pe for forces-archive@IETF.ORG; Wed, 22 Dec 2004 15:03:34 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F1B699@cherry.ease.lsoft.com>; Wed, 22 Dec 2004 14:53:24 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50306795 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 14:53:22 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Dec 2004 14:46:23 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8356841 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 14:46:22 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1103732431.1075.8.camel@jzny.localdomain> <6.1.2.0.0.20041222112710.039db878@localhost> <1103733696.1074.19.camel@jzny.localdomain> <6.1.2.0.0.20041222135811.038a1ca8@localhost> <1103743833.1077.31.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041222144310.03b2e9a0@localhost> Date: Wed, 22 Dec 2004 14:46:11 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Events revisted To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1103743833.1077.31.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Looks like a good start. A couple of questions: What does access mean? I would expect the event to include a list of variables from the to be included in the event notification? Is there some other thing the TypeRef is to reference? I presume that the trigger conditions are described in English prose. Thresholds would be LFB variables defined in the main part of the LFB Class definition? Thanks, Joel At 02:30 PM 12/22/2004, Jamal Hadi Salim wrote: >On Wed, 2004-12-22 at 13:59, Joel M. Halpern wrote: > > The schema for defining an LFB will have to include provision for > > describing the events the LFB can generate. Then the LFB declaration will > > have to include the events that LFB can generate, and the IDs used to > > registor for those events. > > > >Most likey something along this sample: > >-- > > >. >. > > > EventPortTable > 3 > table of Events one row per Port > porteventdesc > > >. >. > > > >----- > >Registration would have to explicitly mention path (to ID 3 means >everything in the sample table). Events generation will also have paths >+ optionally data included. Thoughts? > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 22 15:33: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 PAA00778 for ; Wed, 22 Dec 2004 15:33:57 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChDL1-00023M-8T for forces-archive@IETF.ORG; Wed, 22 Dec 2004 15:44:04 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00F1B6A9@cherry.ease.lsoft.com>; Wed, 22 Dec 2004 15:33:58 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50312193 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 15:33:57 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Dec 2004 15:33:28 -0500 Received: from [10.0.0.9] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122212364543:91136 ; Wed, 22 Dec 2004 12:36:45 -0800 References: <1103732431.1075.8.camel@jzny.localdomain> <6.1.2.0.0.20041222112710.039db878@localhost> <1103733696.1074.19.camel@jzny.localdomain> <6.1.2.0.0.20041222135811.038a1ca8@localhost> <1103743833.1077.31.camel@jzny.localdomain> <6.1.2.0.0.20041222144310.03b2e9a0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/22/2004 12:36:45 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/22/2004 12:36:47 PM, Serialize complete at 12/22/2004 12:36:47 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103747605.1076.68.camel@jzny.localdomain> Date: Wed, 22 Dec 2004 15:33:25 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: Znyx Networks Subject: Re: Events revisted To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041222144310.03b2e9a0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit On Wed, 2004-12-22 at 14:46, Joel M. Halpern wrote: > Looks like a good start. > > A couple of questions: > What does access mean? ACL - a hint to show CE cant update those variables. Maybe this is not so reflective if you are going to set notification thresholds. > I would expect the event to include a list of variables from the to be > included in the event notification? Any port attribute whose state could change, or some set threshold crossed resulting in an event would be listed in that porteventdesc. For subscription purposes you would need the following: a) a path b) Perhaps a way to define a threshold. A threahold could be as simple as a MTU change regardless of the value and like you described earlier "error count exceeded 10" c) a verbosity level (revisits our old discussion here;->) i) "let me know when the threshold gets crossed" vs ii)"let me know when the threshold gets crossed and what value it crossed to" For notification: a) A path b) optionally a data value for that path as per registration. > Is there some other thing the TypeRef > is to reference? > I presume that the trigger conditions are described in English > prose. Thresholds would be LFB variables defined in the main part of the > LFB Class definition? > Refer to my comment above. I dont wanna complicate things; but the eventdescp path reference maybe just an alias that refers to the local attribute. For thresholds maybe we could learn something from RMON gauges. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 22 15:41: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 PAA01413 for ; Wed, 22 Dec 2004 15:41:47 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChDSP-0002Iw-Md for forces-archive@IETF.ORG; Wed, 22 Dec 2004 15:51:54 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00F1B708@cherry.ease.lsoft.com>; Wed, 22 Dec 2004 15:41:35 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50312748 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 15:41:34 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Dec 2004 15:39:36 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8357240 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 15:39:35 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1103732431.1075.8.camel@jzny.localdomain> <6.1.2.0.0.20041222112710.039db878@localhost> <1103733696.1074.19.camel@jzny.localdomain> <6.1.2.0.0.20041222135811.038a1ca8@localhost> <1103743833.1077.31.camel@jzny.localdomain> <6.1.2.0.0.20041222144310.03b2e9a0@localhost> <1103747605.1076.68.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041222153723.03b72fc0@localhost> Date: Wed, 22 Dec 2004 15:39:23 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Events revisted To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1103747605.1076.68.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Given that there is only one CE in charge of the FE (we don't have the SNMP multi-manager problem) it seems that the threshold can just be an attribute of the LFB. I would really like the event definition to indicate which variables should be sent. I don't think that "all variables of the triggering LFB" is a useful definition. But the CE needs to know what to expect, and how to parse it. Yours, Joel At 03:33 PM 12/22/2004, Jamal Hadi Salim wrote: >On Wed, 2004-12-22 at 14:46, Joel M. Halpern wrote: > > Looks like a good start. > > > > A couple of questions: > > What does access mean? > >ACL - a hint to show CE cant update those variables. Maybe this is not >so reflective if you are going to set notification thresholds. > > > I would expect the event to include a list of variables from the to be > > included in the event notification? > >Any port attribute whose state could change, or some set threshold >crossed resulting in an event would be listed in that porteventdesc. > >For subscription purposes you would need the following: >a) a path >b) Perhaps a way to define a threshold. A threahold could be as simple >as a MTU change regardless of the value and like you described earlier >"error count exceeded 10" >c) a verbosity level (revisits our old discussion here;->) >i) "let me know when the threshold gets crossed" vs ii)"let me know >when the threshold gets crossed and what value it crossed to" > >For notification: >a) A path >b) optionally a data value for that path as per registration. > > > > Is there some other thing the TypeRef > > is to reference? > > I presume that the trigger conditions are described in English > > prose. Thresholds would be LFB variables defined in the main part of the > > LFB Class definition? > > > >Refer to my comment above. I dont wanna complicate things; but the >eventdescp path reference maybe just an alias that refers to the local >attribute. >For thresholds maybe we could learn something from RMON gauges. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 22 16:43: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 QAA06152 for ; Wed, 22 Dec 2004 16:43:16 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChEQ6-0004Gc-Vh for forces-archive@IETF.ORG; Wed, 22 Dec 2004 16:53:24 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.00F1B6FD@cherry.ease.lsoft.com>; Wed, 22 Dec 2004 16:43:15 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50317130 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 16:43:03 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Dec 2004 16:42:33 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122213455132:91345 ; Wed, 22 Dec 2004 13:45:51 -0800 References: <1103732431.1075.8.camel@jzny.localdomain> <6.1.2.0.0.20041222112710.039db878@localhost> <1103733696.1074.19.camel@jzny.localdomain> <6.1.2.0.0.20041222135811.038a1ca8@localhost> <1103743833.1077.31.camel@jzny.localdomain> <6.1.2.0.0.20041222144310.03b2e9a0@localhost> <1103747605.1076.68.camel@jzny.localdomain> <6.1.2.0.0.20041222153723.03b72fc0@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/22/2004 01:45:51 PM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/22/2004 01:45:52 PM, Serialize complete at 12/22/2004 01:45:52 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103751750.1079.13.camel@jzny.localdomain> Date: Wed, 22 Dec 2004 16:42:30 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Events revisted To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041222153723.03b72fc0@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit On Wed, 2004-12-22 at 15:39, Joel M. Halpern wrote: > Given that there is only one CE in charge of the FE (we don't have the SNMP > multi-manager problem) it seems that the threshold can just be an attribute > of the LFB. Is this because we can set its values from the management side? > I would really like the event definition to indicate which variables should > be sent. I don't think that "all variables of the triggering LFB" is a > useful definition. But the CE needs to know what to expect, and how to > parse it. Parse error. The porteventdesc (a datatypedef specific to the port LFB) constitutes attributes upon whose state/threshold changes an event is triggered. Example the MTU attribute to the port would fit such a definition. In the worst case _all_ attributes of an LFB could generate events. In such a case the "all" variables applies and will therefore _all_ be listed. Paste me some xml if ia m missing something maybe then it will become clear. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Wed Dec 22 17:50: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 RAA13633 for ; Wed, 22 Dec 2004 17:50:33 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChFT4-0006NI-07 for forces-archive@IETF.ORG; Wed, 22 Dec 2004 18:00:41 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00F1BA86@cherry.ease.lsoft.com>; Wed, 22 Dec 2004 17:50:22 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50324206 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 17:50:21 -0500 Approved-By: joel@STEVECROCKER.COM Received: from 208.184.15.238 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 22 Dec 2004 17:47:19 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 8358395 for FORCES@PEACH.EASE.LSOFT.COM; Wed, 22 Dec 2004 17:47:18 -0500 X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 References: <1103732431.1075.8.camel@jzny.localdomain> <6.1.2.0.0.20041222112710.039db878@localhost> <1103733696.1074.19.camel@jzny.localdomain> <6.1.2.0.0.20041222135811.038a1ca8@localhost> <1103743833.1077.31.camel@jzny.localdomain> <6.1.2.0.0.20041222144310.03b2e9a0@localhost> <1103747605.1076.68.camel@jzny.localdomain> <6.1.2.0.0.20041222153723.03b72fc0@localhost> <1103751750.1079.13.camel@jzny.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <6.1.2.0.0.20041222174417.03bc1890@localhost> Date: Wed, 22 Dec 2004 17:47:04 -0500 Reply-To: "Joel M. Halpern" Sender: Forwarding and Control Element Separation From: "Joel M. Halpern" Subject: Re: Events revisted To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <1103751750.1079.13.camel@jzny.localdomain> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 The question of variables for the notification may be simply a matter of my misreading the description. I would expect to see a list of variables from the LFB Class that has the event notification. A typeRef is a declaration of the type of something, not a reference to other attributes. The type of the content of the notification will be the synthetic struct built from the sequence of the types of the referenced attributes. There is an interesting syntactic issue of how we say "the subscript from the table element that went over threshold, and these attributes from that table element." I am sure we can work this out. This really only affects the XML, not the on-the-wire protocol. Yours, Joel At 04:42 PM 12/22/2004, Jamal Hadi Salim wrote: >On Wed, 2004-12-22 at 15:39, Joel M. Halpern wrote: > > Given that there is only one CE in charge of the FE (we don't have the > SNMP > > multi-manager problem) it seems that the threshold can just be an > attribute > > of the LFB. > >Is this because we can set its values from the management side? > > > I would really like the event definition to indicate which variables > should > > be sent. I don't think that "all variables of the triggering LFB" is a > > useful definition. But the CE needs to know what to expect, and how to > > parse it. > >Parse error. >The porteventdesc (a datatypedef specific to the port LFB) constitutes >attributes upon whose state/threshold changes an event is triggered. >Example the MTU attribute to the port would fit such a definition. In >the worst case _all_ attributes of an LFB could generate events. In such >a case the "all" variables applies and will therefore _all_ be listed. >Paste me some xml if ia m missing something maybe then it will become >clear. > >cheers, >jamal From owner-forces@PEACH.EASE.LSOFT.COM Thu Dec 23 08:09: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 IAA06405 for ; Thu, 23 Dec 2004 08:09:41 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChSsl-0002bq-Vp for forces-archive@IETF.ORG; Thu, 23 Dec 2004 08:19:56 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00F1CDB6@cherry.ease.lsoft.com>; Thu, 23 Dec 2004 8:09:39 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50416044 for FORCES@PEACH.EASE.LSOFT.COM; Thu, 23 Dec 2004 08:09:38 -0500 Approved-By: hadi@ZNYX.COM Received: from 208.2.156.7 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 23 Dec 2004 07:57:09 -0500 Received: from [127.0.0.1] ([208.2.156.2]) by lotus.znyx.com (Lotus Domino Release 5.0.11) with ESMTP id 2004122305002467:92806 ; Thu, 23 Dec 2004 05:00:24 -0800 References: <1103732431.1075.8.camel@jzny.localdomain> <6.1.2.0.0.20041222112710.039db878@localhost> <1103733696.1074.19.camel@jzny.localdomain> <6.1.2.0.0.20041222135811.038a1ca8@localhost> <1103743833.1077.31.camel@jzny.localdomain> <6.1.2.0.0.20041222144310.03b2e9a0@localhost> <1103747605.1076.68.camel@jzny.localdomain> <6.1.2.0.0.20041222153723.03b72fc0@localhost> <1103751750.1079.13.camel@jzny.localdomain> <6.1.2.0.0.20041222174417.03bc1890@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 X-MIMETrack: Itemize by SMTP Server on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/23/2004 05:00:25 AM, Serialize by Router on Lotus/Znyx(Release 5.0.11 |July 24, 2002) at 12/23/2004 05:00:27 AM, Serialize complete at 12/23/2004 05:00:27 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain Message-ID: <1103806623.1075.36.camel@jzny.localdomain> Date: Thu, 23 Dec 2004 07:57:03 -0500 Reply-To: hadi@znyx.com Sender: Forwarding and Control Element Separation From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Events revisted To: FORCES@PEACH.EASE.LSOFT.COM In-Reply-To: <6.1.2.0.0.20041222174417.03bc1890@localhost> Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit On Wed, 2004-12-22 at 17:47, Joel M. Halpern wrote: > The question of variables for the notification may be simply a matter of my > misreading the description. > I would expect to see a list of variables from the LFB Class that has the > event notification. > A typeRef is a declaration of the type of something, not a reference to > other attributes. You need to define the list and where to store the associated parameters. Example of associated parameters: thresholds and paths to the subscrisable events (which i dont think equate to paths to attributes they represent). You need some descripion per event-capable attribute. In the case of the port LFB, the list is per port and we have a table of such ports. Indidual ports in the table maybe of different type within one FE (ethernet, POS,etc) and may not have exactly the same subscrisable events. The difference in subscrisable events applies even to ports of the same type (such as ethernet). To summarize, what i meant by a porteventdesc (a datatypedef), would look like: { ifindex of targeted port, name maybe, MTU: ID = x, optional, Path of value being targeted (maybe unnecessary), real threshold description here; Admin state: ID = Y, .. .. .. .. } port event desriptor type Later define a table of these that corresponds to the table of ports (hence the typeref). Are we saying the same thing? > The type of the content of the notification will be the synthetic struct > built from the sequence of the types of the referenced attributes. There > is an interesting syntactic issue of how we say "the subscript from the > table element that went over threshold, and these attributes from that > table element." I am sure we can work this out. This really only affects > the XML, not the on-the-wire protocol. > Send the XML ;-> some variant of flags on the path-data seems to me like will suffice. cheers, jamal From owner-forces@PEACH.EASE.LSOFT.COM Mon Dec 27 02:57: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 CAA18105 for ; Mon, 27 Dec 2004 02:57:12 -0500 (EST) Received: from cherry.ease.lsoft.com ([209.119.0.109]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CipvK-0002Zg-KF for forces-archive@IETF.ORG; Mon, 27 Dec 2004 03:08:15 -0500 Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00F2404B@cherry.ease.lsoft.com>; Mon, 27 Dec 2004 2:57:09 -0500 Received: by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 14.3) with spool id 50820999 for FORCES@PEACH.EASE.LSOFT.COM; Mon, 27 Dec 2004 02:57:07 -0500 Approved-By: hormuzd.m.khosravi@INTEL.COM Received: from 134.134.136.19 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 27 Dec 2004 02:54:23 -0500 Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id iBR7sNQi004392; Mon, 27 Dec 2004 07:54:23 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id iBR7sHkW004948; Mon, 27 Dec 2004 07:54:22 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 M2004122623542230051 ; Sun, 26 Dec 2004 23:54:22 -0800 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, 26 Dec 2004 23:54:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [FORCES] Issue Resolution - Issue #1: Feedback, protocol section 6.2 Thread-Index: AcTnD8JpCqU9rakoR1OqUonZlkrycwE2Gf1w X-OriginalArrivalTime: 27 Dec 2004 07:54:22.0675 (UTC) FILETIME=[47254A30:01C4EBE9] X-Scanned-By: MIMEDefang 2.44 Message-ID: <468F3FDA28AA87429AD807992E22D07E025792B5@orsmsx408> Date: Sun, 26 Dec 2004 23:54:09 -0800 Reply-To: "Khosravi, Hormuzd M" Sender: Forwarding and Control Element Separation From: "Khosravi, Hormuzd M" Subject: Re: Issue Resolution - Issue #1: Feedback, protocol section 6.2 Comments: To: hadi@znyx.com To: FORCES@PEACH.EASE.LSOFT.COM Precedence: list X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Jamal, Sorry for the late reply. Pls see my replies below... -----Original Message----- From: Forwarding and Control Element Separation Of Jamal Hadi Salim > >=20 > > 2) I am not sure what the Show / Advertise operations are intended to > > reflect. Those may be Gets, or they may be something else that > requires > > elucidation. >=20 > The Name "advertised" by the FE is infact the attribute "FEName" - to be > found in the FEObject LFB instance. > [HK] I think we have some misunderstanding here, not sure what gave you > this impression, > but the "advertise" operation is used to advertise the > entire FE protocol object=20 Did you mean the FE Object LFB? [I actually meant the FE Protocol object, may be we need both?] The FEname and FEID are stored in the FEObject. Heres the way i see it: The typical path is a CE setting things in the FE Object LFB. The exceptions are things like the FEID in which the FE on association setup can announce a 0 FEID in the main header as a signal it needs to be assigned one. We also allow for it to provide one to the CE if it knows what it is (example based on a geographical chasis location you could come up with a static ID scheme). The other exception i can think of that the FE would know on bootup is its name (we could probably add vendor specific items in this list as well - eg what model it is etc). So those are the two things that belong to the FE Object that a FE can "advertise" to the CE. Both of which are infact read/write i.e can be overriden in the response (with the CE setting the values by directing them to the FE Object attribute). ** There is a scenario where an FE may actually have a lot more attributes on the FE Object populated. Such is in the case of a situation where an FE is forced to reassociate for example - maybe due to lost communication or a restart of some form. So the summary of what i am saying is the FE OBject LFB is a source as well as sink of the Association msg/response. If there are any attributes already known to the FE then it makes sense to notify the CE of their state (the name being one of them).=20 [HK] Yes I agree with that...similar to what I am saying. I think we will need both the FE Object and FE Protocol object to be advertised in the Association message. You pointed out a good scenario where FE would have more info than just FE Name to be advertised to the CE. > Let me know how you would like to resolve this? Any suggestions would be > welcome. Isnt this discussion the point? If we dont get anywhere i will capture it in the tracking database. [I think if we agree with the comments above, we have resolved this one...atleast partly] > One more thing, you had asked for a special TLV -> FORCES_REASON for the > Teardown msg. Since we would both like to avoid this, any suggestions on > how this can be accommodated via FE LFBs? May be we remove the Reason > completely from the Teardown msg?...let me know your thoughts? This is a hard one. We could send it easily (either direction) if it is an attribute. I think for logging debugging purposes we would need to know the departure reasons. But whose attribute is this? Maybe other people have opinions. [HK] We could use similar mechanism as we do to report all our results, to report the Reason. Let me know your thoughts, Thanks Hormuzd