2006 Message-Id: Date: Wed, 1 Nov 2006 09:43:12 +0800 From: Jia Fenggen Subject: Packet redirect:fixed meta data ID assignment,into IANA part? Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed In protocol draft version 8,the redirect packet is transimitted to CE using an redirect TLV encapsulation which has two main constructors:meta-data ILVs which encapsulate the associated meta informations with the packet such as output id,input port id etc and Redirect data TLV which encapsulate the real packet.According to meta ILV,the identifier of meta data is important,I look through issue32,it seems that on paris wg meeting we have come to an consensus that static metadata assignment will be used, with metadata transcoding as necessary.To make static meta data assignment,i think we should put meta data ID assignment to IANA consideration,if that is the case,then we need some inital meta data definitions,are there any mistakes,thanks. Yours,Fenggen _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn 2006 Message-Id: Date: Fri, 10 Nov 2006 14:24:14 +0800 From: "Guo,xiaoyi" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Joel You means we should change some contents for clarify this both in model and protocol draft ? Thanks, Xiaoyi 2006/11/9, Joel M. Halpern : > I think that I understand the question. > The IDs used in path-data TLVs are not just any arbitrary XML > elements that happen to have elementID attributes. > They must be or components. > This is actually implicit in the fact that other XML "elements" (in > the XML sense) are not legal in the document. > When we get the terminology straightened out in both the model and > the protocol draft, this potential confusion should disappear. > > Yours, > Joel > 2006 Message-Id: Date: Fri, 10 Nov 2006 06:54:42 +0800 From: "Ma.Huaiyuan 50376" Subject: =?gb2312?Q?=BB=D8=B8=B4:Re:_=BB=D8=B8=B4:Re:_=BB=D8=B8=B4:ForCES?= meeting minutes (draft) Comments: To: "Joel M. Halpern" MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Dear Joel=3A In fact=2C many policies could be applied many times in different FEs rat= her than just in a single FE=2C for example=2C hierachy QoS (HQOS)=2E Best=2C Michael ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Joel M=2E Halpern=22 =3Cjoel=40stevecrocker=2Eco= m=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =CA=AE=D2=BB=D4=C2 9=C8=D5=2C 2006 = =CF=C2=CE=E71=3A10 =D6=F7=CC=E2=3A Re=3A =BB=D8=B8=B4=3ARe=3A =BB=D8=B8=B4=3AForCES meeting = minutes (draft) =3E In a ForCES based router=2C the ingress policies would be applied = =3E on = =3E the board that first receives the packets=2E It knows what port the = =3E packets arrive on=2E =3E I would recommend (but the standard can not mandate) that one use = =3E separate ethernet ports to interconnect the FEs=2C distinct from the = =3E ports used to send and receive external traffic=2E But that is an = =3E implementation choice=2E =3E = =3E Yours=2C =3E Joel M=2E Halpern =3E = =3E At 09=3A15 PM 11/8/2006=2C you wrote=3A =3E =3EFor Example=2C in traditional router=2C many policies are based on= = =3E =3Esource port in forwarding process=2E =3E =3Efor instance=2C to filter some unwanted traffic based on the sourc= e = =3E port=2C=3Eand source port information could be different for each = =3E packet=2C and = =3E =3Edestination address in the header of packets =3E =3Ehas no relationship with the source port=2C given that the source = =3E port = =3E =3Eis carried in meta-data=2C I do not know how =3E =3Eto reconstruct this info again when it is needed later=2E =3E =3E =3E =3E =3E =3EKind Regards=2C =3E =3E =3E =3EMichael =3E 2006 Message-Id: Date: Thu, 9 Nov 2006 10:26:50 -0500 From: "Joel M. Halpern" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I think that I understand the question. The IDs used in path-data TLVs are not just any arbitrary XML elements that happen to have elementID attributes. They must be or components. This is actually implicit in the fact that other XML "elements" (in the XML sense) are not legal in the document. When we get the terminology straightened out in both the model and the protocol draft, this potential confusion should disappear. Yours, Joel At 04:17 AM 11/9/2006, tom.petch wrote: >----- Original Message ----- >From: "Joel M. Halpern" >Sent: Wednesday, November 08, 2006 6:36 PM >Subject: Re: terminology wa Re: XML basics Re: LC model draft >draft-ietf-forces-model-07.txt > > > > All pieces of information that the ForCES protocol can manipulate are > > described in LFB Class definitions using the LFB components defined > > in the schema (currently called capability, attribute, and event, > > along with element properties.) > > Given the existence of documentation elements, there is no reason to > > use arbitrary XML in the definitions, and the schema does not permit > > arbitrary elements. > > >Ok so far but I am asking more. If a CE wishes to access a piece of data by >itself (not as part of a larger structure) using PATH-DATA-TLV, then must that >piece of data be defined as an XML element as opposed to being >defined as an XML >attribute? > >This is fundamental to my understanding of how -model and -protocol link >together and I do not see it clearly stated. s7.6 may or may not say this >depending on which of the many possible interpretations is given to the terms >'element' and 'identifier':-( > >Thus s7.6 might be reworded as > "The FE Model provides for the definition of LFB Classes. Each > LFB Class has >a globally unique identifier, assigned by IANA. Each instance of a particular >LFB Class within an NE also has a unique identifier. Data elements >that can be >accessed by the protocol using a PATH-DATA-TLV are defined as XML elements and >each is assigned an identifier (using the XML attribute "elementID= ") that is >unique within an LFB Class. The combination of LFB Class identifier, LFB >instance identifier and element identifier(s) is used by the protocol to >reference the LFB information in the protocol operations. " > >Have I got it? ((skating over for the moment elementIDs in events and >structures) > >Tom Petch > > > (This may suggest to some a compatibility issue. The idea is that if > > the schema is ever extended then old definitions will be compatible > > with the new schema, but new definitions will not be compatible with > > the old schema. Given the need for semantic knowledge for anything > > making uses of LFB class definitions, this does not seem to be a problem.) > > > > Yours, > > Joel M. Halpern > > > > At 09:49 AM 11/8/2006, tom.petch wrote: > > >In general, most of what can be done in XML can be done by using XML > > >attributes > > >of XML elements or by using XML elements per se. So a second > point is, I am > > >unclear in -model whether the intention is that all pieces of data > > >that a CE can > > >read or write are expressed as XML elements or are some of them XML >attributes > > >(of XML elements). This has ramifications for identifiers and namespaces > > >and -protocol. 2006 Message-Id: Date: Thu, 9 Nov 2006 10:17:57 +0100 From: "tom.petch" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Comments: To: "Joel M. Halpern" Comments: cc: Ellen Deleganes MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Joel M. Halpern" Sent: Wednesday, November 08, 2006 6:36 PM Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt > All pieces of information that the ForCES protocol can manipulate are > described in LFB Class definitions using the LFB components defined > in the schema (currently called capability, attribute, and event, > along with element properties.) > Given the existence of documentation elements, there is no reason to > use arbitrary XML in the definitions, and the schema does not permit > arbitrary elements. > Ok so far but I am asking more. If a CE wishes to access a piece of data by itself (not as part of a larger structure) using PATH-DATA-TLV, then must that piece of data be defined as an XML element as opposed to being defined as an XML attribute? This is fundamental to my understanding of how -model and -protocol link together and I do not see it clearly stated. s7.6 may or may not say this depending on which of the many possible interpretations is given to the terms 'element' and 'identifier':-( Thus s7.6 might be reworded as "The FE Model provides for the definition of LFB Classes. Each LFB Class has a globally unique identifier, assigned by IANA. Each instance of a particular LFB Class within an NE also has a unique identifier. Data elements that can be accessed by the protocol using a PATH-DATA-TLV are defined as XML elements and each is assigned an identifier (using the XML attribute "elementID= ") that is unique within an LFB Class. The combination of LFB Class identifier, LFB instance identifier and element identifier(s) is used by the protocol to reference the LFB information in the protocol operations. " Have I got it? ((skating over for the moment elementIDs in events and structures) Tom Petch > (This may suggest to some a compatibility issue. The idea is that if > the schema is ever extended then old definitions will be compatible > with the new schema, but new definitions will not be compatible with > the old schema. Given the need for semantic knowledge for anything > making uses of LFB class definitions, this does not seem to be a problem.) > > Yours, > Joel M. Halpern > > At 09:49 AM 11/8/2006, tom.petch wrote: > >In general, most of what can be done in XML can be done by using XML > >attributes > >of XML elements or by using XML elements per se. So a second point is, I am > >unclear in -model whether the intention is that all pieces of data > >that a CE can > >read or write are expressed as XML elements or are some of them XML attributes > >(of XML elements). This has ramifications for identifiers and namespaces > >and -protocol. 2006 Message-Id: Date: Thu, 9 Nov 2006 10:15:15 +0800 From: "Ma.Huaiyuan 50376" Subject: =?gb2312?Q?=BB=D8=B8=B4:Re:_=BB=D8=B8=B4:ForCES?= meeting minutes (draft) Comments: To: "Joel M. Halpern" MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Dear Joel=3A *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained herein in any way (in= cluding=2C but not limited to=2C total or partial disclosure=2C reproduct= ion=2C or dissemination) by persons other than the intended recipient(s) = is prohibited=2E If you receive this e-mail in error=2C please notify the= sender by phone or em ail immediately and delete it! ************************************************************************= **************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A =22Joel M=2E Halpern=22 =3Cjoel=40stevecrocker=2Eco= m=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =CA=AE=D2=BB=D4=C2 9=C8=D5=2C 2006 = =C9=CF=CE=E79=3A22 =D6=F7=CC=E2=3A Re=3A =BB=D8=B8=B4=3AForCES meeting minutes (draft) =3E There are two issues here=3A =3E = =3E 1) We have all agreed that it is desirable to be able to pass = =3E meta-data between FEs=2E This is the Fi interface=2E =3E 2) We can build solutions with FEs from different vendors without = =3E passing meta-data=2E We do not get teh degree of scaling we would = =3E like=2C but it does still work=2E Assertions that it does not work = =3E will = =3E prevent folks from utilizing the protocol=2C and therefore prevent = =3E us = =3E from ever getting to work on Fi=2E (I am very confident that doing = =3E this without passing meta-data around is useful because I have = =3E over = =3E the years built several sets of solutions that were distributed = =3E routers without meta data passing=2E) For Example=2C in traditional router=2C many policies are based on source= port in forwarding process=2E for instance=2C to filter some unwanted traffic based on the source port=2C= = and source port information could be different for each packet=2C and des= tination address in the header of packets has no relationship with the source port=2C given that the source port is= carried in meta-data=2C I do not know how = to reconstruct this info again when it is needed later=2E Kind Regards=2C Michael = =3E = =3E As a background=2C this issue of inter-FE communication within an NE = =3E does not depend upon nor is it driven by the integration of legacy = =3E routers=2E It is desirable in and of itself=2E =3E Once it is done=2C the legacy router integration techniques will be = =3E able to make use of it=2C likely with no further change to the = =3E protocol = =3E mechanisms=2E =3E = =3E Yours=2C =3E Joel M=2E Halpern =3E = =3E At 08=3A03 PM 11/8/2006=2C Ma=2EHuaiyuan 50376 wrote=3A =3E =3EAnyway=2C we have to solve this problem sooner or later=2C without= = =3E =3Edefining this meta-data properly=2C =3E =3EFEs from different vendors cannot interoperate directly=2C only FE= s = =3E =3Efrom the same vendors can work together=2E =3E =3E =3E =3ENow I recognized that many people including Joel=2C Robert and Avr= i = =3E =3Eetc identified this question already=2C =3E =3EHopfully we can start working on this question soon=2E =3E 2006 Message-Id: Date: Thu, 9 Nov 2006 09:03:13 +0800 From: "Ma.Huaiyuan 50376" Subject: =?gb2312?Q?=BB=D8=B8=B4:ForCES?= meeting minutes (draft) Comments: To: Robert Haas MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Content-disposition: inline Hi=2C *************************************************************************= ***************** This email and its attachments contain confidential information from HUA= WEI=2C which is intended only for the person or entity whose address is l= isted above=2E Any use of the information contained herein in any way (in= cluding=2C but not limited to=2C total or partial disclosure=2C reproduct= ion=2C or dissemination) by persons other than the intended recipient(s) = is prohibited=2E If you receive this e-mail in error=2C please notify the= sender by phone or em ail immediately and delete it! ************************************************************************= **************** ----- =D4=AD=D3=CA=BC=FE ----- =B7=A2=BC=FE=C8=CB=3A Robert Haas =3Crha=40zurich=2Eibm=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=CB=C4=2C =CA=AE=D2=BB=D4=C2 9=C8=D5=2C 2006 = =C9=CF=CE=E70=3A56 =D6=F7=CC=E2=3A ForCES meeting minutes (draft) =3E All=2C =3E Please find below the meeting minutes for yesterday meeting in San = =3E Diego=2ELet me know if you have comments/questions=2E =3E Regards=2C =3E -Robert =3E = =3E = =3E Meeting Minutes=3A =3E = =3E 1) WG status =26 Agenda Bash=2C Robert Haas =3E slides=3A http=3A//www3=2Eietf=2Eorg/proceedings/06nov/slides/forces-= 0=2Eppt =3E = =3E - Protocol and MIB drafts under AD review=2E Ross Callon to complete =3E reviews by year end=2E Avri to incorporate changes=2E =3E - Model draft will have another LC once changes are incorporated=2E =3E - TCP-based TML ready for LC=2E =3E - TML Service Primitives draft ready LC once changes are incorporated= =2E =3E = =3E = =3E 2) A Framework Adapting Traditional Router to ForCES-based = =3E Architecture=2EHuaiyuan=2C Ma (Michael) =3E http=3A//www=2Eietf=2Eorg/internet-drafts/draft-ma-forces-proxy- =3E framework-00=2Etxt =3E slides=3A http=3A//www3=2Eietf=2Eorg/proceedings/06nov/slides/forces-= 2=2Eppt =3E = =3E The draft addresses two main issues to allow the evolution from =3E traditional routers towards ForCES-compatible routers=3A =3E a) Ensuring interoperability between FEs with different forwarding =3E models by introducing an FE Adapter=2E Comment from Joel=3A the fact = that =3E different forwarding models are used by the FEs is irrelevant=3A it = =3E is the =3E Fi interface that is out of scope of the standardization effort = =3E and for =3E which an FE Adapter could be needed=2E This would allows FEs from =3E different vendors to interoperate by interpreting the metadata = =3E that is =3E passed along with the packet=2E =3E b) Control of legacy FEs that do not support ForCES by using an FE =3E Proxy=2E Comment from Joel=3A The FE Proxy is not distinguishable fro= m = =3E an FE =3E from the ForCES-protocol perspective=2E =3E Comment by Robert=3A the draft shows how FE Proxies can be used in a =3E traditional router to make it ForCES compatible=2C while remaining =3E transparent to the ForCES protocol=2E Moreover=2C as the Fi interface= = =3E is not =3E subject to standardization=2C the FE Adapter is out of the scope = =3E of the =3E standardization=2E Anyway=2C we have to solve this problem sooner or later=2C without defini= ng this meta-data properly=2C FEs from different vendors cannot interoperate directly=2C only FEs from = the same vendors can work together=2E = Now I recognized that many people including Joel=2C Robert and Avri etc i= dentified this question already=2C = Hopfully we can start working on this question soon=2E =3E = =3E = =3E 3) ForCES Model=2C Joel Halpern =3E http=3A//www=2Eietf=2Eorg/internet-drafts/draft-ietf-forces-model-07=2E= txt =3E (no slides available) =3E Credits also to Ellen for editing=2E The last call uncovered =3E inconsistencies in the terminology=3A clash between XML attributes = =3E and LFB =3E attributes=2C clash between XML elements and LFB elements (encompasse= s =3E capabilities=2C capacities=2C attributes)=2E More comments are welcom= e=2E =3E = =3E = =3E 4) TML Service Primitives (Weiming Wang) presented by Robert Haas=2E =3E http=3A//www=2Eietf=2Eorg/internet-drafts/draft-ietf-forces-tcptml-04= =2Etxt =3E slides=3A http=3A//www3=2Eietf=2Eorg/proceedings/06nov/slides/forces-= 1=2Eppt =3E = =3E Discussion of the open issues=3A =3E a) TML errors and congestion alerts=2C and possibly stats=2E =3E Comment by Joel=3A Should first determine if such information should = be =3E reflected in an LFB or if it is only useful locally (between the = =3E TML and =3E PL)=2E For instance=2C taking the example of congestion notification=2C= this =3E can be done as follows=3A =3E - the TML locally notifies the PL about congestion it observes on the= =3E communication channel=2C and that=27s all=2C or=3A =3E - in addition=2C the TML changes an attribute in an LFB that in turn =3E generates a ForCES event notification from FE to CE=2E But is it = =3E wise to =3E generate more traffic when congestion has been detected =3F The TML = =3E shouldpreferably deal with congestion itself directly=2E =3E Comment by Robert=3A Authors of the draft should examine each of thes= e =3E information and determine if they are of local interest (hence no nee= d =3E to be reflected in an LFB) or have FE-CE interest (hence update = =3E the LFBs)=2E I agree with Joel strongly=2E because it is kind of self-contradiction st= uff=2E When this congestion happens=2C there is no way to send this kind of message from the congested FE to CE=2C= that is=2C this kind of notification cannot be delivered to the CE until the congestion disappers=2C so trying= to make this kind of notification work = in this way does not make any sense=2E =3E b) Statement from protocol draft that =22PL must be portable across = =3E TMLs=22=2EComment by Joel=3A this statement is a mistake=2E This come= s = =3E from a =3E confusion between definition vs implementation=2E Standardization of =3E TML-to-PL-interface is out of scope=2E Avri seconds Joel=27s comment=2E= I agree with that=2C our definition should be very general=2E =3E = =3E = =3E = =3E -- = =3E Dr=2E Robert R=2E Haas =3E IBM Zurich Research Laboratory =3E S=3Fumerstrasse 4 =3E CH-8803 R=A8=B9schlikon/Switzerland =3E phone +41-44-724-8698 fax +41-44-724-8578 = =3E http=3A//www=2Ezurich=2Eibm=2Ecom/=7Erha 2006 Message-Id: Date: Thu, 9 Nov 2006 00:10:09 -0500 From: "Joel M. Halpern" Subject: Re: =?gb2312?Q?=BB=D8=B8=B4:Re:_=BB=D8=B8=B4:ForCES?= meeting minutes (draft) Comments: To: "Ma.Huaiyuan 50376" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed In a ForCES based router, the ingress policies would be applied on the board that first receives the packets. It knows what port the packets arrive on. I would recommend (but the standard can not mandate) that one use separate ethernet ports to interconnect the FEs, distinct from the ports used to send and receive external traffic. But that is an implementation choice. Yours, Joel M. Halpern At 09:15 PM 11/8/2006, you wrote: >For Example, in traditional router, many policies are based on >source port in forwarding process. >for instance, to filter some unwanted traffic based on the source port, >and source port information could be different for each packet, and >destination address in the header of packets >has no relationship with the source port, given that the source port >is carried in meta-data, I do not know how >to reconstruct this info again when it is needed later. > > >Kind Regards, > >Michael 2006 Message-Id: Date: Wed, 8 Nov 2006 21:34:48 +0100 From: "tom.petch" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Joel M. Halpern" Sent: Wednesday, November 08, 2006 6:38 PM Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt > My inclination is a hybrid of your suggestions. > We should say that LFB Arrays are used to represent tabular data > structures, including things that are frequently called arrays or tables. > Whenever we refer to the LFB structure in the abstract, we should > refer to it as an array. > And we should try to use array as much as possible the rest of the time. > Yes, sounds good to me Tom Petch > Yours, > Joel > > At 10:04 AM 11/8/2006, tom.petch wrote: > >----- Original Message ----- > >From: "Joel M. Halpern" > >Sent: Monday, November 06, 2006 6:24 PM > >Subject: Re: terminology wa Re: XML basics Re: LC model draft > >draft-ietf-forces-model-07.txt > > > > > > > We should certainly be consistent about what we call the things. > > > Since I find the term subscript very useful, I tend to think of arrays. > > > Part of the reason that I like subscript is that it is clearly > > > distinct from the content key. In contrast, the table index is not > > > so clearly different. > > > >Ok so how about replacing all uses of table with array? a quick > >browse of -model > >shows array in use about 200 times and table 45 including such phrases as > >'array index of a table' :-) > > > >Trouble is,.many uses of table are as part of a well known phrase > >such as 'dscp > >mapping table' 'forwarding table' ' frequency table' so I suspect that won't > >work. Perhaps the best thing would be to state that no semantic difference is > >meant between the use of table (widely used in s3) and array (widely > >used in s4) > > > >Tom Petch > > > > > > > > Yours, > > > Joel > > > > > > At 11:30 AM 11/6/2006, Jamal Hadi Salim wrote: > > > > > My 'arrays' are usually 'tables' with rows and columns which > > > > works at least when > > > > > they are 2-D; > > > > > > > >Table is a better name. 2006 Message-Id: Date: Wed, 8 Nov 2006 20:22:27 -0500 From: "Joel M. Halpern" Subject: Re: =?gb2312?Q?=BB=D8=B8=B4:ForCES?= meeting minutes (draft) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed There are two issues here: 1) We have all agreed that it is desirable to be able to pass meta-data between FEs. This is the Fi interface. 2) We can build solutions with FEs from different vendors without passing meta-data. We do not get teh degree of scaling we would like, but it does still work. Assertions that it does not work will prevent folks from utilizing the protocol, and therefore prevent us from ever getting to work on Fi. (I am very confident that doing this without passing meta-data around is useful because I have over the years built several sets of solutions that were distributed routers without meta data passing.) As a background, this issue of inter-FE communication within an NE does not depend upon nor is it driven by the integration of legacy routers. It is desirable in and of itself. Once it is done, the legacy router integration techniques will be able to make use of it, likely with no further change to the protocol mechanisms. Yours, Joel M. Halpern At 08:03 PM 11/8/2006, Ma.Huaiyuan 50376 wrote: >Anyway, we have to solve this problem sooner or later, without >defining this meta-data properly, >FEs from different vendors cannot interoperate directly, only FEs >from the same vendors can work together. > >Now I recognized that many people including Joel, Robert and Avri >etc identified this question already, >Hopfully we can start working on this question soon. 2006 Message-Id: Date: Wed, 8 Nov 2006 17:56:04 +0100 From: Robert Haas Subject: ForCES meeting minutes (draft) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable All, Please find below the meeting minutes for yesterday meeting in San Diego. Let me know if you have comments/questions. Regards, -Robert Meeting Minutes: 1) WG status & Agenda Bash, Robert Haas slides: http://www3.ietf.org/proceedings/06nov/slides/forces-0.ppt - Protocol and MIB drafts under AD review. Ross Callon to complete reviews by year end. Avri to incorporate changes. - Model draft will have another LC once changes are incorporated. - TCP-based TML ready for LC. - TML Service Primitives draft ready LC once changes are incorporated. 2) A Framework Adapting Traditional Router to ForCES-based Architecture. Huaiyuan, Ma (Michael) http://www.ietf.org/internet-drafts/draft-ma-forces-proxy-framework-00.tx= t slides: http://www3.ietf.org/proceedings/06nov/slides/forces-2.ppt The draft addresses two main issues to allow the evolution from traditional routers towards ForCES-compatible routers: a) Ensuring interoperability between FEs with different forwarding models by introducing an FE Adapter. Comment from Joel: the fact that different forwarding models are used by the FEs is irrelevant: it is the Fi interface that is out of scope of the standardization effort and for which an FE Adapter could be needed. This would allows FEs from different vendors to interoperate by interpreting the metadata that is passed along with the packet. b) Control of legacy FEs that do not support ForCES by using an FE Proxy. Comment from Joel: The FE Proxy is not distinguishable from an FE from the ForCES-protocol perspective. Comment by Robert: the draft shows how FE Proxies can be used in a traditional router to make it ForCES compatible, while remaining transparent to the ForCES protocol. Moreover, as the Fi interface is not subject to standardization, the FE Adapter is out of the scope of the standardization. 3) ForCES Model, Joel Halpern http://www.ietf.org/internet-drafts/draft-ietf-forces-model-07.txt (no slides available) Credits also to Ellen for editing. The last call uncovered inconsistencies in the terminology: clash between XML attributes and LFB attributes, clash between XML elements and LFB elements (encompasses capabilities, capacities, attributes). More comments are welcome. 4) TML Service Primitives (Weiming Wang) presented by Robert Haas. http://www.ietf.org/internet-drafts/draft-ietf-forces-tcptml-04.txt slides: http://www3.ietf.org/proceedings/06nov/slides/forces-1.ppt Discussion of the open issues: a) TML errors and congestion alerts, and possibly stats. Comment by Joel: Should first determine if such information should be reflected in an LFB or if it is only useful locally (between the TML and PL). For instance, taking the example of congestion notification, this can be done as follows: - the TML locally notifies the PL about congestion it observes on the communication channel, and that's all, or: - in addition, the TML changes an attribute in an LFB that in turn generates a ForCES event notification from FE to CE. But is it wise to generate more traffic when congestion has been detected ? The TML should preferably deal with congestion itself directly. Comment by Robert: Authors of the draft should examine each of these information and determine if they are of local interest (hence no need to be reflected in an LFB) or have FE-CE interest (hence update the LFBs). b) Statement from protocol draft that "PL must be portable across TMLs". Comment by Joel: this statement is a mistake. This comes from a confusion between definition vs implementation. Standardization of TML-to-PL-interface is out of scope. Avri seconds Joel's comment. --=20 Dr. Robert R. Haas IBM Zurich Research Laboratory S=E4umerstrasse 4 CH-8803 R=FCschlikon/Switzerland phone +41-44-724-8698 fax +41-44-724-8578 http://www.zurich.ibm.com/~rh= a 2006 Message-Id: Date: Wed, 8 Nov 2006 16:49:05 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: section 3.2.1/2 LFB outputs/inputs Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Wed, 2006-08-11 at 15:52 -0500, Joel M. Halpern wrote: > If you can give me a bit more explanation of the hub-and-spoke case, > I'll try to work it in. I could draw it, but hope this would suffice to describe it: The Hub is a special LFB which deals with metadata +/- content (typically metadata only) to decide routing of packets to the next(hop) LFB in a topology. Typically setup is: Two uni-directional spokes connect this LFB with every other LFB. The src vertex maps to the LFB output and the LFB input maps to the dst vertex[1] The CE is capable of taking a linearly graphed policy description and mapping it to this layout. A few ASICs i know use this scheme. > And 3.2, with the better description of what LFBs are, is a good > place to re-iterate that they are a descriptive construct, not an > implementation construct. Ok, I have update #98 to state the above. cheers, jamal [1]Probably more detail than needed : The connected to LFB may decide to steal the packet or even inject a new packet. The hub needs to know of these details (via metadata or otherwise) so it can terminate the execution. 2006 Message-Id: Date: Wed, 8 Nov 2006 16:04:10 +0100 From: "tom.petch" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Joel M. Halpern" Sent: Monday, November 06, 2006 6:24 PM Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt > We should certainly be consistent about what we call the things. > Since I find the term subscript very useful, I tend to think of arrays. > Part of the reason that I like subscript is that it is clearly > distinct from the content key. In contrast, the table index is not > so clearly different. Ok so how about replacing all uses of table with array? a quick browse of -model shows array in use about 200 times and table 45 including such phrases as 'array index of a table' :-) Trouble is,.many uses of table are as part of a well known phrase such as 'dscp mapping table' 'forwarding table' ' frequency table' so I suspect that won't work. Perhaps the best thing would be to state that no semantic difference is meant between the use of table (widely used in s3) and array (widely used in s4) Tom Petch > > Yours, > Joel > > At 11:30 AM 11/6/2006, Jamal Hadi Salim wrote: > > > My 'arrays' are usually 'tables' with rows and columns which > > works at least when > > > they are 2-D; > > > >Table is a better name. 2006 Message-Id: Date: Wed, 8 Nov 2006 15:52:11 -0500 From: "Joel M. Halpern" Subject: Re: section 3.2.1/2 LFB outputs/inputs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed If you can give me a bit more explanation of the hub-and-spoke case, I'll try to work it in. And 3.2, with the better description of what LFBs are, is a good place to re-iterate that they are a descriptive construct, not an implementation construct. Yours, Joel At 03:34 PM 11/8/2006, Jamal Hadi Salim wrote: >On Wed, 2006-08-11 at 13:23 -0500, Joel M. Halpern wrote: > > I believe we need to have the redirector LFB. Whether we have one > > class that can do both meta-data based redirection and content based > > redirection, or two (or three) classes is not a concern. But we need > > to have that ability. I realize that using such an LFB means that > > someone reading the graph can't tell where the packets will go > > without the table in the redirector. But there are way too many > > cases where we need it. (The simplest example is where one places a > > DSCP on a packet early in the processing, but branches to different > > queues much later in the processing.) > >We need to have some redirection information modelling representation. >I am uncertain that it needs to be an LFB. Regardless, my worry (based >on experience) is that this document will be used as religious scripture >(as it should be) where the danger is people making literal >translation. >Somewhere it needs to be spelt out, strongly, that the redirection >activity could reside in the src LFB, a special LFB (of which a >redirector as described in this doc is one _example_) or in the >destination LFB. > > > I am happy to add brief descriptions of other ways of doing the > > interconnection, although I had thought that the two extreme examples > > covered things pretty well already. > >The redirector doesnt cover the Hubnspokes approach i spoke of early. >In-fact it is a speacial case of the hub. > > > As a separate matter, if we need to strengthen the wording elsewhere > > about the fact that LFBs are abstractions and not implementations, I > > am happy to do so. Suggestions on how to strengthen the existing > > wording would be appreciated. This is a very important point, and I > > think some folks have already missed it. > >Perhaps section 3.2 right at the begining (and combined with >http://www.mip4.org/issues/tracker/forces/issue98 )? > > >cheers, >jamal 2006 Message-Id: Date: Wed, 8 Nov 2006 15:49:46 +0100 From: "tom.petch" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Comments: To: "Deleganes, Ellen M" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Tom Petch ----- Original Message ----- From: "Deleganes, Ellen M" Sent: Monday, November 06, 2006 8:14 PM Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt > I agree that the changes are editorial as opposed to technical. This > discussion is mostly about clarifying terminology, not changing the > basic definition of the items under discussion. yes very much so > > >> 'element' in -protocol could be 'protocol element' which, for me at least, is > >> markedly different to (data) element in XML > > >You lost me a little here. Why should the protocol care? It just carries > >the modelled data. > > I think what Tom is trying to distinguish is a ForCES element from the XML > use of the term "element". It seems that XML has a specific meaning for the > word "element" that doesn't match the ForCES usage. > Again, very much so. To take a line from -model, attribute is an XML element while elementID is an XML attribute; that is what I would most like to amend, get away from attribute as used by ForCES and, if possible, element as well. As I said, I like 'capability' ditto 'configuration' 'customisation' 'potentiality' 'property' .... And as Joel said, it would be helpful to have an umbrella term for what is currently either (the XML element) or in ForCES. In general, most of what can be done in XML can be done by using XML attributes of XML elements or by using XML elements per se. So a second point is, I am unclear in -model whether the intention is that all pieces of data that a CE can read or write are expressed as XML elements or are some of them XML attributes (of XML elements). This has ramifications for identifiers and namespaces and -protocol. > > Regards, > Ellen > > -----Original Message----- > From: Forwarding and Control Element Separation > [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim > Sent: Monday, November 06, 2006 8:30 AM > To: FORCES@PEACH.EASE.LSOFT.COM > Subject: Re: terminology wa Re: XML basics Re: LC model draft > draft-ietf-forces-model-07.txt > > On Sun, 2006-05-11 at 18:39 +0100, tom.petch wrote: > > I do like the terms in s3.1 of -model; they - capability and > > constraint(capacity) - seem the most natural to me. I have used the > term > > 'function' in my e-mails because that is not in the I-Ds and so seemed > neutral > > in any discussion, and because it is for me what it is we are talking > about, as > > much as capability. The two could be combined; functional capability > and > > functional constraints. > >=20 > > I dont see a problem with the above description. S3 does go into pains > of describing the difference between the two already ("I can do IPV4 > forwarding" being a capability and "I can handle 100K /32 routes" being > a constraint.=20 > Referring to the constraint as a capacity maybe misconstrued as to be a > numeric constraint (as in IPV4 forwarding table capacity) > > > 'element' in -protocol could be 'protocol element' which, for me at > least, > is > > markedly different to (data) element in XML > > You lost me a little here. Why should the protocol care? It just carries > the modelled data.=20 > There may be a need to perhaps mark a clear distinction between the data > vs Information model mentioned in passing in the intro. The draft tries > to be both. > The leggo that constructs the model aka "element" or "structure" are > more part of a data model approach whereas the capability/constraint > constructs are more of an information model approach, no? > > > My 'arrays' are usually 'tables' with rows and columns which works at > least when > > they are 2-D;=20 > > Table is a better name. > > > and I allow for atomic elements or structures in the rows. (I > > sense a C language background to the terminogy of ForCES whereas I am > more > > mathematics, ASN.1 and SNMP). > >=20 > > You are right, there is a C-like assumption in the data modelling. That > approach is suited to an implementer - isnt that what we want? > > Joel, re: protocol change - you sound very concerned:=20 > IMO, we have always had the constraint that the protocol is dependent on > the model. AFAICS, the changes are editorial not technical, no? i.e it > is not a big deal. > > cheers, > jamal 2006 Message-Id: Date: Wed, 8 Nov 2006 15:40:21 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: ForCES meeting minutes (draft) Comments: To: Robert Haas Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Wed, 2006-08-11 at 17:56 +0100, Robert Haas wrote: > All, > Please find below the meeting minutes for yesterday meeting in San Diego. > Let me know if you have comments/questions. BTW, I did join the jabber session and was hoping to ask questions - but nobody was there. The audio reception was great. My intent of joining jabber was to pose the question on the SCTP TML again before i sent a new draft out. At the last meeting the question posed was: http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0607&L=forces&T=0&P=1114 I received one response from a _usual suspect_ at: http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0607&L=forces&T=0&P=1209 If there was no disagreement i will submit the next iteration as a WG draft. cheers, jamal 2006 Message-Id: Date: Wed, 8 Nov 2006 15:34:57 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: section 3.2.1/2 LFB outputs/inputs Comments: To: "Joel M. Halpern" Comments: cc: Ellen M Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Wed, 2006-08-11 at 13:23 -0500, Joel M. Halpern wrote: > I believe we need to have the redirector LFB. Whether we have one > class that can do both meta-data based redirection and content based > redirection, or two (or three) classes is not a concern. But we need > to have that ability. I realize that using such an LFB means that > someone reading the graph can't tell where the packets will go > without the table in the redirector. But there are way too many > cases where we need it. (The simplest example is where one places a > DSCP on a packet early in the processing, but branches to different > queues much later in the processing.) We need to have some redirection information modelling representation. I am uncertain that it needs to be an LFB. Regardless, my worry (based on experience) is that this document will be used as religious scripture (as it should be) where the danger is people making literal translation. Somewhere it needs to be spelt out, strongly, that the redirection activity could reside in the src LFB, a special LFB (of which a redirector as described in this doc is one _example_) or in the destination LFB. > I am happy to add brief descriptions of other ways of doing the > interconnection, although I had thought that the two extreme examples > covered things pretty well already. The redirector doesnt cover the Hubnspokes approach i spoke of early. In-fact it is a speacial case of the hub. > As a separate matter, if we need to strengthen the wording elsewhere > about the fact that LFBs are abstractions and not implementations, I > am happy to do so. Suggestions on how to strengthen the existing > wording would be appreciated. This is a very important point, and I > think some folks have already missed it. Perhaps section 3.2 right at the begining (and combined with http://www.mip4.org/issues/tracker/forces/issue98 )? cheers, jamal 2006 Message-Id: Date: Wed, 8 Nov 2006 13:23:59 -0500 From: "Joel M. Halpern" Subject: Re: section 3.2.1/2 LFB outputs/inputs Comments: To: hadi@znyx.com, Ellen M Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I believe we need to have the redirector LFB. Whether we have one class that can do both meta-data based redirection and content based redirection, or two (or three) classes is not a concern. But we need to have that ability. I realize that using such an LFB means that someone reading the graph can't tell where the packets will go without the table in the redirector. But there are way too many cases where we need it. (The simplest example is where one places a DSCP on a packet early in the processing, but branches to different queues much later in the processing.) I am happy to add brief descriptions of other ways of doing the interconnection, although I had thought that the two extreme examples covered things pretty well already. As a separate matter, if we need to strengthen the wording elsewhere about the fact that LFBs are abstractions and not implementations, I am happy to do so. Suggestions on how to strengthen the existing wording would be appreciated. This is a very important point, and I think some folks have already missed it. Yours, Joel At 01:06 PM 11/8/2006, Jamal Hadi Salim wrote: >I am not adding this to the tracker yet. Will do when we discuss and >reach some consensus. > >I havent looked at this text for a while - but last i looked at it i had >some strong reservations with its use. It still left the same after >taste in my mouth this time as well. > >I am making the strong assumption that this text will be used by many an >implementer to provide the information model or spec[1]. It has been >argued in the past that the information model is merely meant as a >guideline - so was RFC2401 and to this date i am met with many >arguements of "but thats what the RFC said". So that arguement is not >strong. >Enough of that rant, heres where i am coming from: > >Inputs and outputs are good to have because they provide for a >consistent way to info-model the graphing - so no argument there. The >text however, still has some strong subliminal implementation >suggestions of the existence of a redirector LFB (suggested on page 15 >and other places) whose purpose merely is to bridge different LFBs. This >is where i have argued in the past, it borders on implementation >details. As an example, I could interconnect >LFBs in a star topology with a specialized LFB doing the routing. >I have seen many a ASIC with this approach. I am certain there are other >ways which i havent come across. > >If: > a) i) we got rid of the redirector LFB as a necessary component > or > ii) add the other ways of doing it such as the hubnspoke scheme i >just described above and perhaps others. > b) we add some strong language to mean all this is not necessarily the >way to implement. > >Then my concern will go down. > >Thoughts? > >cheers, >jamal > >[1] Infact section 4 para 2 states: ".. the model will serve as an > important reference for the design and development of the CEs > (software) and FEs (mostly the software part). It will also serve > as a design input when specifying the ForCES protocol elements for > CE-FE communication." 2006 Message-Id: Date: Wed, 8 Nov 2006 13:08:02 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: tracker broken? Comments: cc: Avri Doria Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit I have been adding issues to the tracker and adding the list as a nosy listener but havent seen any echoes on the list. Is it design intent or broken? I wonder if the folks i have been adding to be copied even got the message. cheers, jamal 2006 Message-Id: Date: Wed, 8 Nov 2006 13:06:20 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: section 3.2.1/2 LFB outputs/inputs Comments: To: Ellen M , "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit I am not adding this to the tracker yet. Will do when we discuss and reach some consensus. I havent looked at this text for a while - but last i looked at it i had some strong reservations with its use. It still left the same after taste in my mouth this time as well. I am making the strong assumption that this text will be used by many an implementer to provide the information model or spec[1]. It has been argued in the past that the information model is merely meant as a guideline - so was RFC2401 and to this date i am met with many arguements of "but thats what the RFC said". So that arguement is not strong. Enough of that rant, heres where i am coming from: Inputs and outputs are good to have because they provide for a consistent way to info-model the graphing - so no argument there. The text however, still has some strong subliminal implementation suggestions of the existence of a redirector LFB (suggested on page 15 and other places) whose purpose merely is to bridge different LFBs. This is where i have argued in the past, it borders on implementation details. As an example, I could interconnect LFBs in a star topology with a specialized LFB doing the routing. I have seen many a ASIC with this approach. I am certain there are other ways which i havent come across. If: a) i) we got rid of the redirector LFB as a necessary component or ii) add the other ways of doing it such as the hubnspoke scheme i just described above and perhaps others. b) we add some strong language to mean all this is not necessarily the way to implement. Then my concern will go down. Thoughts? cheers, jamal [1] Infact section 4 para 2 states: ".. the model will serve as an important reference for the design and development of the CEs (software) and FEs (mostly the software part). It will also serve as a design input when specifying the ForCES protocol elements for CE-FE communication." 2006 Message-Id: Date: Wed, 8 Nov 2006 12:40:42 -0500 From: "Joel M. Halpern" Subject: Re: [issue97] 3.1. FE Capability Model and State Model Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I wish we had been more explicit in the first place. I know there was something specific we were thinking of. (I think that the reason we were not more explicit was to avoid insulting other people's work.) I'll need to reread this and see what I can remember / deduce. Yours, Joel At 11:41 AM 11/8/2006, Jamal Hadi Salim wrote: >New submission from Jamal Hadi Salim : > >3.1. FE Capability Model and State Model > > >" While one could try and build an object model to fully represent the > FE capabilities, other efforts found this to be a significant > undertaking." > >It would be useful to have a reference to something that found this to >be a "significant undertaking". Further below there is a talk about two >PIBs which seem to involve a solution to the "significant understaking". >If they are also the source of this knowledge then text needs to be >representative > >---------- >category: Editorial >draft: draft-ietf-forces-model >messages: 475 >nosy: FORCES, ellen, jamal, joel >priority: May fix >status: No discussion >title: 3.1. FE Capability Model and State Model > >___________________________________________________ >Forces issue tracker > >___________________________________________________ 2006 Message-Id: Date: Wed, 8 Nov 2006 12:38:24 -0500 From: "Joel M. Halpern" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed My inclination is a hybrid of your suggestions. We should say that LFB Arrays are used to represent tabular data structures, including things that are frequently called arrays or tables. Whenever we refer to the LFB structure in the abstract, we should refer to it as an array. And we should try to use array as much as possible the rest of the time. Yours, Joel At 10:04 AM 11/8/2006, tom.petch wrote: >----- Original Message ----- >From: "Joel M. Halpern" >Sent: Monday, November 06, 2006 6:24 PM >Subject: Re: terminology wa Re: XML basics Re: LC model draft >draft-ietf-forces-model-07.txt > > > > We should certainly be consistent about what we call the things. > > Since I find the term subscript very useful, I tend to think of arrays. > > Part of the reason that I like subscript is that it is clearly > > distinct from the content key. In contrast, the table index is not > > so clearly different. > >Ok so how about replacing all uses of table with array? a quick >browse of -model >shows array in use about 200 times and table 45 including such phrases as >'array index of a table' :-) > >Trouble is,.many uses of table are as part of a well known phrase >such as 'dscp >mapping table' 'forwarding table' ' frequency table' so I suspect that won't >work. Perhaps the best thing would be to state that no semantic difference is >meant between the use of table (widely used in s3) and array (widely >used in s4) > >Tom Petch > > > > > Yours, > > Joel > > > > At 11:30 AM 11/6/2006, Jamal Hadi Salim wrote: > > > > My 'arrays' are usually 'tables' with rows and columns which > > > works at least when > > > > they are 2-D; > > > > > >Table is a better name. 2006 Message-Id: Date: Wed, 8 Nov 2006 12:36:29 -0500 From: "Joel M. Halpern" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed All pieces of information that the ForCES protocol can manipulate are described in LFB Class definitions using the LFB components defined in the schema (currently called capability, attribute, and event, along with element properties.) Given the existence of documentation elements, there is no reason to use arbitrary XML in the definitions, and the schema does not permit arbitrary elements. (This may suggest to some a compatibility issue. The idea is that if the schema is ever extended then old definitions will be compatible with the new schema, but new definitions will not be compatible with the old schema. Given the need for semantic knowledge for anything making uses of LFB class definitions, this does not seem to be a problem.) Yours, Joel M. Halpern At 09:49 AM 11/8/2006, tom.petch wrote: >In general, most of what can be done in XML can be done by using XML >attributes >of XML elements or by using XML elements per se. So a second point is, I am >unclear in -model whether the intention is that all pieces of data >that a CE can >read or write are expressed as XML elements or are some of them XML attributes >(of XML elements). This has ramifications for identifiers and namespaces >and -protocol. 2006 Message-Id: Date: Wed, 8 Nov 2006 10:15:12 -0800 From: Avri Doria Subject: Re: tracker broken? Comments: To: Jamal Hadi Salim Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit hi, On 8 nov 2006, at 10.08, Jamal Hadi Salim wrote: > > I have been adding issues to the tracker and adding the list as a nosy > listener but havent seen any echoes on the list. Is it design > intent or > broken? I don't know will check. > I wonder if the folks i have been adding to be copied even got > the message. since I was one of those who should have been getting ping'ed and didn't, yeah something does seem amiss. but i am awake again and will follow up - both on the tracker and the issues in the tracker for the protocol. a. 2006 Message-Id: Date: Wed, 8 Nov 2006 00:33:25 +0800 From: "Wang,Weiming" Subject: Fw: TML Service Primitive Update MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGVoZSwganVzdCBsZXQgZ3V5cyBzZWUgd2hhdCBvdXIgZGVhciBJTlRFUk5FVCBzb21ldGltZXMg aXMhIDopDQpXZWltaW5nDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkph bWFsIEhhZGkgU2FsaW0iIDxoYWRpQHpueXguY29tPg0KVG86ICJXYW5nLFdlaW1pbmciIDx3bXdh bmdAbWFpbC56amdzdS5lZHUuY24+DQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA4LCAyMDA2 IDEyOjE1IEFNDQpTdWJqZWN0OiBSZTogVE1MIFNlcnZpY2UgUHJpbWl0aXZlIFVwZGF0ZQ0KDQoN Cj4gV2VpbWluZywNCj4gDQo+IFRoaXMgaXMgdmVyeSB2ZXJ5IHN0cmFuZ2UuIE1heWJlIGkgc2hv dWxkIHN0b3AgdXNpbmcgbXkgY29tcGFueXMgZW1haWwgDQo+IHNlcnZpY2VzLiBNeSB2ZXJzaW9u IG9mIGV2ZW50cyBiZWxvdzoNCj4gDQo+IE9uIFdlZCwgMjAwNi0wOC0xMSBhdCAwMDowNiArMDgw MCwgV2FuZyxXZWltaW5nIHdyb3RlOg0KPiA+IEphbWFsLA0KPiA+IA0KPiA+IEkgdGhpbmsgd2Ug aGF2ZSByZWFsbHkgZ290IHByb2JsZW1zIHdpdGggdGhlIGVtYWlsLiBJIGNhbiBkZXNjcmliZSAN Cj4gPiB0aGUgd2hvbGUgcHJvY2VzcyBhcyBoZXJlOg0KPiA+IDEuIFlvdSBhc2tlZCB0byBjaGFu Z2UgdGhlIHRleHQsIEkgaW1tZWRpYXRlbHkgcmVwbHkgdGhhdCdzIG9rLiANCj4gDQo+IERpZCBu b3QgcmVjZWl2ZSB0aGlzIGVtYWlsLiANCj4gDQo+ID4gMi4gWW91IHNlbnQgYW4gZW1haWwgYXNr IHdoeSBJIGRpZCBub3QgcmVwbHksIEkgcmVwbGllZCBhZ2Fpbi4gDQo+ID4gVGhpcyB3YXMgdGhl IGxhc3QgZW1haWwgSSByZWNlaXZlZCBmcm9tIHlvdS4NCj4gDQo+IERpZCBub3QgcmVjZWl2ZSB0 aGlzLg0KPiANCj4gPiAzLiBJIGFza2VkIHlvdSB0byByZXBseSBtZS4gV2l0aCBubyByZXBseS4N Cj4gDQo+IFJlZmVyIHRvICMyIGFib3ZlIDstPg0KPiANCj4gPiA0LiBJIHdhaXRlZCBmb3IgMyBk YXlzLCBhc2tlZCBhZ2Fpbi4gbm8gcmVwbHkuIEkgc2VudCBhIHNlcGNpYWwgDQo+ID4gZW1haWwg b25seSB0byB5b3UgKG90aGVycyBhcmUgYWxzbyBmb3IgQWxleCkgdG8gYXNrIGlmIGFueXRoaW5n IA0KPiA+IGhhcyBtYWRlIHlvdSB1bmhhcHB5LiBJZiBzbywgcGxzIGxldCBtZSBrbm93Lg0KPiAN Cj4gZGlkbnQgcmVjZWl2ZSBpdCBlaXRoZXIuDQo+IA0KPiA+IDUuIDItMyBkYXlzIGJlZm9yZSB0 aGUgbWVldGluZywgSSBhc2tlZCBhZ2FpbiBhYm91dCB0aGUgcHJvZ3Jlc3MsIA0KPiA+IGJ1dCBz dGlsbCB3aXRoIG5vIHJlcGx5LiANCj4gDQo+IGRpZG50IHJlY2VpdmUgaXQgZWl0aGVyLg0KPiAN Cj4gPiA2LiBUaGVyZWZvcmUsIEkgc2VudCB5b3UgZW1haWwgdG8gdGVsbCB0byB0YWtlIHRoZSBl ZGl0aW5nIGFuZCANCj4gPiB0byBpbmNvcnBhcmF0ZSB0aGUgY2hhbmdlcyB5b3UgcHJvcG9zZWQu IEJlY2F1c2UgaXQgd2FzIHZlcnkgDQo+ID4gaHVycnkgdGhhdCB0aW1lLCBJIGRpZCBub3QgdXNl IHhtbCB0byBkbyB0aGUgY2hhbmdlcy4gTm90ZSB0aGF0IA0KPiA+IHRoZXJlIGFyZSBzdGlsbCBt YW55IHRoaW5ncyBtaXNzZWQgaW4geW91ciB2ZXJzaW9uIG9mIHhtbC4gQWxsIA0KPiA+IGhlYWRp bmdzIGFib3V0IFNQIHBhcmFtZXRlcnMgYXJlIG1pc3NpbmcuDQo+IA0KPiBBbHNvIGRpZG50IHNl ZSB0aGlzIGVpdGhlci4NCj4gDQo+ID4gNy4gSSBwb3N0ZWQgdGhlIGNoYW5nZWQgdXBkYXRlIHRv IHRoZSBsaXN0Lg0KPiA+IA0KPiANCj4gVGhpcyBpIHNhdy4gQW5kIGkgY2FuIGRvdWJsZSBjaGVj ayB0aGlzIGluZm9ybWF0aW9uIGluIGNhc2UgaSBkb250DQo+IHJlY2VpdmUgZW1haWxzIGJlY2F1 c2UgaXQgaXMgYXJjaGl2ZWQgb24gdGhlIGludGVybmV0Lg0KPiANCj4gPiBUaGF0J3MgYWxsIHRo ZSBwcm9jZXNzLiANCj4gPiBCdXQgZG9uJ3Qgd29ycnkgdG9vIG11Y2ggdGhhdCB3ZSBzdGlsbCBh cmUgYWJsZSB0byBkbyBhbnl0aGluZyB0aGF0IHdlIA0KPiA+IGNhbiBkby4gSSdtIHJlYWxseSB2 ZXJ5IGdsYWQgdG8gc2VlIHRoYXQgaXQgd2FzIGp1c3QgYSBjb21tdW5pY2F0aW9uIA0KPiA+IHBy b2JsZW0gYW5kIHNlZSB3ZSBjYW4gd29yayB0b2dldGhlciBhZ2FpbjopDQo+ID4gDQo+IA0KPiBB IHZlcnkgYmFkIGNvbW11bmljYXRpb24gcHJvYmxlbS4gSSB0aG91Z2h0IHlvdSB3ZXJlIHRvbyBi dXN5IGFuZA0KPiB0aGVyZWZvcmUgd2VyZSBub3QgcmVzcG9uZGluZyB0byBtZS4NCj4gDQo+ID4g cGxzIHJlcGx5IHRvIG1lIGltbWVkaWF0ZWx5IHdoZW4geW91IGdldCB0aGUgZW1haWwuIFdlIHN0 aWxsIGhhdm4ndCANCj4gPiB2ZXJpZnkgdGhlIHBhdGggZnJvbSBteSBwbGFjZSB0byB5b3Vycy4N Cj4gPiANCj4gDQo+IFNvIGl0IHNlZW1zIHlvdSB3ZXJlIHJlY2VpdmluZyBteSBlbWFpbHMgYnV0 IGkgd2FzbnQgcmVjZWl2aW5nIHlvdXJzLg0KPiANCj4gSWYgeW91IGhhdmUgdGhlIG9yaWdpbmFs IGVtYWlscyBvciBoZWFkZXJzICh3aGljaCB3aWxsIGhhdmUgZGF0ZXMgcGxlYXNlDQo+IHNlbmQg dGhlbSB0byBtZSBhbmQgSSB3aWxsIGZvbGxvdyB1cCB3aXRoIG91ciBJVCkNCj4gDQo+IGNoZWVy cywNCj4gamFtYWwNCj4g 2006 Message-Id: Date: Wed, 8 Nov 2006 00:20:19 +0800 From: "Wang,Weiming" Subject: Re: TML Service Primitive Update Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 c2VlbXMgdGhlIGVtYWlsIGdvdCBsb3N0IGFnYWluOiggIA0Kbm8gcmVwbHksIGFuZCBubyBib3Vu Y2UgYWxzby4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiV2FuZyxXZWlt aW5nIiA8d213YW5nQG1haWwuempnc3UuZWR1LmNuPg0KVG86IDxoYWRpQHpueXguY29tPg0KU2Vu dDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwOCwgMjAwNiAxMjowNiBBTQ0KU3ViamVjdDogUmU6IFRN TCBTZXJ2aWNlIFByaW1pdGl2ZSBVcGRhdGUNCg0KDQo+IEphbWFsLA0KPiANCj4gSSB0aGluayB3 ZSBoYXZlIHJlYWxseSBnb3QgcHJvYmxlbXMgd2l0aCB0aGUgZW1haWwuIEkgY2FuIGRlc2NyaWJl IHRoZSB3aG9sZSBwcm9jZXNzIGFzIGhlcmU6DQo+IDEuIFlvdSBhc2tlZCB0byBjaGFuZ2UgdGhl IHRleHQsIEkgaW1tZWRpYXRlbHkgcmVwbHkgdGhhdCdzIG9rLiANCj4gMi4gWW91IHNlbnQgYW4g ZW1haWwgYXNrIHdoeSBJIGRpZCBub3QgcmVwbHksIEkgcmVwbGllZCBhZ2Fpbi4gVGhpcyB3YXMg dGhlIGxhc3QgZW1haWwgSSByZWNlaXZlZCBmcm9tIHlvdS4NCj4gMy4gSSBhc2tlZCB5b3UgdG8g cmVwbHkgbWUuIFdpdGggbm8gcmVwbHkuDQo+IDQuIEkgd2FpdGVkIGZvciAzIGRheXMsIGFza2Vk IGFnYWluLiBubyByZXBseS4gSSBzZW50IGEgc2VwY2lhbCBlbWFpbCBvbmx5IHRvIHlvdSAob3Ro ZXJzIGFyZSBhbHNvIGZvciBBbGV4KSB0byBhc2sgaWYgYW55dGhpbmcgaGFzIG1hZGUgeW91IHVu aGFwcHkuIElmIHNvLCBwbHMgbGV0IG1lIGtub3cuDQo+IDUuIDItMyBkYXlzIGJlZm9yZSB0aGUg bWVldGluZywgSSBhc2tlZCBhZ2FpbiBhYm91dCB0aGUgcHJvZ3Jlc3MsIGJ1dCBzdGlsbCB3aXRo IG5vIHJlcGx5LiANCj4gNi4gVGhlcmVmb3JlLCBJIHNlbnQgeW91IGVtYWlsIHRvIHRlbGwgdG8g dGFrZSB0aGUgZWRpdGluZyBhbmQgdG8gaW5jb3JwYXJhdGUgdGhlIGNoYW5nZXMgeW91IHByb3Bv c2VkLiBCZWNhdXNlIGl0IHdhcyB2ZXJ5IGh1cnJ5IHRoYXQgdGltZSwgSSBkaWQgbm90IHVzZSB4 bWwgdG8gZG8gdGhlIGNoYW5nZXMuIE5vdGUgdGhhdCB0aGVyZSBhcmUgc3RpbGwgbWFueSB0aGlu Z3MgbWlzc2VkIGluIHlvdXIgdmVyc2lvbiBvZiB4bWwuIEFsbCBoZWFkaW5ncyBhYm91dCBTUCBw YXJhbWV0ZXJzIGFyZSBtaXNzaW5nLg0KPiA3LiBJIHBvc3RlZCB0aGUgY2hhbmdlZCB1cGRhdGUg dG8gdGhlIGxpc3QuDQo+IA0KPiBUaGF0J3MgYWxsIHRoZSBwcm9jZXNzLiANCj4gQnV0IGRvbid0 IHdvcnJ5IHRvbyBtdWNoIHRoYXQgd2Ugc3RpbGwgYXJlIGFibGUgdG8gZG8gYW55dGhpbmcgdGhh dCB3ZSBjYW4gZG8uIEknbSByZWFsbHkgdmVyeSBnbGFkIHRvIHNlZSB0aGF0IGl0IHdhcyBqdXN0 IGEgY29tbXVuaWNhdGlvbiBwcm9ibGVtIGFuZCBzZWUgd2UgY2FuIHdvcmsgdG9nZXRoZXIgYWdh aW46KQ0KPiANCj4gcGxzIHJlcGx5IHRvIG1lIGltbWVkaWF0ZWx5IHdoZW4geW91IGdldCB0aGUg ZW1haWwuIFdlIHN0aWxsIGhhdm4ndCB2ZXJpZnkgdGhlIHBhdGggZnJvbSBteSBwbGFjZSB0byB5 b3Vycy4NCj4gDQo+IFRoYW5rcywNCj4gV2VpbWluZw0KPiANCj4gLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLSANCj4gRnJvbTogIkphbWFsIEhhZGkgU2FsaW0iIDxoYWRpQHpueXguY29tPg0K PiBUbzogIldhbmcsV2VpbWluZyIgPHdtd2FuZ0BtYWlsLnpqZ3N1LmVkdS5jbj4NCj4gQ2M6IDxG T1JDRVNAUEVBQ0guRUFTRS5MU09GVC5DT00+DQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA3 LCAyMDA2IDExOjUxIFBNDQo+IFN1YmplY3Q6IFJlOiBUTUwgU2VydmljZSBQcmltaXRpdmUgVXBk YXRlDQo+IA0KPiANCj4gPiBPbiBUdWUsIDIwMDYtMDctMTEgYXQgMjM6NDEgKzA4MDAsIFdhbmcs V2VpbWluZyB3cm90ZToNCj4gPiA+IEphbWFsLA0KPiA+ID4gDQo+ID4gPiBUaGFua3MgdmVyeSBt dWNoIGZvciB0aGUgcmVzcG9uc2UuIFBscyBzZWUgcmVwbHkgaW4gbGluZS4NCj4gPiA+IA0KPiA+ ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCj4gPiA+IEZyb206ICJKYW1hbCBIYWRp IFNhbGltIiA8aGFkaUB6bnl4LmNvbT4NCj4gPiA+IA0KPiA+ID4gPiBPbiBUdWUsIDIwMDYtMDct MTEgYXQgMjA6NDYgKzA4MDAsIFdhbmcsV2VpbWluZyB3cm90ZToNCj4gPiA+ID4gDQo+ID4gPiA+ ID4gSG93IGFib3V0IG90aGVycyAoYWxzbyB0aGUgYXV0aG9ycykgdGhvdWdodHM/DQo+ID4gPiA+ ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBJIGFncmVlIHdpdGggSm9lbCdzIHZpZXc7IGluIGFkZGl0 aW9uLCB0aGUgdGV4dCBzdGlsbCBoYXMgYSBsb3Qgb2YNCj4gPiA+IEphbWFsLCB0aGUgdGV4dCBh cyAiLi4uQSBGb3JDRVMgUEwgaW1wbGVtZW50YXRpb24gbXVzdCBiZSBwb3J0YWJsZSBhY3Jvc3Mu Li4iIA0KPiA+ID4gd2VyZSBvcmlnaW5hbGx5IGFkZGVkIGJ5IHlvdSA6KS4gKEknbSBub3Qgc3Vy ZSBpdCBpcyBhbHNvIGZvciB0aGUgcHJvdG9jb2wgDQo+ID4gPiBkb2N1bWVudCkuIFRoYXQncyB3 aHkgSSBhc2tlZCB5b3VyIHRob3VnaHQuIA0KPiA+ID4gDQo+ID4gDQo+ID4gSSB0aGluayB0aGF0 IGxhbmd1YWdlIGlzIHByb2JhYmx5IHRvbyBzdHJvbmcgYW5kIGl0IGlzIG5vdCB0b28gbGF0ZSB0 bw0KPiA+IGZpeCBpbiB0aGUgcHJvdG9jb2wgZHJhZnQgYXMgd2VsbC4NCj4gPiANCj4gPiA+ID4g Imhvd3RvIiB0eXBlIG9mICJmZWF0dXJlcyIuIA0KPiA+ID4gPiBJIHRoaW5rIHlvdSBzdGlsbCBo YXZlIHRvbyBtYW55ICJmZWF0dXJlcyIgdGhhdCBlbmQgdXANCj4gPiA+ID4gdHlpbmcgdGhpbmdz IHRvIHNvbWUgc3BlY2lmaWMgb3BlcmF0aW9ucyBpbiBzb21lIHNwZWNpZmljIE9TZXMuIA0KPiA+ ID4gPiBUaGlzIGRvY3VtZW50IHNob3VsZCBiZSBtYWtpbmcgcmVjb21tZW5kYXRpb25zLCBub3Qg c2F5ICJ0aGlzIGlzIGhvdyBpdA0KPiA+ID4gPiBpcyBkb25lIi4gSXQgbXVzdCBuZXZlciBiZSBp bXBvc2luZyB0aGUgaG93LXRvIGFjaGlldmUgdGhpbmdzLg0KPiA+ID4gPiBJIHNlbnQgeW91IHBy aXZhdGUgZW1haWxzIG9uIHRoZSB0b3BpYyBhbHJlYWR5IGJ1dCBkaWRudCByZWNlaXZlDQo+ID4g PiA+IHJlc3BvbnNlcyAtIHNvIGEgZmV3IG9mIHRoZSB0aG91Z2h0cyBhcmUgYmVsb3c6DQo+ID4g PiBKYW1hbCwgSSBoYXZlIHNlbnQgeW91IGEgYnVuY2ggb2YgZW1haWxzIHdpdGggdGhlIHJlc3Bv bnNlcyByZWdhcmRpbmcgdGhpcy4gDQo+ID4gPiBJIGRvbid0IGtub3cgaWYgc29tZXRoaW5nIHdy b25nIHdpdGggdGhlIGVtYWlscyBvciBub3QsIG9yIG90aGVyIHJlYXNvbnM/IA0KPiA+ID4gTWF5 YmUgd2UgaGF2ZSB0byB1c2UgdGhpcyBsaXN0IGFsc28gZm9yIHRoZSBwcml2YXRlIGNvbW0uOikN Cj4gPiA+IE1heSBiZSBJIG5lZWQgdG8gcmVzZW5kIHlvdSB0aGVzZSBlbWFpbHMuDQo+ID4gPiAN Cj4gPiANCj4gPiBQbGVhc2UgcmVzZW5kIHRoZW0gYmVjYXVzZSB0aGV5IG5ldmVyIGdvdCB0byBt ZSBhdCBhbGwuIEkgYW0gcmVhbGx5DQo+ID4gc29ycnkgdG8gYnJpbmcgdGhpcyB1cCBpbiB0aGUg bGlzdCBpbnN0ZWFkIG9mIHByaXZhdGVseS4gDQo+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiAxKSBJ biB0aGUgZXZlbnRzIHNlY3Rpb24gd2hlcmUgdGhlcmUgYXJlIHNvbWUgZXZlbnRzIHRoYXQgYXJl IGRlc2NyaWJlZA0KPiA+ID4gPiBzdWNoIGFzIGNvbmdlc3Rpb24gYWxlcnQsIERPUyBhbGVydCBl dGMuIEl0IGlzIG5vdCBkZWZpbmVkIGhvdyBzdWNoDQo+ID4gPiBZb3UgbWVhbiB3ZSBsYWNrIGRl dGFpbGVkIGRlZmluaXRpb24/IEknbSBhZnJhaWQgaXQgbWF5IHJlYWxseSBsZWFkIHRvIA0KPiA+ ID4gdG9vICdmZWF0dXJlZCcgc3BlY2lmaWMgb3BlcmF0aW9ucyx3aGljaCBpcyBhcyB5b3Ugb3Bw b3NlZCBpbiBhYm92ZSB0ZXh0Lg0KPiA+ID4gDQo+ID4gPiA+IHRoaW5ncyBnZXQgZGV0ZWN0ZWQg YnkgdGhlIFRNTC4gSXQgaXMgYWxzbyBub3QgbWVudGlvbmVkIGhvdyAgc3VjaA0KPiA+ID4gPiBp bmZvcm1hdGlvbiBpcyB1c2VkIGJ5IHRoZSBQTC4gQW4gZXhhbXBsZSBvZiB3aGF0IHdvdWxkIGJl IHVzZWZ1bCB3b3VsZA0KPiA+ID4gPiBoYXZlIGJlZW4gc29tZXRoaW5nIGxpa2U6DQo+ID4gPiA+ IA0KPiA+ID4gPiAiSW4gY2FzZXMgd2hlcmUgdGhlIE9TIGlzIGNhcGFibGUgb2YgZGV0ZWN0aW5n IEVDTiAoRWFybHkvZXhwbGljaXQNCj4gPiA+ID4gY29uZ2VzdGlvbiBub3RpZmljYXRpb24pIHdo ZXJlIHRoZSB1bmRlcmx5aW5nIElQIHByb3RvY29sIGlzIGNhcGFibGUgb2YNCj4gPiA+ID4gb2Yg cGFzc2luZyBpbmZvcm1hdGlvbiB0byB0aGUgYXBwbGljYXRpb24sIHRoZW4gdGhlIFRNTCBjb3Vs ZCBwYXNzIHN1Y2gNCj4gPiA+ID4gaW5mb3JtYXRpb24gdG8gdGhlIFBMLiBUaGUgUEwgY291bGQg dXNlIHRoaXMgaW5mb3JtYXRpb24gZm9yIGV4YW1wbGUgdG8NCj4gPiA+ID4gYWRqdXN0IGl0cyBz ZW5kaW5nIHJhdGVzIG9yIGluY3JlYXNlIG9yIHJlZHVjZSB0aGUgcHJpb3JpdHkgb2YgY2VydGFp bg0KPiA+ID4gPiBQTCBtZXNzYWdlcywgZXRjIg0KPiA+ID4gVGhpcyB0ZXh0IGhhcyBhbHJlYWR5 IGJlZW4gYWRkZWQgaW4gdGhlIG5ldyB1cGRhdGUuIFBscyBjaGVjayBpdC4NCj4gPiA+IA0KPiA+ IA0KPiA+IERpZCB5b3UgdXBkYXRlIHRoZSB4bWwgb3IgdGhlIC5kb2M/DQo+ID4gSSBzZW50IGEg Zml4ZWQgeG1sIHZlcnNpb24sIGRpZCB5b3UgZ2V0IHRoYXQ/DQo+ID4gSSBhbSBzdXBwb3NlZCB0 byBiZSB3b3JraW5nIGZvciBhIGNvbW11bmljYXRpb25zIGNvbXBhbnkgYWN0dWFsbHksDQo+ID4g T25seSBlbWFpbCBpc250IHJlbGlhYmxlIGNvbW11bmljYXRpb24gZm9yIG1lIGxhdGVseTstPiAN Cj4gPiBQbGVhc2Ugc2VuZCBtZSB0aGUgaGVhZGVycyBldGMgb2Ygd2hlbiB5b3Ugc2VudCB0aGUg ZW1haWxzIHNvIGkgY2FuDQo+ID4gZm9sbG93IHVwIG9uIHRoaXMgc2lkZS4gDQo+ID4gDQo+ID4g SW4gYW55IGNhc2UsIGxldHMgdGFrZSBpdCBvZmYgdGhlIGxpc3QgYW5kIHJlc29sdmUgaXQgdGhh dCB3YXkuDQo+ID4gSWYgeW91IGhhdmUgdXBkYXRlZCB0aGUgeG1sIHNlbmQgaXQgYXMgd2VsbC4N Cj4gPiANCj4gPiBjaGVlcnMsDQo+ID4gamFtYWwNCj4gPg== 2006 Message-Id: Date: Tue, 7 Nov 2006 23:41:40 +0800 From: "Wang,Weiming" Subject: Re: TML Service Primitive Update Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SmFtYWwsDQoNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHRoZSByZXNwb25zZS4gUGxzIHNlZSByZXBs eSBpbiBsaW5lLg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkphbWFs IEhhZGkgU2FsaW0iIDxoYWRpQHpueXguY29tPg0KDQo+IE9uIFR1ZSwgMjAwNi0wNy0xMSBhdCAy MDo0NiArMDgwMCwgV2FuZyxXZWltaW5nIHdyb3RlOg0KPiANCj4gPiBIb3cgYWJvdXQgb3RoZXJz IChhbHNvIHRoZSBhdXRob3JzKSB0aG91Z2h0cz8NCj4gPiANCj4gDQo+IEkgYWdyZWUgd2l0aCBK b2VsJ3MgdmlldzsgaW4gYWRkaXRpb24sIHRoZSB0ZXh0IHN0aWxsIGhhcyBhIGxvdCBvZg0KSmFt YWwsIHRoZSB0ZXh0IGFzICIuLi5BIEZvckNFUyBQTCBpbXBsZW1lbnRhdGlvbiBtdXN0IGJlIHBv cnRhYmxlIGFjcm9zcy4uLiIgd2VyZSBvcmlnaW5hbGx5IGFkZGVkIGJ5IHlvdSA6KS4gKEknbSBu b3Qgc3VyZSBpdCBpcyBhbHNvIGZvciB0aGUgcHJvdG9jb2wgZG9jdW1lbnQpLiBUaGF0J3Mgd2h5 IEkgYXNrZWQgeW91ciB0aG91Z2h0LiANCg0KPiAiaG93dG8iIHR5cGUgb2YgImZlYXR1cmVzIi4g DQo+IEkgdGhpbmsgeW91IHN0aWxsIGhhdmUgdG9vIG1hbnkgImZlYXR1cmVzIiB0aGF0IGVuZCB1 cA0KPiB0eWluZyB0aGluZ3MgdG8gc29tZSBzcGVjaWZpYyBvcGVyYXRpb25zIGluIHNvbWUgc3Bl Y2lmaWMgT1Nlcy4gDQo+IFRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIG1ha2luZyByZWNvbW1lbmRh dGlvbnMsIG5vdCBzYXkgInRoaXMgaXMgaG93IGl0DQo+IGlzIGRvbmUiLiBJdCBtdXN0IG5ldmVy IGJlIGltcG9zaW5nIHRoZSBob3ctdG8gYWNoaWV2ZSB0aGluZ3MuDQo+IEkgc2VudCB5b3UgcHJp dmF0ZSBlbWFpbHMgb24gdGhlIHRvcGljIGFscmVhZHkgYnV0IGRpZG50IHJlY2VpdmUNCj4gcmVz cG9uc2VzIC0gc28gYSBmZXcgb2YgdGhlIHRob3VnaHRzIGFyZSBiZWxvdzoNCkphbWFsLCBJIGhh dmUgc2VudCB5b3UgYSBidW5jaCBvZiBlbWFpbHMgd2l0aCB0aGUgcmVzcG9uc2VzIHJlZ2FyZGlu ZyB0aGlzLiBJIGRvbid0IGtub3cgaWYgc29tZXRoaW5nIHdyb25nIHdpdGggdGhlIGVtYWlscyBv ciBub3QsIG9yIG90aGVyIHJlYXNvbnM/IE1heWJlIHdlIGhhdmUgdG8gdXNlIHRoaXMgbGlzdCBh bHNvIGZvciB0aGUgcHJpdmF0ZSBjb21tLjopDQpNYXkgYmUgSSBuZWVkIHRvIHJlc2VuZCB5b3Ug dGhlc2UgZW1haWxzLg0KDQo+IA0KPiAxKSBJbiB0aGUgZXZlbnRzIHNlY3Rpb24gd2hlcmUgdGhl cmUgYXJlIHNvbWUgZXZlbnRzIHRoYXQgYXJlIGRlc2NyaWJlZA0KPiBzdWNoIGFzIGNvbmdlc3Rp b24gYWxlcnQsIERPUyBhbGVydCBldGMuIEl0IGlzIG5vdCBkZWZpbmVkIGhvdyBzdWNoDQpZb3Ug bWVhbiB3ZSBsYWNrIGRldGFpbGVkIGRlZmluaXRpb24/IEknbSBhZnJhaWQgaXQgbWF5IHJlYWxs eSBsZWFkIHRvIHRvbyAnZmVhdHVyZWQnIHNwZWNpZmljIG9wZXJhdGlvbnMsd2hpY2ggaXMgYXMg eW91IG9wcG9zZWQgaW4gYWJvdmUgdGV4dC4NCg0KPiB0aGluZ3MgZ2V0IGRldGVjdGVkIGJ5IHRo ZSBUTUwuIEl0IGlzIGFsc28gbm90IG1lbnRpb25lZCBob3cgIHN1Y2gNCj4gaW5mb3JtYXRpb24g aXMgdXNlZCBieSB0aGUgUEwuIEFuIGV4YW1wbGUgb2Ygd2hhdCB3b3VsZCBiZSB1c2VmdWwgd291 bGQNCj4gaGF2ZSBiZWVuIHNvbWV0aGluZyBsaWtlOg0KPiANCj4gIkluIGNhc2VzIHdoZXJlIHRo ZSBPUyBpcyBjYXBhYmxlIG9mIGRldGVjdGluZyBFQ04gKEVhcmx5L2V4cGxpY2l0DQo+IGNvbmdl c3Rpb24gbm90aWZpY2F0aW9uKSB3aGVyZSB0aGUgdW5kZXJseWluZyBJUCBwcm90b2NvbCBpcyBj YXBhYmxlIG9mDQo+IG9mIHBhc3NpbmcgaW5mb3JtYXRpb24gdG8gdGhlIGFwcGxpY2F0aW9uLCB0 aGVuIHRoZSBUTUwgY291bGQgcGFzcyBzdWNoDQo+IGluZm9ybWF0aW9uIHRvIHRoZSBQTC4gVGhl IFBMIGNvdWxkIHVzZSB0aGlzIGluZm9ybWF0aW9uIGZvciBleGFtcGxlIHRvDQo+IGFkanVzdCBp dHMgc2VuZGluZyByYXRlcyBvciBpbmNyZWFzZSBvciByZWR1Y2UgdGhlIHByaW9yaXR5IG9mIGNl cnRhaW4NCj4gUEwgbWVzc2FnZXMsIGV0YyINClRoaXMgdGV4dCBoYXMgYWxyZWFkeSBiZWVuIGFk ZGVkIGluIHRoZSBuZXcgdXBkYXRlLiBQbHMgY2hlY2sgaXQuDQoNCj4gIA0KPiBUaGlzIG5lZWRz IHRvIGJlIGRvbmUgZm9yIGFsbCBldmVudHMuDQo+IA0KPiAyKSBBZ2FpbiBvbiBldmVudHM7IHlv dSBtZW50aW9uIHRoaW5ncyBsaWtlICJzdXN0YWluZWQgZXZlbnRzIi4gSSB0aGluaw0KPiB0aGUg Y29ycmVjdCB0ZXJtaW5vbG9neSBpcyBsZXZlbC10cmlnZ2VyZWQgdnMgZWRnZS10cmlnZ2VyZWQu IA0KPiBBZ2FpbiwgdGhlcmUgYXJlIGEgbG90IG9mIE9TZXMgd2hpY2ggbWF5IGJlIGNhcGFibGUg b2Ygb25lIHZzIHRoZSBvdGhlci4NCj4gWW91IGNvdWxkIHNheSAiIEl0IGlzIHN1Z2dlc3RlZCB0 aGF0IGVycm9yIGV2ZW50cyBhcmUgZGVsaXZlcmVkIGFzDQo+IGxldmVsLXRyaWdnZXJlZCIgYnV0 IG5vdCBpbXBvc2UgdGhleSBhcmUgZGVsaXZlcmVkIHRoYXQgd2F5Lg0KTWF5YmUgJ3N1c3RhaW5l ZCcgaXMgbm90IGEgZ29vZCB3b3JkIGZvciBpdCwgYnV0IEkgdGhpbmsgbGV2ZWwtdHJpZ2dlcmVk L2VkZ2UtdHJpZ2dlcmVkIGlzIG1vcmUgaW1wbGVtZW50YXRpb24gb3JpZW50ZWQuIFdoZXJlYXMs IGlmIHlvdSBwZXJzaXN0IGl0LCB3ZSBjYW4gY2hhbmdlIHRvLg0KDQo+IA0KPiBNeSByZWNvbW1l bmRhdGlvbiBpcyB0byByZWFsbHkgY3V0IG9mZiBhIGxvdCBvZiB0aGlzIHN0dWZmIG9mZiBmb3Ig bm93DQo+IGFuZCB0aGVuIHdlIGNhbiBoYXZlIGRpc2N1c3Npb25zIHdoZXJlIHdlIGNhbiByZXN0 b3JlIHNvbWUgcGllY2VzLiANCkNhbiB5b3Ugc2hvdyBtb3JlIG9uIHdoaWNoIHBhcnQgd2Ugc2hv dWxkIGN1dCBvZmY/IEZyb20gYWJvdmUgdHdvIHBvaW50cywgaXQgc2VlbXMgd2UgbWF5IGFkZCBz b21ldGhpbmcgbW9yZS4NCg0KPiANCj4gVGhlcmUgYXJlIGEgbG90IG1vcmUgaXNzdWVzIGxpa2Ug dGhlIGFib3ZlICh3aGljaCBoZWxkIG1lIGJhY2sgZnJvbQ0KPiBlZGl0aW5nIGJlZm9yZSB0aGUg ZGVhZGxpbmUgc2luY2UgaSBkaWRudCBoZWFyIGZyb20geW91KS4gDQoNCj4gV2UgYWxzbyBuZWVk DQo+IHRvIGltcHJvdmUgcmVhZGFiaWxpdHkgaW4gYSBiaWcgd2F5Lg0KTXVjaCB0aGFua3MgaWYg YW55b25lIGNhbiBoZWxwIGRvIHRoaXMuDQoNClBsZWFzZSBkbyBsZXQgbWUga25vdyBpZiB0aGUg ZW1haWwgY2FuIG9ubHkgYmUgcmVjZWl2ZWQgdmlhIHRoZSBsaXN0IHJhdGhlciB0aGFuIHlvdXIg cHJpdmF0ZSBhY2NvdW50Lg0KIA0KbG90cyB0aGFua3MsDQpXZWltaW5nDQoNCj4gDQo+IGNoZWVy cywNCj4gamFtYWw= 2006 Message-Id: Date: Tue, 7 Nov 2006 20:46:19 +0800 From: "Wang,Weiming" Subject: Re: TML Service Primitive Update Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 Sm9lbCwNCg0KSSB0aGluayB0aGUgcHJvYmxlbSB5b3UgcmFpc2VkIGhhcyBiZWVuIHNvbHZlZCBp biB0aGlzIHVwZGF0ZS4gIFRoZSBmb2xsb3dpbmcgdGV4dCBpbiBTZWN0aW9uIDEgb2YgdGhlIGRy YWZ0IGhhcyBxdWl0ZSBjbGVhcmx5IHN0YXRlZCB0aGUgcHVycG9zZSBvZiB0aGUgZHJhZnQsIHdo aWNoIEkgdGhpbmcgbWVldCB5b3VyIHRob3VnaHRzIHF1aXRlIHdlbGw6IA0KLS0tLS0tLS0tDQog ICBUaGUgcHVycG9zZSBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIHNwZWNpZnkgdGhlIHNlcnZpY2Vz IHRoYXQgdmFyaW91cyANCiAgIFRNTHMgbXVzdCBwcm92aWRlIGZvciBGb3JDRVMgUEwgbGF5ZXIu IFRoZSBUTUwgc2VydmljZXMgYXJlIA0KICAgcmVwcmVzZW50ZWQgYnkgYSBzZXQgb2YgVE1MIHNl cnZpY2UgcHJpbWl0aXZlcyBhbmQgYXNzb2NpYXRlZCBUTUwgDQogICBwcm9wZXJ0aWVzIChUTUwg YXR0cmlidXRlcywgZXRjKS4gIA0KICAgIA0KICAgTm90ZSB0aGF0IHRoaXMgZG9jdW1lbnQgc3Bl Y2lmaWVzIFRNTCBzZXJ2aWNlcyBtb3JlIGF0IGEgc2VtYW50aWMgDQogICBsZXZlbCwgaS5lLiwg aXQgZG9lcyBub3QgdHJ5IHRvIHNwZWNpZnkgZGV0YWlscyBvbiBob3cgdGhlIGRlZmluZWQgDQog ICBUTUwgc2VydmljZXMgc2hhbGwgYmUgaW1wbGVtZW50ZWQuIERpZmZlcmVudCBPcGVyYXRpbmcg U3lzdGVtIA0KICAgcGxhdGZvcm1zIHRoYXQgUEwgYW5kIFRNTCBtYXkgcmVseSBvbiB0byBiZSBk ZXZlbG9wZWQgbWF5IGhhdmUgDQogICBkaWZmZXJlbnQgcHJvZ3JhbW1pbmcgbWV0aG9kcywgcHJv Y2VzcyB0ZWNobmlxdWVzLCBkYXRhIHN0cnVjdHVyZXMsIA0KICAgZXRjIGZvciByZWFsaXppbmcg dGhlIHNldCBvZiBUTUwgc2VydmljZXMuIEFzIGEgcmVzdWx0LCBUTUwgaW50ZXJmYWNlIA0KICAg QVBJcyBjb25zdHJ1Y3RlZCBhY2NvcmRpbmcgdG8gdGhpcyBkb2N1bWVudCBtYXkgdmFyeSBpbiBz b21lIHdheS4gSW4gDQogICB0aGlzIGNvbmRpdGlvbiwgb25lIFBMIHBvcnRhYmxlIHRvIHZhcmlv dXMgVE1McyBhY3R1YWxseSBtZWFucyB0aGUgUEwgDQogICBtdXN0IHByb3ZpZGUgdmFyaW91cyBp bnRlcmZhY2UgZHJpdmVycyBmb3IgZGlmZmVyZW50IFRNTHMsIHdoaWxlIA0KICAga2VlcGluZyB0 aGUgUEwga2VybmVsIHRoZSBzYW1lIGZvciB0aGUgVE1MIG9wZXJhdGlvbnMuIA0KLS0tLS0tLS0N Cg0KSSBzdXBwb3NlIHlvdSBtYXkgYmUgaW4gc29tZXdheSBzdGltdWxhdGVkIGJ5IHRoZSBmb2xs b3dpbmcgdGV4dCB0aGF0IGlzIGFsc28gaW4gU2VjdGlvbiAxIG9mIHRoZSBkcmFmdDogDQotLS0t LS0tLQ0KICBUaGUgRm9yQ0VTIHByb3RvY29sIFtGb3JDRVMtUExdIGRvY3VtZW50IGRlZmluZXMg dGhlIHNwZWNpZmljYXRpb25zIA0KICAgZm9yIFBMLCB3aGlsZSBUTUxzIG9mIGRpZmZlcmVudCB0 cmFuc3BvcnQgbWVkaWEgdHlwZXMgYXJlIHRvIGJlIA0KICAgZGVmaW5lZCBieSBpbmRpdmlkdWFs IElFVEYgZG9jdW1lbnRzLiBBIEZvckNFUyBQTCBpbXBsZW1lbnRhdGlvbiBtdXN0IA0KICAgYmUg cG9ydGFibGUgYWNyb3NzIGFsbCBUTUxzLiBJdCBpcyBmZWFzaWJsZSB0aGF0IHRoZSBpbXBsZW1l bnRlcnMgb2YgDQogICBUTUwgYW5kIFBMIG1heSBiZSBmcm9tIGRpZmZlcmVudCBvcmdhbml6YXRp b25zLiBBcyBhIHJlc3VsdCwgc2VydmljZXMgDQogICBUTUwgcHJvdmlkZXMgdG8gUEwgbXVzdCBi ZSBzcGVjaWZpZWQgaW4gYSBzdGFuZGFyZGl6aW5nIHdheS4gIA0KLS0tLS0tLS0NCg0KZXNwZWNp YWxseSBieSB0aGUgc2VudGVuY2UgIkEgRm9yQ0VTIFBMIGltcGxlbWVudGF0aW9uIG11c3QgDQog YmUgcG9ydGFibGUgYWNyb3NzIGFsbCBUTUxzLiBJdCBpcyBmZWFzaWJsZSB0aGF0IHRoZSBpbXBs ZW1lbnRlcnMgb2YgDQogVE1MIGFuZCBQTCBtYXkgYmUgZnJvbSBkaWZmZXJlbnQgb3JnYW5pemF0 aW9ucy4iIA0KDQpOb3RlIHRoYXQgdGhlIGZpcnN0IGhhbGYgb2YgdGhlIHNlbnRlbmNlIGlzIHF1 b3RlZCBmcm9tIHRoZSBGb3JDRVMgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbiwgd2hpbGUgdGhlIGxh c3QgaGFsZiBvZiB0aGUgc2VudGVuY2Ugb25seSBzdGF0ZXMgIml0IGlzIGZlYXNpYmxlIiwgcmF0 aGVyIHRoYW4gdG8gc3RhdGUgdGhhdCAiaXQgaXMgYSBnb2FsIG9mIHRoZSBkcmFmdCAuLi4iLiAg IFRoZSBkcmFmdCBoYXMgbm90IHN0YXRlZCB0aGlzIGFzIGEgZ29hbC4gDQoNClRvIHJlbW92ZSBw b3NzaWJsZSBhbWJpZ3VpdHksIEkgYWdyZWUgdG8gcmVtb3ZlIHRoZSBzZW50ZW5jZS4gDQoNCkhv dyBhYm91dCBvdGhlcnMgKGFsc28gdGhlIGF1dGhvcnMpIHRob3VnaHRzPw0KDQpUaGFua3MsDQpX ZWltaW5nDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSm9lbCBNLiBI YWxwZXJuIiA8am9lbEBzdGV2ZWNyb2NrZXIuY29tPg0KU3ViamVjdDogUmU6IFRNTCBTZXJ2aWNl IFByaW1pdGl2ZSBVcGRhdGUNCg0KDQo+IEkgdGhpbmsgSSBoYXZlIGEgcGhpbG9zb3BoaWNhbCBk aWZmZXJlbmNlIHdpdGggdGhlIGF1dGhvcnMgb2YgdGhlIFRNTCANCj4gU2VydmljZSBwcmltaXRp dmVzIGRyYWZ0IGFzIHRvIHRoZSBwdXJwb3NlIG9mIHRoZSBkcmFmdC4NCj4gDQo+IEkgZG8gbm90 IGJlbGlldmUsIGFzIHRoZSBkcmFmdCBzdGF0ZXMsIHRoYXQgaXQgaXMgYSBnb2FsIG9mIHRoZSBk cmFmdCANCj4gdG8gcHJvdmlkZSBzdWZmaWNpZW50IHNwZWNpZmljYXRpb24gdG8gYWxsb3cgUEwg aW1wbGVtZW50YXRpb25zIGZyb20gDQo+IG9uZSB2ZW5kb3IgdG8gd29yayB3aXRoIFRNTCBpbXBs ZW1lbnRhdGlvbnMgZnJvbSBhbm90aGVyIHZlbmRvci4NCj4gDQo+IE15IHZpZXcgb2YgdGhlIFRN TCBzZXJ2aWNlIHByaW1pdGl2ZXMgKHdoaWNoIEkgYXNrZWQgZm9yIHF1aXRlIA0KPiB2b2NpZmVy b3VzbHkpIGlzIHRoYXQgdGhleSBkZWZpbmUgdHdvIHRoaW5nczoNCj4gVGhlIHNlcnZpY2VzIHRo YXQgdGhlIFBMIGRlZmluaXRpb24gY2FuIGFzc3VtZSBmcm9tIHRoZSBUTUwsIHNvIHRhaHQgDQo+ IHdlIGNhbiBkZWZpbmUgdGhlIFBMIGNsZWFubHk7DQo+IFRoZSBzZXJ2aWNlcyBhbnkgVE1MIG11 c3QgcHJvdmlkZSB0byB0aGUgVE1MIHNvIHRoYXQgd2UgY2FuIHZlcmlmeSANCj4gdGhhdCBhIFRN TCBwcm9wb3NhbCBtZWV0cyB0aGUgbmVlZHMuDQo+IChUaG9zZSB0d28gb3VnaHQgdG8gYmUgdGhl IHNhbWUuKQ0KPiANCj4gV2hpbGUgcGVvcGxlIG1heSBldmVudHVhbGx5IGJlIGFibGUgdG8gZ2V0 IHByb3RvY29sIHN0YWNrcyBmcm9tIG90aGVyIA0KPiB2ZW5kb3JzLCBhbmQgZXZlbiBwYXJ0cyBv ZiBzdGFja3MsIGludGVybmFsIGludGVyZmFjZXMgYW5kIGludGVybmFsIA0KPiBpbnRlcmZhY2Ug Y29uc2lzdGVuY3kgYXJlIG5vdCBvdXIgZ29hbC4NCj4gDQo+IEkgYmVsaWV2ZSB0aGF0IHRoaXMg cHJpbWFyaWx5IGFmZmVjdHMgdGhlIGludHJvZHVjdG9yeSBtYXRlcmlhbCwgYW5kIA0KPiBub3Qg dGhlIHN1YnN0YW5jZSBvZiB0aGUgZG9jdW1lbnQuICBCdXQgaXQgYWZmZWN0cyB3aHkgdGhlIHJl c3Qgb2YgDQo+IHRoZSBkb2N1bWVudCBpcyBub3cgcmVhc29uYWJsZS4NCj4gDQo+IFlvdXJzLA0K PiBKb2VsIE0uIEhhbHBlcm4NCj4gDQo+IEF0IDEwOjM5IFBNIDExLzMvMjAwNiwgV2VpbWluZyBX YW5nIHdyb3RlOg0KPiA+RGVhciBDaGFpcnMgYW5kIEZvckNFUyBwYXJ0aWNpcGFudHMsDQo+ID4N Cj4gPkF0dGFjaGVkIGlzIHRoZSB1cGRhdGVkIFRNTCBTZXJ2aWNlIHByaW10aXZlIGRyYWZ0IHRo YXQgd2UgYXJlIGdvaW5nIA0KPiA+dG8gc3VibWl0IHNvb24gYWZ0ZXIgdGhlIG1lZXRpbmcuIFRo ZSBhdXRob3JzIGFyZSBzb3JyeSB0byBoYXZlIA0KPiA+bWlzc2VkIHRoZSBzdWJtaXNpb24gZGVh ZGxpbmUgYmVmb3JlIHRoZSBtZWV0aW5nLiBXZSBqdXN0IGhhdmUgaGFkIA0KPiA+c29tZSBleHRy YSBkaXNjdXNzaW9ucyBhbW9uZyB0aGUgYXV0aG9ycyBhZnRlciB0aGUgdXBkYXRlIHdhcyBmaXJz dCANCj4gPm1hZGUgYmVmb3JlIHRoZSBkZWFkbGluZSwgd2hpY2ggZGVsYXllZCBvdXIgc2NoZWR1 bGUgYSBsaXR0bGUuDQo+ID4NCj4gPlRoZSB1cGRhdGUgaXMgbWFpbmx5IGJhc2VkIG9uIGRpc2N1 c3Npb25zIG9uIHRoZSBGb3JDRVMgbGlzdCBtYWRlIA0KPiA+Zm9yIFRNTCBTUC4gU29tZSBrZXkg Y2hhbmdlcyBhcmU6DQo+ID4xLiByZW1vdmVkIGFsbCBYTUwgZGVzY3JpcHRpb25zIGZvciBUTUwu DQo+ID4yLiBtb3N0bHkgcmV3cm90ZSB0aGUgVE1MIGV2ZW50cyBwYXJ0DQo+ID4zLiBtb2RpZmll ZCB0aGUgU1AgZm9ybWF0IGFuZCB0aGUgcGFyYW1ldGVycy4NCj4gPg0KPiA+TW9yZSBjb21tZW50 cyBmcm9tIGxpc3QgYXJlIHZlcnkgbXVjaCBhcHByZWNpYXRlZCBiZWZvcmUgd2UgY291bGQgDQo+ ID5zdWJtaXQgaXQgc29vbiBhZnRlciB0aGUgbWVldGluZy4NCj4gPg0KPiA+VGhhbmtzIGEgbG90 Lg0KPiA+DQo+ID5XZWltaW5n 2006 Message-Id: Date: Tue, 7 Nov 2006 10:51:33 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: TML Service Primitive Update Comments: To: "Wang,Weiming" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Tue, 2006-07-11 at 23:41 +0800, Wang,Weiming wrote: > Jamal, > > Thanks very much for the response. Pls see reply in line. > > ----- Original Message ----- > From: "Jamal Hadi Salim" > > > On Tue, 2006-07-11 at 20:46 +0800, Wang,Weiming wrote: > > > > > How about others (also the authors) thoughts? > > > > > > > I agree with Joel's view; in addition, the text still has a lot of > Jamal, the text as "...A ForCES PL implementation must be portable across..." > were originally added by you :). (I'm not sure it is also for the protocol > document). That's why I asked your thought. > I think that language is probably too strong and it is not too late to fix in the protocol draft as well. > > "howto" type of "features". > > I think you still have too many "features" that end up > > tying things to some specific operations in some specific OSes. > > This document should be making recommendations, not say "this is how it > > is done". It must never be imposing the how-to achieve things. > > I sent you private emails on the topic already but didnt receive > > responses - so a few of the thoughts are below: > Jamal, I have sent you a bunch of emails with the responses regarding this. > I don't know if something wrong with the emails or not, or other reasons? > Maybe we have to use this list also for the private comm.:) > May be I need to resend you these emails. > Please resend them because they never got to me at all. I am really sorry to bring this up in the list instead of privately. > > > > 1) In the events section where there are some events that are described > > such as congestion alert, DOS alert etc. It is not defined how such > You mean we lack detailed definition? I'm afraid it may really lead to > too 'featured' specific operations,which is as you opposed in above text. > > > things get detected by the TML. It is also not mentioned how such > > information is used by the PL. An example of what would be useful would > > have been something like: > > > > "In cases where the OS is capable of detecting ECN (Early/explicit > > congestion notification) where the underlying IP protocol is capable of > > of passing information to the application, then the TML could pass such > > information to the PL. The PL could use this information for example to > > adjust its sending rates or increase or reduce the priority of certain > > PL messages, etc" > This text has already been added in the new update. Pls check it. > Did you update the xml or the .doc? I sent a fixed xml version, did you get that? I am supposed to be working for a communications company actually, Only email isnt reliable communication for me lately;-> Please send me the headers etc of when you sent the emails so i can follow up on this side. In any case, lets take it off the list and resolve it that way. If you have updated the xml send it as well. cheers, jamal 2006 Message-Id: Date: Tue, 7 Nov 2006 09:46:38 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: TML Service Primitive Update Comments: To: "Wang,Weiming" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Tue, 2006-07-11 at 20:46 +0800, Wang,Weiming wrote: > How about others (also the authors) thoughts? > I agree with Joel's view; in addition, the text still has a lot of "howto" type of "features". I think you still have too many "features" that end up tying things to some specific operations in some specific OSes. This document should be making recommendations, not say "this is how it is done". It must never be imposing the how-to achieve things. I sent you private emails on the topic already but didnt receive responses - so a few of the thoughts are below: 1) In the events section where there are some events that are described such as congestion alert, DOS alert etc. It is not defined how such things get detected by the TML. It is also not mentioned how such information is used by the PL. An example of what would be useful would have been something like: "In cases where the OS is capable of detecting ECN (Early/explicit congestion notification) where the underlying IP protocol is capable of of passing information to the application, then the TML could pass such information to the PL. The PL could use this information for example to adjust its sending rates or increase or reduce the priority of certain PL messages, etc" This needs to be done for all events. 2) Again on events; you mention things like "sustained events". I think the correct terminology is level-triggered vs edge-triggered. Again, there are a lot of OSes which may be capable of one vs the other. You could say " It is suggested that error events are delivered as level-triggered" but not impose they are delivered that way. My recommendation is to really cut off a lot of this stuff off for now and then we can have discussions where we can restore some pieces. There are a lot more issues like the above (which held me back from editing before the deadline since i didnt hear from you). We also need to improve readability in a big way. cheers, jamal 2006 Message-Id: Date: Tue, 7 Nov 2006 09:26:06 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Model Section 2 Comments: To: "Joel M. Halpern" , Ellen M Comments: cc: tracker-forces@mip4.org Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Just experimenting in this sample to see if it will be added auto-magically by CCing it. Section 2: Introduction para 2: "The FE model described in this document is primarily an information model, but also includes some aspects of a data model, such as explicit definitions of the LFB class schema and FE schema. It is expected that this FE model will be used as the basis to define the payload for information exchange between the CE and FE in the ForCES protocol. " One could argue that in-fact it primarily a DM given the definition of the schema in this doc takes substantial space; however, i dont think that makes the other piece less important. So how about some minor re-wording of the above to make it more explicit? Example: "The FE model described in this document is an information model, but also includes definitions of the LFB class schema and FE schema which fit as a data model. It is expected that this FE model will be used .................. " Section 2.4 Modeling Language for the FE Model Should we have a s/was/is ? i.e this is not a doc which is capturing history, rather formally describing the decision made. Example: "Human readability was the most important factor considered when" to: "Human readability is the most important factor considered when" As well as "XML was chosen as the specification language" to "XML is chosen as the specification language" etc etc cheers, jamal 2006 Message-Id: Date: Tue, 7 Nov 2006 09:09:16 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: model review: Section 1 Comments: To: "Joel M. Halpern" , "Deleganes, Ellen M" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Ok, so instead of putting off this forever, i am going to incrementally (probably over the rest of the week) post feedback after re-reading the draft for the 100th time over the last few years. Should i be adding these to the issues list or wait for the discussion to complete? Sect 1 ------ Should LFB Capabilities and Events be added as part of the definitions? cheers, jamal 2006 Message-Id: Date: Tue, 7 Nov 2006 08:03:32 -0800 From: "Deleganes, Ellen M" Subject: Re: model review: Section 1 Comments: To: hadi@znyx.com, "Joel M. Halpern" MIME-Version: 1.0 Content-Type: application/x-pkcs7-mime;smime-type=signed-data;name=smime.p7m; smime-type=signed-data; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggPbQ29u dGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9InVzLWFzY2lpIg0KQ29udGVudC1UcmFu c2Zlci1FbmNvZGluZzogN2JpdA0KDQpKYW1hbCwNCg0KVGhhbmtzIGZvciByZXZpZXdpbmcgdGhl IGRvY3VtZW50LiBJIHRoaW5rIGl0IGlzIGdvb2QgdG8gYWRkIHRoZXNlIHRvIHRoZQ0KaXNzdWVz IGxpc3QgYXMgeW91IGVuY291bnRlciB0aGVtLiBJIHN0aWxsIG5lZWQgdG8gZ28gdGhyb3VnaCB0 aGUgaXNzdWVzDQpsaXN0IGFueXdheSBhbmQgY2xvc2Ugb3V0IGFueSB0aGF0IGhhdmUgYmVlbiBy ZXNvbHZlZCBhbmQgZGV0ZXJtaW5lIHdoaWNoIEkNCnRoaW5rIGFyZSBzdGlsbCBvcGVuLg0KDQpU aGFua3MsDQpFbGxlbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmFtYWwg SGFkaSBTYWxpbSBbbWFpbHRvOmhhZGlAem55eC5jb21dIA0KU2VudDogVHVlc2RheSwgTm92ZW1i ZXIgMDcsIDIwMDYgNjowOSBBTQ0KVG86IEpvZWwgTS4gSGFscGVybjsgRGVsZWdhbmVzLCBFbGxl biBNDQpDYzogRk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NDQpTdWJqZWN0OiBtb2RlbCByZXZp ZXc6IFNlY3Rpb24gMQ0KDQpPaywgc28gaW5zdGVhZCBvZiBwdXR0aW5nIG9mZiB0aGlzIGZvcmV2 ZXIsIGkgYW0gZ29pbmcgdG8gaW5jcmVtZW50YWxseQ0KKHByb2JhYmx5IG92ZXIgdGhlIHJlc3Qg b2YgdGhlIHdlZWspIHBvc3QgZmVlZGJhY2sgYWZ0ZXIgcmUtcmVhZGluZyB0aGUNCmRyYWZ0IGZv ciB0aGUgMTAwdGggdGltZSBvdmVyIHRoZSBsYXN0IGZldyB5ZWFycy4NClNob3VsZCBpIGJlIGFk ZGluZyB0aGVzZSB0byB0aGUgaXNzdWVzIGxpc3Qgb3Igd2FpdCBmb3IgdGhlIGRpc2N1c3Npb24N CnRvIGNvbXBsZXRlPw0KDQpTZWN0IDEgDQotLS0tLS0NCg0KU2hvdWxkIExGQiBDYXBhYmlsaXRp ZXMgYW5kIEV2ZW50cyBiZSBhZGRlZCBhcyBwYXJ0IG9mIHRoZSBkZWZpbml0aW9ucz8NCg0KY2hl ZXJzLA0KamFtYWwNCg0KAAAAAAAAoIIRXzCCAyAwggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEF BQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2Vj dXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFa ME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3Vy ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhn CGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXguAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7d AQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41AP OojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8EaTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMx EDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1 dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAEEzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0P BAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9Ky lddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoGCSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDAN BgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHe Y4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv87n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYn oA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG 9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZh eCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4 MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQD Ex5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATDIsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/ LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUjZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxug Pgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZvuSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsY V5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x 7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilo dHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5 K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2k VKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OB Dp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3jMfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlk sJjV86fDrq1QMIIFYzCCBEugAwIBAgIKYSyUiQAAAAAABTANBgkqhkiG9w0BAQUFADBSMQswCQYD VQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVy bmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wNjAzMjIyMjIyNDJaFw0xMjAzMjIyMjMyNDJaMFYxCzAJ BgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0 ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKvXqH/ah10uJc7YzQUh+XEDNqS6IsXOyqCtizr9x6F+v6iRAbvddRRJRWixfV78qarSN9WMymJ9 0M8c9/Dfr1yzFuq95RgCAF3vdve3wKi7kJv6lkMJwyyB+uIYcWtljYx2LDqbb9S6Z6He3q8W/aGK vu23I9ksNx+cmZcDNZwGdXVIEHpEMyA4bp0RvYtfp8BsGAyn6YuK63HugeyYdeFL+4+Wz2tGUqw9 OWhob6oV1oDH3zboLhHJiQ2oIj3jAJ3/LrIkzcWP2R20UIliDAPAAl6MNWJPdsNK5EEeuxEuUSpd FsMj5rBmPHH4U8i8rUmi6GEOcX5rwAw64AzS3gECAwEAAaOCAjUwggIxMA8GA1UdEwEB/wQFMAMB Af8wHQYDVR0OBBYEFAlpgTN7BnOPI0wKA9/3FoERghMFMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3 FQEEAwIBADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBQaxgxKxEdvqNut K/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5odHRwOi8vd3d3LmludGVsLmNvbS9y ZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3klMjBDQS5jcmyG V2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0 ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYIKwYBBQUHAQEEgdYwgdMwYwYIKwYB BQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVs JTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNydDBsBggrBgEFBQcwAoZgaHR0cDov L2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBF eHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCuNCne cJ+vDpXzsHOzMEyz4KgTNDbJROHag8H/ZVga7socoJyC+HKqDfQgxifVorbTbSajCBEAxqg6bbNW BJ6qKOFHneBrXkENf5WdD50eCTCFWRV3EIsHEOQ1kP0eNYV5Ed4hp9y6wASV6z2z86O4+qouLJio w4AIhoCKD8rEyD7ODgTvjvLCKpsVyPlG1jOVSsOSIF2VUmueAmK3RFU4np83zerK/j0G37owhniE DT6ZhwkUd0XL45nt1m7yApMEbnXUTHNaXnE+P98kk3nDXdW25sB+5xWcYR3GpgMdQiZgP/f0KZ+y ZKNE7gcp3I/O4pXqUNWIsLSYTi3soAR2MIIFjzCCBHegAwIBAgIKbxPUggAAAAADuDANBgkqhkiG 9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNV BAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0EwHhcNMDYxMDMwMTczMjQwWhcN MDkxMDI5MTczMjQwWjBJMRswGQYDVQQDExJEZWxlZ2FuZXMsIEVsbGVuIE0xKjAoBgkqhkiG9w0B CQEWG2VsbGVuLm0uZGVsZWdhbmVzQGludGVsLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAx0E8Yjepks3kSYx6il3czgdgDMG56PKqJ+PWV8U7YwSpvWLxknVFP6AJAevwOuXNw9cvqTm2 5nkBschgh76fC7w6JCsFYzrdNPy9mbj4znMuSB41er3u0+TOn1o3BD+Kr2YEZVvPTOkewIRL6Ydi NLuvgai7PrVNmuw6R1h0k4sCAwEAAaOCAu4wggLqMAsGA1UdDwQEAwIHgDAdBgNVHQ4EFgQU7TMr o2hBqE8Y+9Nz1mR1JJ2xGMMwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIhsOMdYSZ5VGD/YEo hY6fU4KRwAlngd69OZXwQwIBZAIBAzAfBgNVHSMEGDAWgBQJaYEzewZzjyNMCgPf9xaBEYITBTCB yQYDVR0fBIHBMIG+MIG7oIG4oIG1hlRodHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L0NS TC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQS5jcmyGXWh0dHA6 Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwl MjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNBLmNybDCB7wYIKwYBBQUHAQEEgeIwgd8waQYIKwYB BQUHMAKGXWh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVs JTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNBLmNydDByBggrBgEFBQcwAoZm aHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZpY2F0ZXMvSW50 ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0EuY3J0MB8GA1UdJQQYMBYG CCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQBgjcVCgQcMBowCgYIKwYBBQUHAwQwDAYKKwYB BAGCNwoDDDBTBgNVHREETDBKoCsGCisGAQQBgjcUAgOgHQwbZWxsZW4ubS5kZWxlZ2FuZXNAaW50 ZWwuY29tgRtlbGxlbi5tLmRlbGVnYW5lc0BpbnRlbC5jb20wDQYJKoZIhvcNAQEFBQADggEBAKJt 6rY5eR3gkgKYAjFrfQU6gLSmW0grXZuDDllFuD9YSBdknV1vIdu+3QUdpG0Yjw9SJf4tu+b8ydaY r4zp/x86WSMpdvBgol5kbY2FQwx55+Jl/hiRmfv1sfVsSAlbTmNfxUvPVU5hI7kGbnuoUQp4jqbl HyZz6w7to+mQVeUqBpTF2E7xIvMKLnGk8R2emvxMaGDoWY7krkZjZDofrlu1U2G8JeU+JDDk96Ks 5LhROAU03QsE9VswMte+WNF9IUJhyjbBAxL2iJ2jCb7IOSc0XL+i409/dFTZUnR7tUE4lEdMFY4a qIWUTd79gIlHReoRAipykasL7AEGuHxvHFoxggGQMIIBjAIBATBkMFYxCzAJBgNVBAYTAlVTMRow GAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMg SXNzdWluZyBDQSAzQQIKbxPUggAAAAADuDAJBgUrDgMCGgUAoIGDMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MTEwNzE2MDMzMlowIwYJKoZIhvcNAQkEMRYEFLOi QDJM+FFCnkU3iS5OBOagmYW8MCQGCSqGSIb3DQEJDzEXMBUwBwYFKw4DAhowCgYIKoZIhvcNAgUw DQYJKoZIhvcNAQEBBQAEgYCqZnRtvrodqyM8XdaHzVCz7Eukt3RWy3xCpdztyw7F2s1TgJLKA/kV 0MiQVxMCM716EUeXwQ2hHCZXvBUlPyuyKxkd3s8FXCgtQf2DbeaUQmv3DtjV6exEXU+AoI4Vh8ri Vg6dHzvGPpmyspJocULR0wrluYazBQOCnvExliC3hgAAAAAAAA== 2006 Message-Id: Date: Mon, 6 Nov 2006 13:41:38 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Comments: To: "Deleganes, Ellen M" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Mon, 2006-06-11 at 08:57 -0800, Deleganes, Ellen M wrote: > > I think what Tom is trying to distinguish is a ForCES element from the XML > use of the term "element". It seems that XML has a specific meaning for the > word "element" that doesn't match the ForCES usage. Ok, that i have no issues with. Thanks for the clarification. But why not ForCESElement or LFBElement etc? cheers, jamal 2006 Message-Id: Date: Mon, 6 Nov 2006 12:35:16 -0500 From: "Joel M. Halpern" Subject: Re: TML Service Primitive Update Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I think I have a philosophical difference with the authors of the TML Service primitives draft as to the purpose of the draft. I do not believe, as the draft states, that it is a goal of the draft to provide sufficient specification to allow PL implementations from one vendor to work with TML implementations from another vendor. My view of the TML service primitives (which I asked for quite vociferously) is that they define two things: The services that the PL definition can assume from the TML, so taht we can define the PL cleanly; The services any TML must provide to the TML so that we can verify that a TML proposal meets the needs. (Those two ought to be the same.) While people may eventually be able to get protocol stacks from other vendors, and even parts of stacks, internal interfaces and internal interface consistency are not our goal. I believe that this primarily affects the introductory material, and not the substance of the document. But it affects why the rest of the document is now reasonable. Yours, Joel M. Halpern At 10:39 PM 11/3/2006, Weiming Wang wrote: >Dear Chairs and ForCES participants, > >Attached is the updated TML Service primtive draft that we are going >to submit soon after the meeting. The authors are sorry to have >missed the submision deadline before the meeting. We just have had >some extra discussions among the authors after the update was first >made before the deadline, which delayed our schedule a little. > >The update is mainly based on discussions on the ForCES list made >for TML SP. Some key changes are: >1. removed all XML descriptions for TML. >2. mostly rewrote the TML events part >3. modified the SP format and the parameters. > >More comments from list are very much appreciated before we could >submit it soon after the meeting. > >Thanks a lot. > >Weiming 2006 Message-Id: Date: Mon, 6 Nov 2006 12:24:27 -0500 From: "Joel M. Halpern" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed We should certainly be consistent about what we call the things. Since I find the term subscript very useful, I tend to think of arrays. Part of the reason that I like subscript is that it is clearly distinct from the content key. In contrast, the table index is not so clearly different. Yours, Joel At 11:30 AM 11/6/2006, Jamal Hadi Salim wrote: > > My 'arrays' are usually 'tables' with rows and columns which > works at least when > > they are 2-D; > >Table is a better name. 2006 Message-Id: Date: Mon, 6 Nov 2006 12:01:01 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Packet redirect:fixed meta data ID assignment,into IANA part? Comments: To: Jia Fenggen Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Hi Fenggen, I believe you are correct (please open an issue tracker on this). We should probably define a few of them ourselves and have IANA issue the rest. I am reading through the redirect section in order to respond to you and reaching a conclusion that this is not how we have implemented and that infact there may be a redundancy involved. Anyways, this is a separate discussion. cheers, jamal On Wed, 2006-01-11 at 09:43 +0800, Jia Fenggen wrote: > In protocol draft version 8,the redirect packet is transimitted to CE > using an redirect TLV encapsulation which has two main > constructors:meta-data ILVs which encapsulate the associated meta > informations with the packet such as output id,input port id etc and > Redirect data TLV which encapsulate the real packet.According to meta > ILV,the identifier of meta data is important,I look through issue32,it > seems that on paris wg meeting we have come to an consensus that static > metadata assignment will be used, with metadata transcoding as necessary.To > make static meta data assignment,i think we should put meta data ID > assignment to IANA consideration,if that is the case,then we need some > inital meta data definitions,are there any mistakes,thanks. 2006 Message-Id: Date: Mon, 6 Nov 2006 11:56:14 -0500 From: "Joel M. Halpern" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Just to clarify, as far as I am concerned the really hard part is the naming for the pieces of information that are configured by the CE. In section 3.1 where we discuss FE Capabilities, FE Capacity, and FE State we also discuss FE configuration. The pieces that go into the configuration information are currently called elements. The collection of all possible components of an LFB or a structure are called "elements" because they are declared using XML Elements with the proper value (i.e. element, element, ...) The usage of element in those terms is probably right. We then further complicate things by bringing in a different use of element when we refer to information elements exchanged between FE and CE in the protocol.n This in turn leads to sentences like "For all elements of information..." which starts to get very confusing as to what kind of element we mean. Some of this can be fixed by clever wording. But it would be helpful to have a term that encompased whatever we rename elements as, as well as elements, since both may have properties, the path to both may appear in get operations, etc. (And we need to at least determine whether it should refer to elements.) [Another example of this is in section 3.2.6 where aI am trying to talk about all the parts of the LFB declaration, and therefore end up with "LFBs are made up of elements..." But an actual LFB is not XML, so it is not made up of XML elements. It is only declared in XML, with the declaration using XML elements to declare various parts that will make up the actual LFB instance.) Yours, Joel M. Halpern At 12:39 PM 11/5/2006, tom.petch wrote: > do like the terms in s3.1 of -model; they - capability and >constraint(capacity) - seem the most natural to me. I have used the term >'function' in my e-mails because that is not in the I-Ds and so seemed neutral >in any discussion, and because it is for me what it is we are >talking about, as >much as capability. The two could be combined; functional capability and >functional constraints. > >'element' in -protocol could be 'protocol element' which, for me at least, is >markedly different to (data) element in XML > >My 'arrays' are usually 'tables' with rows and columns which works >at least when >they are 2-D; and I allow for atomic elements or structures in the rows. (I >sense a C language background to the terminogy of ForCES whereas I am more >mathematics, ASN.1 and SNMP). > >But as you say, hearing more voices would be most welcome. > >Tom Petch 2006 Message-Id: Date: Mon, 6 Nov 2006 11:30:16 -0500 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Comments: To: "tom.petch" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-05-11 at 18:39 +0100, tom.petch wrote: > I do like the terms in s3.1 of -model; they - capability and > constraint(capacity) - seem the most natural to me. I have used the term > 'function' in my e-mails because that is not in the I-Ds and so seemed neutral > in any discussion, and because it is for me what it is we are talking about, as > much as capability. The two could be combined; functional capability and > functional constraints. > I dont see a problem with the above description. S3 does go into pains of describing the difference between the two already ("I can do IPV4 forwarding" being a capability and "I can handle 100K /32 routes" being a constraint. Referring to the constraint as a capacity maybe misconstrued as to be a numeric constraint (as in IPV4 forwarding table capacity) > 'element' in -protocol could be 'protocol element' which, for me at least, is > markedly different to (data) element in XML You lost me a little here. Why should the protocol care? It just carries the modelled data. There may be a need to perhaps mark a clear distinction between the data vs Information model mentioned in passing in the intro. The draft tries to be both. The leggo that constructs the model aka "element" or "structure" are more part of a data model approach whereas the capability/constraint constructs are more of an information model approach, no? > My 'arrays' are usually 'tables' with rows and columns which works at least when > they are 2-D; Table is a better name. > and I allow for atomic elements or structures in the rows. (I > sense a C language background to the terminogy of ForCES whereas I am more > mathematics, ASN.1 and SNMP). > You are right, there is a C-like assumption in the data modelling. That approach is suited to an implementer - isnt that what we want? Joel, re: protocol change - you sound very concerned: IMO, we have always had the constraint that the protocol is dependent on the model. AFAICS, the changes are editorial not technical, no? i.e it is not a big deal. cheers, jamal 2006 Message-Id: Date: Mon, 6 Nov 2006 11:14:16 -0800 From: "Deleganes, Ellen M" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apologies if you have already seen the email enclosed below. Apparently my digital signature results in some people not seeing any contents. It's very odd, because others apparently are. Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Deleganes, Ellen M Sent: Monday, November 06, 2006 8:57 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt I agree that the changes are editorial as opposed to technical. This discussion is mostly about clarifying terminology, not changing the basic definition of the items under discussion. >> 'element' in -protocol could be 'protocol element' which, for me at least, is >> markedly different to (data) element in XML >You lost me a little here. Why should the protocol care? It just carries >the modelled data. I think what Tom is trying to distinguish is a ForCES element from the XML use of the term "element". It seems that XML has a specific meaning for the word "element" that doesn't match the ForCES usage. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Monday, November 06, 2006 8:30 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt On Sun, 2006-05-11 at 18:39 +0100, tom.petch wrote: > I do like the terms in s3.1 of -model; they - capability and > constraint(capacity) - seem the most natural to me. I have used the term > 'function' in my e-mails because that is not in the I-Ds and so seemed neutral > in any discussion, and because it is for me what it is we are talking about, as > much as capability. The two could be combined; functional capability and > functional constraints. >=20 I dont see a problem with the above description. S3 does go into pains of describing the difference between the two already ("I can do IPV4 forwarding" being a capability and "I can handle 100K /32 routes" being a constraint.=20 Referring to the constraint as a capacity maybe misconstrued as to be a numeric constraint (as in IPV4 forwarding table capacity) > 'element' in -protocol could be 'protocol element' which, for me at least, is > markedly different to (data) element in XML You lost me a little here. Why should the protocol care? It just carries the modelled data.=20 There may be a need to perhaps mark a clear distinction between the data vs Information model mentioned in passing in the intro. The draft tries to be both. The leggo that constructs the model aka "element" or "structure" are more part of a data model approach whereas the capability/constraint constructs are more of an information model approach, no? > My 'arrays' are usually 'tables' with rows and columns which works at least when > they are 2-D;=20 Table is a better name. > and I allow for atomic elements or structures in the rows. (I > sense a C language background to the terminogy of ForCES whereas I am more > mathematics, ASN.1 and SNMP). >=20 You are right, there is a C-like assumption in the data modelling. That approach is suited to an implementer - isnt that what we want? Joel, re: protocol change - you sound very concerned:=20 IMO, we have always had the constraint that the protocol is dependent on the model. AFAICS, the changes are editorial not technical, no? i.e it is not a big deal. cheers, jamal 2006 Message-Id: Date: Mon, 6 Nov 2006 08:57:08 -0800 From: "Deleganes, Ellen M" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: application/x-pkcs7-mime;smime-type=signed-data;name=smime.p7m; smime-type=signed-data; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggxcQ29u dGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9InVzLWFzY2lpIg0KQ29udGVudC1UcmFu c2Zlci1FbmNvZGluZzogN2JpdA0KDQpJIGFncmVlIHRoYXQgdGhlIGNoYW5nZXMgYXJlIGVkaXRv cmlhbCBhcyBvcHBvc2VkIHRvIHRlY2huaWNhbC4gVGhpcw0KZGlzY3Vzc2lvbiBpcyBtb3N0bHkg YWJvdXQgY2xhcmlmeWluZyB0ZXJtaW5vbG9neSwgbm90IGNoYW5naW5nIHRoZSBiYXNpYw0KZGVm aW5pdGlvbiBvZiB0aGUgaXRlbXMgdW5kZXIgZGlzY3Vzc2lvbi4NCg0KPj4gJ2VsZW1lbnQnIGlu IC1wcm90b2NvbCBjb3VsZCBiZSAncHJvdG9jb2wgZWxlbWVudCcgd2hpY2gsIGZvciBtZSBhdA0K bGVhc3QsIGlzDQo+PiBtYXJrZWRseSBkaWZmZXJlbnQgdG8gKGRhdGEpIGVsZW1lbnQgaW4gWE1M DQoNCj5Zb3UgbG9zdCBtZSBhIGxpdHRsZSBoZXJlLiBXaHkgc2hvdWxkIHRoZSBwcm90b2NvbCBj YXJlPyBJdCBqdXN0IGNhcnJpZXMNCj50aGUgbW9kZWxsZWQgZGF0YS4NCg0KSSB0aGluayB3aGF0 IFRvbSBpcyB0cnlpbmcgdG8gZGlzdGluZ3Vpc2ggaXMgYSBGb3JDRVMgZWxlbWVudCBmcm9tIHRo ZSBYTUwNCnVzZSBvZiB0aGUgdGVybSAiZWxlbWVudCIuIEl0IHNlZW1zIHRoYXQgWE1MIGhhcyBh IHNwZWNpZmljIG1lYW5pbmcgZm9yIHRoZQ0Kd29yZCAiZWxlbWVudCIgdGhhdCBkb2Vzbid0IG1h dGNoIHRoZSBGb3JDRVMgdXNhZ2UuDQoNClJlZ2FyZHMsDQpFbGxlbg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogRm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFy YXRpb24NClttYWlsdG86Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NXSBPbiBCZWhhbGYgT2Yg SmFtYWwgSGFkaSBTYWxpbQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwNiwgMjAwNiA4OjMwIEFN DQpUbzogRk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NDQpTdWJqZWN0OiBSZTogdGVybWlub2xv Z3kgd2EgUmU6IFhNTCBiYXNpY3MgUmU6IExDIG1vZGVsIGRyYWZ0DQpkcmFmdC1pZXRmLWZvcmNl cy1tb2RlbC0wNy50eHQNCg0KT24gU3VuLCAyMDA2LTA1LTExIGF0IDE4OjM5ICswMTAwLCB0b20u cGV0Y2ggd3JvdGU6DQo+IEkgZG8gbGlrZSB0aGUgdGVybXMgaW4gczMuMSBvZiAtbW9kZWw7IHRo ZXkgLSBjYXBhYmlsaXR5IGFuZA0KPiBjb25zdHJhaW50KGNhcGFjaXR5KSAtIHNlZW0gdGhlIG1v c3QgbmF0dXJhbCB0byBtZS4gIEkgaGF2ZSB1c2VkIHRoZSB0ZXJtDQo+ICdmdW5jdGlvbicgaW4g bXkgZS1tYWlscyBiZWNhdXNlIHRoYXQgaXMgbm90IGluIHRoZSBJLURzIGFuZCBzbyBzZWVtZWQN Cm5ldXRyYWwNCj4gaW4gYW55IGRpc2N1c3Npb24sIGFuZCBiZWNhdXNlIGl0IGlzIGZvciBtZSB3 aGF0IGl0IGlzIHdlIGFyZSB0YWxraW5nDQphYm91dCwgYXMNCj4gbXVjaCBhcyBjYXBhYmlsaXR5 LiAgVGhlIHR3byBjb3VsZCBiZSBjb21iaW5lZDsgZnVuY3Rpb25hbCBjYXBhYmlsaXR5IGFuZA0K PiBmdW5jdGlvbmFsIGNvbnN0cmFpbnRzLg0KPiANCg0KSSBkb250IHNlZSBhIHByb2JsZW0gd2l0 aCB0aGUgYWJvdmUgZGVzY3JpcHRpb24uIFMzIGRvZXMgZ28gaW50byBwYWlucw0Kb2YgZGVzY3Jp YmluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0d28gYWxyZWFkeSAoIkkgY2FuIGRvIElQ VjQNCmZvcndhcmRpbmciIGJlaW5nIGEgY2FwYWJpbGl0eSBhbmQgIkkgY2FuIGhhbmRsZSAxMDBL IC8zMiByb3V0ZXMiIGJlaW5nDQphIGNvbnN0cmFpbnQuIA0KUmVmZXJyaW5nIHRvIHRoZSBjb25z dHJhaW50IGFzIGEgY2FwYWNpdHkgbWF5YmUgbWlzY29uc3RydWVkIGFzIHRvIGJlIGENCm51bWVy aWMgY29uc3RyYWludCAoYXMgaW4gSVBWNCBmb3J3YXJkaW5nIHRhYmxlIGNhcGFjaXR5KQ0KDQo+ ICdlbGVtZW50JyBpbiAtcHJvdG9jb2wgY291bGQgYmUgJ3Byb3RvY29sIGVsZW1lbnQnIHdoaWNo LCBmb3IgbWUgYXQgbGVhc3QsDQppcw0KPiBtYXJrZWRseSBkaWZmZXJlbnQgdG8gKGRhdGEpIGVs ZW1lbnQgaW4gWE1MDQoNCllvdSBsb3N0IG1lIGEgbGl0dGxlIGhlcmUuIFdoeSBzaG91bGQgdGhl IHByb3RvY29sIGNhcmU/IEl0IGp1c3QgY2Fycmllcw0KdGhlIG1vZGVsbGVkIGRhdGEuIA0KVGhl cmUgbWF5IGJlIGEgbmVlZCB0byBwZXJoYXBzIG1hcmsgYSBjbGVhciBkaXN0aW5jdGlvbiBiZXR3 ZWVuIHRoZSBkYXRhDQp2cyBJbmZvcm1hdGlvbiBtb2RlbCBtZW50aW9uZWQgaW4gcGFzc2luZyBp biB0aGUgaW50cm8uIFRoZSBkcmFmdCB0cmllcw0KdG8gYmUgYm90aC4NClRoZSBsZWdnbyB0aGF0 IGNvbnN0cnVjdHMgdGhlIG1vZGVsIGFrYSAiZWxlbWVudCIgb3IgInN0cnVjdHVyZSIgYXJlDQpt b3JlIHBhcnQgb2YgYSBkYXRhIG1vZGVsIGFwcHJvYWNoIHdoZXJlYXMgdGhlIGNhcGFiaWxpdHkv Y29uc3RyYWludA0KY29uc3RydWN0cyBhcmUgbW9yZSBvZiBhbiBpbmZvcm1hdGlvbiBtb2RlbCBh cHByb2FjaCwgbm8/DQoNCj4gTXkgJ2FycmF5cycgYXJlIHVzdWFsbHkgJ3RhYmxlcycgd2l0aCBy b3dzIGFuZCBjb2x1bW5zIHdoaWNoIHdvcmtzIGF0DQpsZWFzdCB3aGVuDQo+IHRoZXkgYXJlIDIt RDsgDQoNClRhYmxlIGlzIGEgYmV0dGVyIG5hbWUuDQoNCj4gYW5kIEkgYWxsb3cgZm9yIGF0b21p YyBlbGVtZW50cyBvciBzdHJ1Y3R1cmVzIGluIHRoZSByb3dzLiAgKEkNCj4gc2Vuc2UgYSBDIGxh bmd1YWdlIGJhY2tncm91bmQgdG8gdGhlIHRlcm1pbm9neSBvZiBGb3JDRVMgd2hlcmVhcyBJIGFt IG1vcmUNCj4gbWF0aGVtYXRpY3MsIEFTTi4xIGFuZCBTTk1QKS4NCj4gDQoNCllvdSBhcmUgcmln aHQsIHRoZXJlIGlzIGEgQy1saWtlIGFzc3VtcHRpb24gaW4gdGhlIGRhdGEgbW9kZWxsaW5nLiBU aGF0DQphcHByb2FjaCBpcyBzdWl0ZWQgdG8gYW4gaW1wbGVtZW50ZXIgLSBpc250IHRoYXQgd2hh dCB3ZSB3YW50Pw0KDQpKb2VsLCByZTogcHJvdG9jb2wgY2hhbmdlIC0geW91IHNvdW5kIHZlcnkg Y29uY2VybmVkOiANCklNTywgd2UgaGF2ZSBhbHdheXMgaGFkIHRoZSBjb25zdHJhaW50IHRoYXQg dGhlIHByb3RvY29sIGlzIGRlcGVuZGVudCBvbg0KdGhlIG1vZGVsLiBBRkFJQ1MsIHRoZSBjaGFu Z2VzIGFyZSBlZGl0b3JpYWwgbm90IHRlY2huaWNhbCwgbm8/IGkuZSBpdA0KaXMgbm90IGEgYmln IGRlYWwuDQoNCmNoZWVycywNCmphbWFsDQoAAAAAAACgghFfMIIDIDCCAomgAwIBAgIENd70zzAN BgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMk RXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyMjE2NDE1MVoXDTE4 MDgyMjE2NDE1MVowTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAwV2xWGcIYu6gmi0fCG2RFGiYCh7+2gRvE4RiIcPRfM6fBeC4AfBONOziipUEZKzxa1Nf BbPLZ4C/QgKO/t0BCezhABRP/PvwDN1Dulsr4R+AcJkVV5MW8Q+XarfCaCMczE1ZMKxRHjuvK9bu Y0V7xdlfUNLjUA86iOe/FP3gx7kCAwEAAaOCAQkwggEFMHAGA1UdHwRpMGcwZaBjoGGkXzBdMQsw CQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMBoGA1UdEAQTMBGBDzIwMTgwODIyMTY0 MTUxWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUSOZo+SvSspXXR9gjIBBPM5iQn9QwHQYDVR0O BBYEFEjmaPkr0rKV10fYIyAQTzOYkJ/UMAwGA1UdEwQFMAMBAf8wGgYJKoZIhvZ9B0EABA0wCxsF VjMuMGMDAgbAMA0GCSqGSIb3DQEBBQUAA4GBAFjOKer89961zgK5F7WF0bnj4JXMJTENAKaSbn+2 kmOeUJXRmm/kEd5jhW6Y7qj/WsjTVbJmcVfewCHrPSqnI0kBBIZCe/zuf6IWUrVnZ9NA2zsmWLIo dz2uFHdh1voqZiegDfqnc1zqcPGUIWVEX/r87yloqaKHee9570+sB3c4MIIDPTCCAqagAwIBAgID BbD/MA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYD VQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDYwMjE2MTgwMTMw WhcNMTYwMjE5MTgwMTMwWjBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRp b24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMGl39c5v1BWoRnyZDXTjZN04ircBMMixXbEPK3fTIvIxHlaO26z RufcH6F7z0GI078s/r6sXMTCUPnk+Vf4csYgp400b3t2rJzfQUSURSNnNNkWrY3h7eRUn9cAQSAA 3NXy/2qnupbDG6A+B9zfP0GRii34KJ+jN7Ectv+ERmP7IhIJTrWRFm+5JDQTXXJgvh1GByCUl5oe jehfnuu8hyRouxhXn/UCP5HwMzU+mT3rldAAqwd+fJPsLhLnRPiVWfiXPfrA501mf/N6AbXOnjWW ehMV9Pgq4pUkfnHtgPWnopuAkIoui+e6Ma6iGq4E191cqlmS/Pqka/6ILUdrAl0CAwEAAaOBoDCB nTAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBrGDErER2+o260r8PRWBqPtN1QMMDoGA1UdHwQz MDEwL6AtoCuGKWh0dHA6Ly9jcmwuZ2VvdHJ1c3QuY29tL2NybHMvc2VjdXJlY2EuY3JsMB8GA1Ud IwQYMBaAFEjmaPkr0rKV10fYIyAQTzOYkJ/UMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEF BQADgYEAExA4raRUpUiVRbAtN3LAn57Y748L+5CW0rYXeVHKs98Gfr206Qg/hKAMk5+zHKhsis8t 7vmQEvD4OibXc4EOn8QxklnUKCVB9VXxyj2ZPdpkyNIYZCIyCQktHeMx+v3TR9dkqPld6oIn4k/S YSEkYR1UJj4UWWSwmNXzp8OurVAwggVjMIIES6ADAgECAgphLJSJAAAAAAAFMA0GCSqGSIb3DQEB BQUAMFIxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlvbjEnMCUGA1UEAxMe SW50ZWwgRXh0ZXJuYWwgQmFzaWMgUG9saWN5IENBMB4XDTA2MDMyMjIyMjI0MloXDTEyMDMyMjIy MzI0MlowVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQD EyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAq9eof9qHXS4lztjNBSH5cQM2pLoixc7KoK2LOv3HoX6/qJEBu911FElFaLF9 XvypqtI31YzKYn3Qzxz38N+vXLMW6r3lGAIAXe9297fAqLuQm/qWQwnDLIH64hhxa2WNjHYsOptv 1Lpnod7erxb9oYq+7bcj2Sw3H5yZlwM1nAZ1dUgQekQzIDhunRG9i1+nwGwYDKfpi4rrce6B7Jh1 4Uv7j5bPa0ZSrD05aGhvqhXWgMffNuguEcmJDagiPeMAnf8usiTNxY/ZHbRQiWIMA8ACXow1Yk92 w0rkQR67ES5RKl0WwyPmsGY8cfhTyLytSaLoYQ5xfmvADDrgDNLeAQIDAQABo4ICNTCCAjEwDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUCWmBM3sGc48jTAoD3/cWgRGCEwUwCwYDVR0PBAQDAgGG MBAGCSsGAQQBgjcVAQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaA FBrGDErER2+o260r8PRWBqPtN1QMMIG9BgNVHR8EgbUwgbIwga+ggayggamGTmh0dHA6Ly93d3cu aW50ZWwuY29tL3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGlj eSUyMENBLmNybIZXaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwv SW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3JsMIHjBggrBgEFBQcBAQSB 1jCB0zBjBggrBgEFBQcwAoZXaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZp Y2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MGwGCCsGAQUF BzAChmBodHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRl cy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBQb2xpY3klMjBDQS5jcnQwDQYJKoZIhvcNAQEF BQADggEBAK40Kd5wn68OlfOwc7MwTLPgqBM0NslE4dqDwf9lWBruyhygnIL4cqoN9CDGJ9WittNt JqMIEQDGqDpts1YEnqoo4Ued4GteQQ1/lZ0PnR4JMIVZFXcQiwcQ5DWQ/R41hXkR3iGn3LrABJXr PbPzo7j6qi4smKjDgAiGgIoPysTIPs4OBO+O8sIqmxXI+UbWM5VKw5IgXZVSa54CYrdEVTienzfN 6sr+PQbfujCGeIQNPpmHCRR3Rcvjme3WbvICkwRuddRMc1pecT4/3ySTecNd1bbmwH7nFZxhHcam Ax1CJmA/9/Qpn7Jko0TuByncj87ilepQ1YiwtJhOLeygBHYwggWPMIIEd6ADAgECAgpvE9SCAAAA AAO4MA0GCSqGSIb3DQEBBQUAMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jwb3Jh dGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQTAeFw0wNjEw MzAxNzMyNDBaFw0wOTEwMjkxNzMyNDBaMEkxGzAZBgNVBAMTEkRlbGVnYW5lcywgRWxsZW4gTTEq MCgGCSqGSIb3DQEJARYbZWxsZW4ubS5kZWxlZ2FuZXNAaW50ZWwuY29tMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDHQTxiN6mSzeRJjHqKXdzOB2AMwbno8qon49ZXxTtjBKm9YvGSdUU/oAkB 6/A65c3D1y+pObbmeQGxyGCHvp8LvDokKwVjOt00/L2ZuPjOcy5IHjV6ve7T5M6fWjcEP4qvZgRl W89M6R7AhEvph2I0u6+BqLs+tU2a7DpHWHSTiwIDAQABo4IC7jCCAuowCwYDVR0PBAQDAgeAMB0G A1UdDgQWBBTtMyujaEGoTxj703PWZHUknbEYwzA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3FQiG w4x1hJnlUYP9gSiFjp9TgpHACWeB3r05lfBDAgFkAgEDMB8GA1UdIwQYMBaAFAlpgTN7BnOPI0wK A9/3FoERghMFMIHJBgNVHR8EgcEwgb4wgbuggbiggbWGVGh0dHA6Ly93d3cuaW50ZWwuY29tL3Jl cG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNB LmNybIZdaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwl MjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0EuY3JsMIHvBggrBgEFBQcBAQSB 4jCB3zBpBggrBgEFBQcwAoZdaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9jZXJ0aWZp Y2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0EuY3J0MHIG CCsGAQUFBzAChmZodHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRp ZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAzQS5jcnQw HwYDVR0lBBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwKQYJKwYBBAGCNxUKBBwwGjAKBggrBgEF BQcDBDAMBgorBgEEAYI3CgMMMFMGA1UdEQRMMEqgKwYKKwYBBAGCNxQCA6AdDBtlbGxlbi5tLmRl bGVnYW5lc0BpbnRlbC5jb22BG2VsbGVuLm0uZGVsZWdhbmVzQGludGVsLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAom3qtjl5HeCSApgCMWt9BTqAtKZbSCtdm4MOWUW4P1hIF2SdXW8h277dBR2kbRiP D1Il/i275vzJ1pivjOn/HzpZIyl28GCiXmRtjYVDDHnn4mX+GJGZ+/Wx9WxICVtOY1/FS89VTmEj uQZue6hRCniOpuUfJnPrDu2j6ZBV5SoGlMXYTvEi8woucaTxHZ6a/ExoYOhZjuSuRmNkOh+uW7VT Ybwl5T4kMOT3oqzkuFE4BTTdCwT1WzAy175Y0X0hQmHKNsEDEvaInaMJvsg5JzRcv6LjT390VNlS dHu1QTiUR0wVjhqohZRN3v2AiUdF6hECKnKRqwvsAQa4fG8cWjGCAZAwggGMAgEBMGQwVjELMAkG A1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRl cm5hbCBCYXNpYyBJc3N1aW5nIENBIDNBAgpvE9SCAAAAAAO4MAkGBSsOAwIaBQCggYMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTA2MTY1NzA3WjAjBgkqhkiG 9w0BCQQxFgQUu1Hmg4ob4DslOWmFy9n4xCS1gFAwJAYJKoZIhvcNAQkPMRcwFTAHBgUrDgMCGjAK BggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASBgEmIgQM9LKCvlkgeOd7B7YJa1BtwrMjTnkkd5JiP 2WGbdcAB44mq5bQay1MG1LCNlU8I/zCTCm2Hh8LVdYMSCKzTxdxTZjlVUV4osb9oWnws+2X1PvOA TFURXmmBGACvpBLdcWGjXzgNuC9RVWeZs8CnCtC/u9MmRzenYl6JHfN+AAAAAAAA 2006 Message-Id: Date: Sun, 5 Nov 2006 18:39:10 +0100 From: "tom.petch" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Comments: To: "Deleganes, Ellen M" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I do like the terms in s3.1 of -model; they - capability and constraint(capacity) - seem the most natural to me. I have used the term 'function' in my e-mails because that is not in the I-Ds and so seemed neutral in any discussion, and because it is for me what it is we are talking about, as much as capability. The two could be combined; functional capability and functional constraints. 'element' in -protocol could be 'protocol element' which, for me at least, is markedly different to (data) element in XML My 'arrays' are usually 'tables' with rows and columns which works at least when they are 2-D; and I allow for atomic elements or structures in the rows. (I sense a C language background to the terminogy of ForCES whereas I am more mathematics, ASN.1 and SNMP). But as you say, hearing more voices would be most welcome. Tom Petch ----- Original Message ----- From: "Deleganes, Ellen M" Sent: Friday, November 03, 2006 6:00 PM Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt It looks like there is general agreement that the terminology ought to be fixed because the current terminology is causing confusion (though it would be good for more people to weigh in). I like the idea of replacing "attribute" with "capability". We more or less equate these in the model document anyway. Section 3 states "FE attributes provide information at the FE level, particularly the capabilities of the FE at a coarse level". In this case, capabilities describe the functions the FE can perform and capacity constraints. Renaming "element" is going to be more awkward because it doesn't look like a simple case of replacing text. This is more an argument for fixing this because it indicates the term is overloaded and confusing. In one case element is used to describe a protocol element, in other cases it is describing a data structure that is part of some other structure (such as the array) or is an atomic data type contained within a structure. I'm not sure how to disambiguate this, but I can see how this can cause some level of confusion - not to mention the term element has some connotation in XML. Unfortunately, I don't have a good suggestion on how to fix this, prepending a prefix seems like the easiest. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, October 31, 2006 2:33 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt What Joel thinks about the naming of the components of the LFB Classes and structures is: It is going to be awkward to fix But keeping it as is would produce far more confusion for far more people over the long term. So we seem to need to change the terms (element and attribute referring components of the structures / LFB Classes.) Note that such a change will likely also affect the protocol document, since it talks about these things as well. After that, I am willing to change them to almost anything. (But I doubt it would help to declare that LFB Classes and structs have Foos, and some Foos are also Bars. So better words are sought. I believe I have one suggestion on file, but would love to see actual discussion and input from other participants.) Yours, Joel At 03:24 PM 10/31/2006, Jamal Hadi Salim wrote: >What does Joel think about this? 2006 Message-Id: Date: Sat, 4 Nov 2006 11:39:04 +0800 From: Weiming Wang Subject: TML Service Primitive Update Comments: To: "Putzolu, David" , Patrick Droz MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0082_01C70005.D45C3E40" This is a multi-part message in MIME format. ------=_NextPart_000_0082_01C70005.D45C3E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 RGVhciBDaGFpcnMgYW5kIEZvckNFUyBwYXJ0aWNpcGFudHMsDQoNCkF0dGFjaGVkIGlzIHRoZSB1 cGRhdGVkIFRNTCBTZXJ2aWNlIHByaW10aXZlIGRyYWZ0IHRoYXQgd2UgYXJlIGdvaW5nIHRvIHN1 Ym1pdCBzb29uIGFmdGVyIHRoZSBtZWV0aW5nLiBUaGUgYXV0aG9ycyBhcmUgc29ycnkgdG8gaGF2 ZSBtaXNzZWQgdGhlIHN1Ym1pc2lvbiBkZWFkbGluZSBiZWZvcmUgdGhlIG1lZXRpbmcuIFdlIGp1 c3QgaGF2ZSBoYWQgc29tZSBleHRyYSBkaXNjdXNzaW9ucyBhbW9uZyB0aGUgYXV0aG9ycyBhZnRl ciB0aGUgdXBkYXRlIHdhcyBmaXJzdCBtYWRlIGJlZm9yZSB0aGUgZGVhZGxpbmUsIHdoaWNoIGRl bGF5ZWQgb3VyIHNjaGVkdWxlIGEgbGl0dGxlLiAgDQoNClRoZSB1cGRhdGUgaXMgbWFpbmx5IGJh c2VkIG9uIGRpc2N1c3Npb25zIG9uIHRoZSBGb3JDRVMgbGlzdCBtYWRlIGZvciBUTUwgU1AuIFNv bWUga2V5IGNoYW5nZXMgYXJlOg0KMS4gcmVtb3ZlZCBhbGwgWE1MIGRlc2NyaXB0aW9ucyBmb3Ig VE1MLg0KMi4gbW9zdGx5IHJld3JvdGUgdGhlIFRNTCBldmVudHMgcGFydA0KMy4gbW9kaWZpZWQg dGhlIFNQIGZvcm1hdCBhbmQgdGhlIHBhcmFtZXRlcnMuDQoNCk1vcmUgY29tbWVudHMgZnJvbSBs aXN0IGFyZSB2ZXJ5IG11Y2ggYXBwcmVjaWF0ZWQgYmVmb3JlIHdlIGNvdWxkIHN1Ym1pdCBpdCBz b29uIGFmdGVyIHRoZSBtZWV0aW5nLg0KDQpUaGFua3MgYSBsb3QuDQoNCldlaW1pbmcNCg== ------=_NextPart_000_0082_01C70005.D45C3E40 Content-Type: text/plain; name="draft-ietf-forces-tmlsp-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-forces-tmlsp-01.txt" ForCES Working Group W. M. Wang = Internet-Draft Zhejiang Gongshang Univ.=20 Expires: May, 2007 J. Hadi Salim=20 Znyx Networks=20 Alex Audu=20 Garland SoftWorx = =20 Nov., 2006=20 =20 =20 ForCES Transport Mapping Layer (TML) Service Primitives=20 =20 draft-ietf-forces-tmlsp-01.txt=20 =20 =20 =20 Status of this Memo=20 =20 By submitting this Internet-Draft, each author represents that any=20 applicable patent or other IPR claims of which he or she is aware=20 have been or will be disclosed, and any of which he or she becomes=20 aware will be disclosed, in accordance with Section 6 of BCP 79.=20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as = Internet-Drafts.=20 =20 Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsoleted by other documents=20 at any time. It is inappropriate to use Internet-Drafts as reference = material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt.=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 Copyright Notice=20 =20 Copyright (C) The Internet Society (2006).=20 =20 Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20 document are to be interpreted as described in [RFC2119].=20 =20 Abstract=20 =20 =20 =20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 This document specifies Transport Mapping Layer (TML) Service=20 Primitives for Forwarding and Control Element Separation (ForCES).=20 Based on the service primitives, TML services that are provided by=20 TML to ForCES Protocol Layer (PL) are standardized. To define the=20 primitives, TML properties represented as TML events, TML attributes, = and TML capabilities are also specified in the document. =20 =20 =20 Table of Contents=20 =20 1. Introduction....................................................2=20 2. Definitions.....................................................3=20 3. Overview........................................................3=20 3.1. ForCES Protocol Framework..................................4=20 3.2. TML Requirements...........................................4=20 4. TML Representation..............................................5=20 4.1. TML events.................................................6=20 4.2. TML attributes............................................11=20 4.3. TML capabilities..........................................14=20 5. TML Service Primitives.........................................15=20 5.1. Design Principles.........................................15=20 5.2. TML Open..................................................15=20 5.3. TML close.................................................16=20 5.4. TML Configuration.........................................17=20 5.5. TML Query.................................................18=20 5.6. TML send..................................................20=20 5.7. TML receive...............................................21=20 6. Operation Notes................................................23=20 7. Security Considerations........................................24=20 8. Acknowledgements...............................................24=20 9. References.....................................................24=20 10. Author's Address..............................................24=20 =20 =20 1. Introduction=20 =20 ForCES aims to define a set of specifications for routers, firewalls, = gateways, etc based on the architecture of separation of Forwarding=20 Elements (FEs) and Control Elements (CEs). RFC3654 has presented the=20 ForCES requirements, and RFC3746 has defined the ForCES framework.=20 The ForCES FE model [ForCES-Model] is specifying the model to=20 represent an FE. The ForCES protocol [ForCES-PL] is specifying the=20 information exchanging protocol between CE and FE. =20 =20 The ForCES protocol infrastructure consists of two layers: =20 =20 1. The Protocol Layer (PL), which is responsible for generating=20 ForCES protocol messages, and processing protocol messages that come=20 from peering protocol layer in the same ForCES NE.=20 =20 W. Wang Expires May, 2007 [Page 2]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 =20 2. The Transport Mapping Layer (TML), which is responsible for=20 transportation of ForCES protocol messages over variant transport=20 media, like IP, Ethernet, ATM, etc.=20 =20 The ForCES protocol [ForCES-PL] document defines the specifications=20 for PL, while TMLs of different transport media types are to be=20 defined by individual IETF documents. A ForCES PL implementation must = be portable across all TMLs. It is feasible that the implementers of=20 TML and PL may be from different organizations. As a result, services = TML provides to PL must be specified in a standardizing way. =20 =20 The purpose of this document is to specify the services that various=20 TMLs must provide for ForCES PL layer. The TML services are=20 represented by a set of TML service primitives and associated TML=20 properties (TML attributes, etc). =20 =20 Note that this document specifies TML services more at a semantic=20 level, i.e., it does not try to specify details on how the defined=20 TML services shall be implemented. Different Operating System=20 platforms that PL and TML may rely on to be developed may have=20 different programming methods, process techniques, data structures,=20 etc for realizing the set of TML services. As a result, TML interface = APIs constructed according to this document may vary in some way. In=20 this condition, one PL portable to various TMLs actually means the PL = must provide various interface drivers for different TMLs, while=20 keeping the PL kernel the same for the TML operations.=20 =20 2. Definitions=20 =20 This document follows the terminology used by RFC3654, RFC3746, the=20 ForCES protocol[ForCES-PL], and the ForCES FE model [ForCES-Model].=20 For convenience, some definitions are just copied here:=20 =20 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol=20 architecture that defines the ForCES protocol messages, the protocol=20 state transfer scheme, as well as the ForCES protocol architecture=20 itself (including requirements of ForCES TML (see below).=20 Specifications of ForCES PL are defined by [ForCES-PL].=20 =20 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in=20 ForCES protocol architecture that uses the capabilities of existing=20 transport protocols to specifically address protocol message=20 transportation issues, such as how the protocol messages are mapped=20 to different transport media (like TCP, IP, ATM, Ethernet, etc), and=20 how to achieve and implement reliability, multicast, ordering, etc.=20 The ForCES TML specifications are detailed in separate ForCES=20 documents, one for each TML.=20 =20 3. Overview=20 =20 W. Wang Expires May, 2007 [Page 3]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 =20 3.1. ForCES Protocol Framework=20 =20 The ForCES protocol document has presented the protocol framework as=20 in Figure 1. The framework shows the relationship between Protocol=20 Layer (PL) and Transport Mapping Layer (TML). According to this=20 framework, TML lies under PL and provides transportation services for = protocol messages to PL. CE PL communicates with FE PL via CE TML=20 and FE TML. On transmission, PL delivers its ForCES messages to its=20 TML. The TML further delivers the messages to the destination peering = TML(s). On receive, TML delivers ForCES messages it has received to=20 its PL.=20 =20 =20 +-------------------+ +-------------------+=20 | CE PL layer | | FE PL layer |=20 +-------------------+ +-------------------+=20 | CE TML layer | | FE TML layer |=20 +-------------------+ +-------------------+=20 ^ ^=20 | ForCES protocol messages |=20 +--------------------------------------+=20 =20 Figure 1. ForCES Protocol Framework=20 =20 3.2. TML Requirements=20 =20 The ForCES protocol docuement has also presented TML requirements.=20 We list the requirements as below. Each TML specification must=20 describe how it contributes to achieving the requirements. If, for=20 any reason, a TML does not provide a service listed by the=20 requirements, a justification needs to be provided.=20 =20 The TML requirements are:=20 =20 1. Reliability=20 As defined by RFC 3654, section 6 #6.=20 =20 2. Security=20 TML provides security services to the ForCES PL. TML layer should=20 support the following security services and describe how they are=20 achieved.=20 =20 * Endpoint authentication of FE and CE.=20 =20 * Message Authentication=20 =20 * Confidentiality service=20 =20 3. Congestion Control=20 =20 W. Wang Expires May, 2007 [Page 4]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 The congestion control scheme used needs to be defined. The=20 congestion control mechanism defined by the TML should prevent the FE = from being overloaded by the CE or the CE from being overwhelmed by=20 traffic from the FE. Additionally, the circumstances under which=20 notification is sent to the PL to notify it of congestion must be=20 defined.=20 =20 4.Uni/multi/broadcast addressing/delivery if any=20 If there is any mapping between PL and TML level Uni/Multi/Broadcast=20 addressing it needs to be defined.=20 =20 5. HA decisions=20 It is expected that availability of transport links is the TML's=20 responsibility. However, on config basis, the PL layer may wish to=20 participate in link failover schemes and therefore the TML must=20 support this capability.=20 =20 6. Encapsulations used.=20 Different types of TMLs will encapsulate the PL messages on=20 different types of headers. The TML needs to specify the=20 encapsulation used.=20 =20 7. Prioritization=20 It is expected that the TML will be able to handle up to 8 priority=20 levels needed by the PL layer and will provide preferential = treatment.=20 TML needs to define how this is achieved. The requirement for=20 supporting up to 8 priority levels does not mean that the underlying=20 TML MUST be capable of handling up to 8 priority levels. In such an=20 event the priority levels should be divided between the available TML = priority levels. For example, if the TML only supports 2 priority=20 levels, the 0-3 could go in one TML priority level, while 4-7 could=20 go in the other.=20 =20 8. Protection against DoS attacks=20 As described in the Requirements RFC 3654, section 6=20 =20 4. TML Representation =20 =20 The document is to define a set of general services for TML that=20 various TMLs and their implementations must fundamentally provide for = ForCES PL layer. For this sake, a TML representation is necessary=20 that describes general properties of various TMLs. The following=20 entities are used to represent various TML properties. =20 =20 TML Events:=20 When the events happen in TML, PL may be interested to be notified.=20 =20 TML attributes:=20 Represent the TML parameters that should be configured by PL when PL=20 asks TML to provide services. =20 =20 W. Wang Expires May, 2007 [Page 5]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 =20 TML capabilities:=20 TML abilities or capacities that PL is interested to know.=20 =20 Note that, not all TML properties should be made perceivable and=20 controllable by PL. PL only cares those TML properties that PL should = interact with in order for TML to properly provide services to the = PL. =20 =20 4.1. TML events=20 =20 TML events are triggered by some TML status changes when TML is=20 running. PL layer may be interested to be notified when some TML=20 events occur. TML is responsible to asynchronously notify PL of these = events. =20 =20 How a TML event is asynchronously notified to PL highly depends upon=20 operating system environments PL and/or TML implementations may be=20 based. As an example, some environments may adopt a callback=20 mechanism for notification of events between program processes. In=20 this case and for the PL/TML usage, PL may first construct a callback = function to process every event, and then tell TML the callback=20 function handle. Whenever an interested event happens in TML, the TML = will notify PL of the event by invoking the callback handle and let=20 PL execute the callback function. In this way, the TML asynchronously = passes the event notification to the PL. =20 =20 However, this document does not try to define specific means for=20 PL/TML notification. Any appropriate means can be adopted under=20 condition that it shall meet the service requirements. =20 =20 A TML event may appear as a sustained event, i.e., the event will=20 last until the condition triggered the event is changed and the event = is then released. For instance, when an error happens in TML, it will = last until the error is finally by any means removed. In the=20 sustained event case, PL may be interested in knowing not only when=20 the event takes place, but also when the event is released. To meet=20 this need, an event status parameter should be defined and associated = with a sustained event report. The parameter will mark the associated = event with either 'occurring' or 'is released' to indicate the two=20 different status of a sustained event. Nevertheless, not all events=20 are sustained events, so that not all event reports need this kind of = parameters.=20 =20 A TML event shall be distinguished as being subscription-free or=20 subscription-requested. A subscription-free TML event will inevitably = be notified to PL when it occurs. A subscription-requested TML event=20 is only notified to PL when it has been subscribed for by the PL. A=20 way for PL to subscribe for a subscription-requested TML event will=20 be provided by defining an event handle TML attribute as in 1) of=20 Section 4.2. The TML attribute can also provide more events=20 =20 W. Wang Expires May, 2007 [Page 6]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 parameters configuration. See Section 4.2 for more details on the=20 attribute definition.=20 =20 An TML event is assigned a TML event id, so that PL can identify the=20 event uniquely.=20 =20 Followed are descriptions of TML events that must be available for=20 all TML specifications. If, for any reason, an individual TML=20 specification does not provide the events, a justification needs to=20 be provided in the specification.=20 =20 1) TML error event=20 =20 This event reports a TML error during TML running to PL. When the=20 event is invoked, something might be wrong in the TML. Failures like=20 TML link failure in TML are also taken as TML errors, which can be=20 understood as fatal errors for some cases.=20 =20 When the event occurs and an event report is notified to PL, an=20 error code is associated with the event report so as to pass more=20 information about the error to PL layer. The code may expose PL the=20 reason of the error, the type of the error, as such. =20 =20 TML error event is a subscription-free event. When the event occurs,=20 it will always invoke a report to PL.=20 =20 TML error event is a sustained event. The error status will last=20 until the error is removed by any means.=20 =20 As a result, when the event is notified to PL, the following=20 information shall be associated with the event report:=20 =20 o TML error code and associated data=20 =20 o event status=20 1 The event is occurring=20 0 The event is released =20 =20 Note that it is not restricted that more information may also be=20 associated with the event report, depending upon each TML=20 specification or implementation. =20 =20 This document defines the following TML errors and associated data.=20 These errors are usually common to all types of TMLs. =20 =20 TML error code TML error Associated Data=20 =20 1 all local TML link failure none=20 2 some local TML link failure peer TML CE/FE ID(s) the=20 link is connected=20 =20 W. Wang Expires May, 2007 [Page 7]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 3 peer TML unavailable peer TML CE/FE ID(s) =20 4 peer TML abnormally left peer TML CE/FE ID(s)=20 =20 Each TML specification may define its specific errors. There is also=20 a room for each TML implementation to define specific errors. =20 =20 TML error event is assigned with a TML event id =3D 1.=20 =20 2) Message arrive event=20 =20 TML shall be able to make it as an event occurrence when it has=20 received a PL ForCES protocol message from peer TML and has made it=20 ready to deliver to local PL. In this way, an asynchronous message=20 receive mode can be realized in PL. In addition to this asynchronous=20 mode, PL can also use a specific TML receive service primitive as=20 defined in Section 5.8 for PL synchronous receiving of ForCES=20 messages. =20 =20 This event is a subscription-requested event, i.e, unless PL has=20 requested TML to do so, TML will not use an asynchronous event=20 notification way to deliver arrived messages to PL. In this case, PL=20 can still use a TML receive primitive to receive ForCES messages.=20 =20 When the event is notified to PL, the following information shall be=20 associated:=20 =20 o the arrived ForCES message length=20 =20 o the whole arrived ForCES message Protocol Data Unit (PDU)=20 =20 It is not restricted that other information might also be associated=20 with this event report, depending upon requirements of individual TML = specifications or implementations.=20 =20 Note that the message arrive event is not a sustained event, and=20 there is no need to distinguish its status as occurring or released.=20 When the message is reported to PL, the event is automatically=20 released.=20 =20 TML message arrive event is assigned with TML event id =3D 2.=20 =20 =20 3) TML congestion alert=20 =20 Although it is expected that TML provide a ForCES message=20 transportation free of congestion, as a general problem for current=20 Internet society, congestion problem is still quite hard to be=20 completely avoided if mechanisms are purely limited in TML resources=20 and without help from PL resources. In many cases, with the help from = the resources in PL layer, congestion problem may be much better=20 =20 W. Wang Expires May, 2007 [Page 8]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 suppressed. For example, in cases where the OS a TML adopts is=20 capable of detecting an ECN (Early/explicit congestion notification)=20 where the underlying IP protocol is capable of passing information to = the application, then the TML could pass such information to the PL.=20 The PL could use this information for example to adjust its sending=20 rates or increase or reduce the priority of certain PL messages, etc. = More over, even in the case PL could help little for TML congestion,=20 it is still very helpful for PL to know the TML congestion state if=20 it does happen. As a result, in the TML requirement in Section 3.2,=20 it is required that TML must be defined with a method to notify PL of = congestion state. =20 =20 =20 This document specifies that a TML congestion alert event must be=20 supplied with various TMLs and their implementations if the TMLs and=20 implementations are not free from congestion problems due to any=20 reasons. TML notifies PL of congestion state by this TML congestion=20 alert event. It is an alert event because we expect that TML notifies = PL of the event when TML is in danger of, rather than in the state = of,=20 congestion. An alert event is more helpful, because TML is the only=20 path that an FE is connected to CE, and a complete congestion state=20 in TML may lead to CE lost control of the FE, which is fatal for the=20 FE. =20 =20 A TML congestion alert event is defined as a subscription-requested=20 event. It means PL will subscribe for it if PL requires the=20 congestion alert. During some usage cases or during some period of=20 usage, PL may not be interested to be notified of such event. For=20 instance, in many cases, congestion problem at CE side are not so=20 serious as that at FE side where FE side often risk DoS attacks from=20 redirect data. In this case, CE side congestion alert event may be=20 turned off so as to save CPU resources, while FE side congestion=20 alert is always open. =20 =20 A TML congestion alert event is a sustained event. When congestion=20 alerts, it will last until its state is changed back to free of=20 danger for congestion. TML should notify PL twice for the whole=20 congestion report. When there is a congestion alert, TML sends one=20 notification to PL, when it is released, TML sends another=20 notification to PL.=20 =20 TML congestion alert event is assigned with TML event id =3D 3.=20 =20 When the event is notified to PL, the following information will be=20 associated with its report:=20 =20 o TML congestion alert type =20 1 congestion alert from control message transmission=20 2 congestion alert from redriect message transmission=20 3 alert from redirect DoS attack =20 =20 W. Wang Expires May, 2007 [Page 9]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 o event status=20 1 The event is happening=20 0 The event is released =20 =20 Note that it is not restricted that other information may also be=20 associated with the congestion alert report, depending upon=20 individual TML specifications or implementations. For instance, in=20 several cases, it may be of great help to associate with some extra=20 information as which CE/FE link is the congestion located. However,=20 it may be quite difficult for all TMLs and implementations to provide = such information, therefore, as a more suitable choice, it is just=20 left each TML or implementation to decide. =20 =20 More specific definitions of the three types of TML congestion alerts = are presented as below: =20 =20 1. Congestion alert from control message transmission=20 =20 We define that ForCES control messages are all kinds of ForCES=20 protocol messages but ForCES redirect messages. ForCES message types=20 are identified by the message type in the ForCES message header.=20 ForCES redirect messages are the messages whose types are marked as=20 'PacketRedirect'[ForCES-PL]. ForCES redirect messages are used to=20 load redirect data between FE and CE. =20 =20 Congestion alert from control message transmission indicates that TML = is in a state where control message transmission channel is in danger = of congestion and control messages is becoming hard to be transmitted = to peering TML(s). Individual TML specifications or implementations=20 may specifically define the detailed invoking state for the alert. =20 =20 Because ForCES control messages are vital for ForCES network elements = to properly work, the congestion alert from control message=20 transmission is an important signal for PL to timely take actions to=20 secure the network element. =20 =20 2. Congestion alert from redirect message transmission=20 =20 This congestion alert is invoked when the TML comes to a risk that=20 redirect messages are congested during transmission. Each TML=20 specification or implementation may specifically define the detailed=20 invoking state for the alert. =20 =20 ForCES redirect messages that load redirect data between FE and CE,=20 congestion of which may not be so harmful as that of ForCES control=20 messages, but some redirected data are still vital for ForCES network = elements to properly work. For instance routing protocol messages=20 are shipped via ForCES redirect messages. A long time congestion of=20 the messages will severely affect actions of routing protocols. = Hence,=20 this congestion alert should be used by PL to avoid redirect message=20 =20 W. Wang Expires May, 2007 [Page 10]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 congestion as much as possible to improve performance of whole=20 network elements.=20 =20 3. Alert from redirect DoS attack=20 =20 As described, ForCES redirect messages ship redirect data. In FEs,=20 redirect data come via FE interfaces from outer networks. This may=20 leave a hole for malicious attackers [RFC3654, RFC3746]. Attackers=20 may try to start a DoS attack by initiating huge amount of redirect=20 data to some specific ForCES CE. It may make some FE TML abnormally=20 busy transporting redirect data. Because TML channels for ForCES=20 redirect messages and ForCES control messages are often intervened in = many TML implementations in the same physical links, it may=20 eventually making control messages transmission blocked by redirect=20 messages transmission, making the network element in a denial of=20 service state. =20 =20 This alert is used to indicate an alert for redirect DoS attack. Each = TML specification or implementation will specifically define the=20 actual invoking state or take a mechanism for the alert to be = invoked,=20 or make a justification if the TML is considered free from such DoS=20 attack. If a TML has taken some specific mechanism to make=20 straightforward detection of DoS attacks from redirect data, this=20 alert may just be a result report of the DoS detection. =20 =20 The TML alert from redirect DoS attack may not be sufficient enough=20 for the PL to assure the DoS attack state. PL may synthesize=20 information from other part of the FE, like information from some FE=20 LFBs, to finally decide it. Whereas, this alert has already been an=20 enough signal for PL to go into some urgent state for the whole=20 system security. Approaches should be taken immediately by PL to try=20 to release the alert state so that the FE is not in a risk of losing=20 control from CE.=20 =20 4.2.TML attributes=20 =20 TML attributes usually represent those TML parameters that need to be = configured by PL. To represent them as TML attributes, PL can then=20 use TML configuration service primitive as defined in Section 5.5 to=20 make operations to the parameters. PL can then also use TML query=20 service primitive defined in Section 5.6 to retrieve the status of=20 the parameters. =20 =20 Every TML attribute shall be assigned with a unique id for PL to=20 identify the attribute. The id is called TML attribute id. =20 =20 Followed are descriptions of basic TML attributes that shall be used=20 by all TMLs. Each TML or implementation may provide more detailed=20 definitions of these TML attributes based on the basic descriptions.=20 =20 W. Wang Expires May, 2007 [Page 11]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 Individual TMLs or implementations are also allowed to define more=20 specific TML attributes on their own if necessary.=20 =20 1) TML event handle=20 =20 This TML attribute is used for PL to set some parameters for=20 individual TML events. Each TML may individually define its data=20 structure for this attribute, whereas, the data structure may have to = appear as a list and every element of the list may have to at least=20 include the following information:=20 =20 o TML event id=20 This id acts as an index for individual TML events.=20 =20 o subscription flag, if described is a subscription-requested TML=20 event=20 This flag is to indicate the state for TML event subscription. To=20 subscribe/unsubscribe an event is to set/reset the flag.=20 =20 The attribute may also include other information for each TML event=20 implementation. For instance, for an implementation that adopts a=20 callback mechanism for event notifications, the attribute may include = a callback handle, which is used for PL to tell TML the callback=20 function handle. =20 =20 The 'TML event handle' is assigned with a TML attribute id =3D 1.=20 =20 2) Multicast list=20 =20 ForCES protocol requires that TML must support for ForCES message=20 delivery in multicast ways. This multicast is defined at ForCES PL=20 level, i.e., to multicast a ForCES protocol message, a multicast=20 'Destination ID' at the ForCES message header will be specified (See=20 [ForCES-PL] for more details). To support the PL level multicast, TML = must be told the members of the multicast, so that the TML can=20 accordingly deliver messages to all the multicast members. A=20 multicast list is used for this purpose. The multicast list comprises = a multicast id, which is exactly the multicast 'Destination ID', and=20 numerous associated members, which are also represented by ForCES=20 'Destination ID's, represented as below:=20 =20 multicast list =3D {multicast id, member1, member2, ... memberN}=20 =20 When TML is told this multicast list, it means whenever TML is asked=20 by PL to send a ForCES message whose Destination ID is this multicast = id, the TML must deliver the message to all destination CEs or FEs=20 whose ids are individually represented by member1, member2, ... , and = memberN. Individual TML specifications should define how such=20 multicast list maps to TML transport level multicast mechanisms. For=20 instance, if TML adopts multiple TCP links for this PL level=20 =20 W. Wang Expires May, 2007 [Page 12]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 multicast, every member in the multicast list may be mapped to a=20 specific TCP port and an associated IP address. If TML adopts UDP=20 multicast for this PL level multicast, a UDP multicast group with the = same numbers may be constructed and the multicast is mapped to the=20 UDP multicast group.=20 =20 The multicast list must be set into TML by PL, hence it is defined=20 as a TML attribute. PL sets up the attribute by use of a TML=20 configuration service primitive.=20 =20 There might be several multicast lists set to a TML so as to=20 construct multiple multicast paths for PL in this TML. The multicast=20 lists may form a table then in the TML. In this case, a multicast id=20 in every multicast list may act as an index for access of the table. = =20 The 'TML multicast list' is assigned with a TML attribute id =3D 2.=20 =20 3) Working TML Type =20 =20 A TML implementation may be capable of several TML transport ways.=20 For example, a TML with IP transport media may be able to support TML = schemes as TCP for control messages transmission and DCCP for=20 redriect message transmission, or TCP for control messages and UDP=20 for redirect messages. In this case, it may be helpful for PL to=20 dynamically specify which TML transport scheme to adopt for current=20 work. =20 =20 The working TML type is used for above purpose. It is defined as an=20 TML attribute. =20 =20 It should be noted that, in many cases, PL does not have to manage=20 working TML type. TML may more rely on its own management tool or a=20 CE/FE manager for TML type management. As a result, this TML=20 attribute is defined as an optional TML attribute, i.e., it is=20 allowed that a TML may not provide this TML attribute for PL. =20 =20 Whereas if the attribute is provided, it should include the=20 following information:=20 =20 o Working TML Type id=20 the TML type represented by an id, which is set to the TML for it=20 works in this type. The TML type id may be assigned with one of the=20 following values: =20 1 - an IP TML type with the protocol scheme as TCP+UDP, i.e., TCP=20 for control message transmission and UDP for redirect data=20 transmission. =20 2 - an IP TML type with the protocol scheme as TCP+DCCP, i.e., TCP=20 for control message transmission and DCCP for redirect data=20 transmission. =20 =20 W. Wang Expires May, 2007 [Page 13]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 3 - an IP TML type with the protocol scheme as SCTP, i.e., SCTP for = both control and redirect data transmissions. =20 4 - an Ethernet TML type =20 5 ?an ATM based TML type=20 =20 The 'Working TML type' is assigned with a TML attribute id =3D 3.=20 =20 4) TML media specific attributes=20 =20 An individual TML specification may require PL to configure some=20 extra TML parameters specific to this TML media. If any, the TML=20 specification shall provide detailed definitions for such attributes. = =20 5) Implementation specific TML attributes=20 =20 An individual TML implementation may require PL to configure some=20 TML parameters specific to this implementation. If any, the=20 individual implementation will provide detailed definitions for such=20 attributes.=20 =20 4.3. TML capabilities=20 =20 TML capabilities represent TML abilities or capacities to provide=20 services to PL. A TML capability can only be read by PL via TML query = service primitive.=20 =20 Note that, the TML query service primitive as described in Section=20 5.6 is used to query status of TML attributes as well as TML=20 capabilities. A TML attribute id or a TML capability id is=20 simultaneously used for the query operation. As a result, TML=20 attribute id and TML capability id should be kept harmonious and=20 unique to each other. =20 =20 1) Supported TML type=20 =20 PL may be interested to know what TML transportation type(s) the=20 associated TML can support. A TML implementation may be capable of=20 only one TML transport type or simultaneously several TML transport=20 types. This TML capability indicates the relative information to PL. = =20 Note that, as mentioned before, in many cases, PL does not have to=20 manage TML types. TML may more rely on its own management tool or the = CE/FE managers for TML type management. As a result, this capability = is defined as an optional TML property, i.e., it is allowed some TML=20 implementations may decide not to provide this information to PL. =20 =20 Whereas, if the capability is provided, it should include the=20 following information: =20 =20 o a list of supported TML Type id(s)=20 =20 W. Wang Expires May, 2007 [Page 14]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 the TML Type id is as defined before. =20 o configurable indicator=20 a flag to indicate if the TML is configurable or not for its=20 working type, i.e., if PL can use a working TML type attribute to set = the type to the TML. =20 =20 The 'Supported TML type' capability is assigned with a TML=20 capability id =3D 10. =20 =20 5. TML Service Primitives=20 =20 5.1.Design Principles=20 =20 The following principles are applied to the PL-TML service=20 primitives design:=20 =20 1.PL-TML service primitives should hide implementation details=20 regarding reliability, security, multicast, congestion control, etc=20 from PL. =20 =20 2.PL-TML service primitives should be decoupled from possible=20 changes of ForCES PL layer such as the update of ForCES protocol and=20 ForCES FE model. More specifically, primitives should be avoided to=20 be coupled with ForCES protocol PDU format.=20 =20 5.2. TML Open =20 =20 Format:=20 Result =3D TMLopen( )=20 =20 Result:=20 the returned result; it shall indicate whether the TML open is=20 succeeded or not. Moreover, if not succeeded, an id called 'TML id'=20 and used to identify the TML should be returned by the primitive. If=20 not succeeded, an error code may be returned to indicate the error=20 type. =20 =20 Parameters:=20 none=20 =20 Service Description:=20 The primitive is for PL to indicate a TML that the PL is going to=20 associate itself with the TML for services and hence the TML should=20 be ready for use. It highly depends upon each TML specification or=20 individual implementations on what a TML should do when it receives=20 this primitive. For some TMLs, this primitive may just act as an=20 indicator that the PL and the TML has been associated, while every=20 thing for providing services has already been there in the TML. For=20 other TMLs, when received the primitive, they may have to do=20 something to make it ready. For example, for a TML that adopts a=20 =20 W. Wang Expires May, 2007 [Page 15]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 connectionless path as one of its transmission path, the path may=20 always be ready for message transportation without any extra setup;=20 while for a connection-oriented TML path, a TML open or a TML close=20 (see below) primitive may act as an indicator for the TML path to be=20 set or reset. However, it is also possible that some TML=20 specifications or implementations may choose to have such connection- oriented path always ready for use when the TML has been initially=20 booted. =20 =20 The 'TML id' returned by this primitive is as an identifier for the=20 PL to recognize the TML. Other primitives as described below will use = this id to identify a TML for operations. Having defined the TML id,=20 we imply that the usage scenario as one PL being associated with more = than one TML will not excluded by any TML specifications, and may be=20 applied in actual implementations. =20 =20 An important note is, to better synchronize the operations between=20 peering PLs, if a TML has, for any reason, received any PL messages=20 from peering PL before local PL has formally opened the TML, the TML=20 shall discard all these messages.=20 =20 5.3. TML close=20 =20 Format:=20 Result =3D TMLclose(=20 TML id=20 )=20 =20 Result:=20 the returned result; it shall indicate whether the TML close=20 operation is succeeded or not. Moreover, if not succeeded, an error=20 code may be returned to indicate the error type for the failed TML=20 close. =20 =20 Parameters:=20 o TML id (input)=20 the id of the TML to be closed. =20 =20 Service Description:=20 By this primitive, a PL tears down its association with a TML. It=20 highly depends upon each TML specification or implementation on what=20 a TML should do when received this primitive. For some TMLs, this=20 primitive may just act as an indication that the association of the=20 PL and the TML is terminated and nothing more need to be done. For=20 other TMLs, when received the primitive, they may have to manage to=20 make it terminate the association, e.g., by disconnecting a=20 connection with peering TML. However, it is out of scope of this=20 document to have more details specified. =20 =20 =20 W. Wang Expires May, 2007 [Page 16]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 An important note is, to better synchronize the operations between=20 peer PLs, if a TML has, for any reason, received any PL messages from = peer PL after local PL has formally closed the TML, the TML shall=20 discard all these messages.=20 =20 5.4.TML Configuration=20 =20 Format:=20 Result =3D TMLconfig(=20 TML id,=20 operation type,=20 TML attribute id,=20 TML attribute data=20 [,optional parameters]=20 )=20 =20 Result:=20 the returned result; it shall indicate whether the TML configuration=20 is succeeded or not. Moreover, if not succeeded, an error code may be = returned to indicate the error type for the failed configuration.=20 =20 Parameters:=20 o TML id (input)=20 the id of the TML to be configured. =20 o operation type (input)=20 As an input parameter, it specifies the operation type the TML=20 configuration primitive will do. The following operations must be=20 included:=20 SET ?to set data to an attribute in the TML=20 DELETE ?to delete data from an attribute in the TML or to=20 totally remove the attribute from the TML.=20 The following operation may be included:=20 MODIFY ?to modify data for an attribute in the TML=20 =20 Individual TMLs or implementations may define other operations if=20 necessary.=20 =20 o TML attribute id (input)=20 the id inputted to TML; it uniquely specifies the TML attribute=20 the primitive is going to operate on. The id is assigned by=20 individual TML attribute definitions.=20 =20 o TML attribute data (input)=20 a data unit that contains data elements to be configured to a TML=20 attribute. Actual data structure of the data unit will be defined by=20 individual TML implementations.=20 =20 o optional parameters (input or output):=20 Individual TMLs or implementations may allow more parameters for=20 the TML attribute configuration. For e.g., some implementations may=20 =20 W. Wang Expires May, 2007 [Page 17]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 choose to take an extra timeout parameter to make the primitive as a=20 non-blocking primitive call. This document does not exclude such=20 usages. =20 =20 Service Description:=20 This primitive is used by PL to configure attributes of TML=20 according to service requirements made to the TML. TML attributes are = basically described as in Section 4.2. Every attribute to be operated = is identified by the TML attribute id. The TML attribute data=20 parameter provides necessary data for the operation. It is up to=20 individual TML implementations to specify data structure for the=20 attribute. It may be organized as an atomic data element or a=20 compound data element. Individual TML implementations should provide=20 detailed description on the data structure used for individual TML=20 attributes.=20 =20 SET or DELETE operations are two basic operation types to a TML=20 attribute operation. In some cases, more operation types may be=20 required so that management to TML attributes may become more=20 portable to users. This is especially useful for management of TML=20 attributes like TML multicast lists. When PL configures multicast=20 lists to TML, it may require some form of operation variations=20 besides general operations as setting a new multicast list or=20 deleting an existing multicast list. For instance, PL may be=20 interested to add a member to, or delete a member from, an existing=20 multicast list. There may be two approaches for each TML=20 implementation to realize this. One is to define more types of=20 operations. The other is to specifically associate attribute data=20 structure definitions with operation types. Below is an example to=20 show that this is feasible: =20 =20 o operation =3D SET, data =3D {multicast id, member1, member2, ...} = If the multicast list with the multicast id does not exist in=20 the TML, it is to set a new multicast list, or else, to add the new=20 members as listed to the existing multicast list.=20 =20 o operation =3D DELETE, data =3D {multicast id }=20 to delete the whole multicast list with the multicast id.=20 =20 o operation =3D DELETE, data =3D {multicast id, member1, member2, = ...}=20 to delete the members as listed from an existing multicast list,=20 while keeping the multicast list id.=20 =20 Note that the TML configuration service primitive is not designed to=20 return any attribute status after configured. To check the TML=20 attribute status, a TML query primitive as defined below should be=20 specifically used. =20 =20 5.5. TML Query=20 =20 =20 W. Wang Expires May, 2007 [Page 18]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 Format:=20 Result =3D TMLquery(=20 TML id,=20 TML attribute id or TML capability id,=20 [,optional parameters]=20 )=20 =20 Result:=20 The result includes a returned result and a queried result; =20 =20 The returned result shall indicate whether the primitive operation is = succeeded or not. Moreover, if not succeeded, an error code may be=20 returned to indicate the error type for the failed query operation. =20 =20 The queried result shall include the queried data if the query=20 operation is succeeded. Each TML implementation shall define the data = structure for the queried result data. Each TML attribute or TML=20 capability may all have its specific data structure.=20 =20 Note that it is not specified and restricted how the queried result=20 should be implemented in reality. Any techniques may be applied for=20 this purpose under condition that the queried data can be transferred = back to PL layer. For instance, some implementations may adopt a=20 return of function call for transferring the queried result data,=20 while some others may just adopt a parameter of function call for the = transferring. =20 =20 Parameters:=20 o TML id (input)=20 the id of the TML to be operated.=20 =20 o TML attribute id or TML capability id (input)=20 the id that uniquely specifies the TML attribute or TML capability=20 the primitive is going to query. =20 =20 o optional parameters (input or output):=20 Besides the mandatory parameters as presented, individual TMLs or=20 implementations may adopt more parameters to customize the query=20 operation. For instance, it may be interested to query a multicast=20 list with a specified multicast id, rather than to query the whole=20 existing multicast lists. This may be realized by defining a=20 parameter composed of a multicast id as an index for the query. The=20 primitive may also include a timeout parameter to make the primitive=20 as a non-blocking operation. This document does not exclude such=20 usages. =20 =20 Service Description:=20 This primitive is used by PL to query TML attributes or TML=20 capabilities to know their current status. The TML attribute id or=20 TML capability id is used to specify which attribute the primitive is = =20 W. Wang Expires May, 2007 [Page 19]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 interested to query. Queried data are included in result of the=20 primitive execution. Note that this primitive definition does not=20 specify any technology on how the queried data shall be transferred=20 from TML to PL, so as to make the primitive definition independent of = any specific OS environments or implementation techniques. =20 =20 5.6. TML send=20 =20 Format:=20 Result =3D TMLsend(=20 TML id,=20 message destination id,=20 message type,=20 message priority,=20 message length,=20 message PDU=20 [, timeout]=20 [, more optional parameters]=20 )=20 =20 Result:=20 a returned code indicating if the TML send primitive is successful=20 or failed. If successful, a success code is returned. If failed, an=20 error code indicating the failure type is returned. =20 =20 Parameters:=20 o TML id (input)=20 the id of the TML to be operated.=20 =20 o message destination id (input)=20 the id indicating the destination of the ForCES PL message to be=20 sent; equal to the destination ID in the protocol message header. =20 =20 o message type (input)=20 the type of the ForCES protocol message to be sent; equal to the=20 message type in the protocol message header. =20 =20 o message priority (input)=20 the message priority of the protocol message to be sent; equal to=20 the priority bits in the protocol message header.=20 =20 o message length (input)=20 the ForCES protocol message length to be sent, equal to the=20 message length field in the protocol message header, representing the = whole protocol message length in DWORDS ( 4 bytes) units.=20 =20 o message PDU (input)=20 Protocol Data Unit for the whole ForCES protocol message,=20 including the message header and the body. Individual implementations = =20 W. Wang Expires May, 2007 [Page 20]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 may need to further specify the endian way (big-endian or little- endian, etc). =20 =20 o timeout (input, optional parameter)=20 This is an optional parameter to optionally specify the primitive=20 as a non-blocking primitive call. The timeout value specifies how=20 long it may wait before abortion of the primitive call. If not=20 adopted, the primitive is executed in a blocking way.=20 =20 o other optional parameters=20 Individual TMLs or implementations may specify more optional=20 parameters if necessary. =20 =20 Service description:=20 By this service, PL tries to send a message to one (unicast) or more=20 (multicast) peer PLs via the TML. Note that this primitive has=20 explicitly included all information that are necessary for TML to=20 manage transmission of the PL message, therefore, there is no need=20 for the TML to further retrieve more information by reading the PL=20 message body PDU. In this way, it may be decoupled of changes in=20 ForCES protocol PDU (e.g., by the protocol update) from TML services. = =20 =20 The message destination id is used by the TML to map to TML layer=20 transport addresses for the message transmission. This also includes=20 the mapping of PL layer multicast ids to TML layer multicast=20 addresses. Each TML specification should define the way for such=20 mapping.=20 =20 The message type is used for the TML to infer the requirements from=20 PL level for the message transmission, regarding its reliability,=20 timeliness, security, and congestion control. With this message type, = it is easy to recognize PL redirect messages from PL control = messages.=20 Individual TML specifications shall define how the message types are=20 mapped to their individual transportation resources. =20 =20 The message priority is used for the TML to meet the PL requirement=20 for the message transmission priority; it may also be used for TML to = meet the requirements for reliability, timeliness, security, and=20 congestion control. Individual TML specifications may define how the=20 priority is mapped to their available transport mechanisms for=20 prioritized timely transmission. Individual TML specifications may=20 also define how the priority is used for other TML requirements.=20 =20 By use of an optional timeout parameter, the primitive may be=20 applied either in a blocking way or a non-blocking way.=20 =20 5.7. TML receive=20 =20 Format:=20 Result =3D TMLreceive(=20 =20 W. Wang Expires May, 2007 [Page 21]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 TML id,=20 message length,=20 message PDU,=20 timeout,=20 [, optional parameters]=20 )=20 =20 Result:=20 a returned code indicating if the TML receive primitive is=20 successful or failed. If successful, a success code is returned. If=20 failed, an error code indicating the failure type is returned. =20 =20 Parameters:=20 o TML id (input)=20 the id of the TML to be operated.=20 =20 o message length (output)=20 the length of the received ForCES protocol message, representing=20 the whole protocol message length in DWORDS ( 4 bytes) units. It is a = parameter output to PL by TML via this primitive. =20 =20 o message PDU (output)=20 Protocol Data Unit for the whole ForCES protocol message received,=20 including the message header and the bogy. Individual implementations = may need to specify the endian way (big-endian or little-endian, = etc).=20 It is a parameter output to PL by TML via this primitive. =20 =20 o timeout (input)=20 This is a mandatory parameter for the TML receive primitive. It=20 mandates that the primitive shall work in a non-blocking way. The=20 timeout value specifies how long it will mostly wait before abortion=20 of this time receiving process. =20 =20 o optional parameters (input or output)=20 Individual TMLs or implementations may specify more optional=20 parameters for the primitive if necessary. =20 =20 Service description:=20 This service is used for PL to synchronously receive ForCES protocol=20 messages from peering TML via local TML. A received protocol message=20 is returned via the parameters. The primitive specifies that it=20 should be implemented in a non-blocking way. It is because that=20 usually such receiving process may take high priority resources and a = blocking way may make the system risk more of fatal errors. =20 =20 Note that a message arrive event as described before can also be=20 used for PL to receive PL messages from TML. The difference is that=20 this TML receive primitive makes PL to synchronously receive = messages,=20 while a message arrive event works in an asynchronous way receiving a = =20 W. Wang Expires May, 2007 [Page 22]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 message. Usually, an asynchronous method exploits more efficiency in=20 terms of CPU resources. =20 =20 6. Operation Notes=20 =20 1) multicast =20 =20 In a ForCES architecture, PL level multicast may be most commonly=20 for a CE to multicast a ForCES protocol message to multiple FEs.=20 Operation steps for the ForCES system to setup this type of multicast = may be presented as below: =20 =20 a. Before a PL level multicast could be established, usually a PL=20 level unicast mechanism should first be established in the ForCES=20 network element. This means a ForCES message should be able to be=20 delivered in a unicast way between CE and FEs before we setup a=20 multicast path.=20 =20 b. The CE PL (or its application layer) forms a PL level multicast=20 list as defined in 2) of Section 4.2. Note that, because it=20 represents multicast of a CE to FEs, the multicast list shall include = a multicast id, the CE id, and a number of member FE ids.=20 =20 c. The multicast list should be sent to the CE TML by TML=20 configuration service primitive as described by this document. When=20 CE TML receives this multicast list, the TML is responsible to map=20 the multicast list to its TML multicast mechanism. =20 =20 d. The multicast list may also need to be sent to all FE members of=20 the multicast by use of ForCES protocol configure messages in order=20 for the FEs to know they belong to this multicast group. Note that a=20 multicast list has been defined in FE as an attribute of the FE=20 Protocol LFB [ForCES-PL]. The FEs further send the PL multicast list=20 to their FE TMLs by means of TML configuration primitive. When the=20 FEs TMLs receive this multicast list, each TML is responsible to map=20 the multicast list to its TML multicast mechanism. =20 =20 e. When a CE PL generates a message with the multicast id as its=20 destination id and sends it to CE TML, the CE TML will use its TML=20 level multicast mechanism to distribute the messages to individual=20 FEs in the multicast group. =20 =20 f. At the FEs side, when a CE PL message with the multicast id=20 arrives at the FEs TMLs, each TML use its TML multicast mechanism to=20 accept the message, and further deliver it to the FE PL. =20 =20 Above steps may vary in some way according to different TML types=20 with their different mechanism supporting for TML level multicast.=20 =20 2) TBD=20 =20 W. Wang Expires May, 2007 [Page 23]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 =20 7. Security Considerations=20 The risk of being DoS attacked by redirect data has already been=20 addressed by RFC 3654, RFC 3746, the ForCES protocol specification=20 [ForCES-PL], etc. Prevention of the DoS attack is one of the key=20 points to secure the ForCES system. This document specified a TML=20 event notification of alert from redirect DoS attack to specifically=20 support a ForCES system to prevent such attack. =20 =20 TML congestion problem is a broader point of view that may affect=20 performance of a ForCES system greatly. A TML event notification of=20 TML congestion alert is defined for TML by this document, so that TML = primitives defined by this document is more capable of improvement of = ForCES system performance. =20 =20 This document does not define any mechanisms for security services=20 like endpoint authentication of FE and CE, message authentication,=20 and confidentiality service This document just reaffirms the=20 requirement for this security service. This is because that this kind = of security requirement are all specific to TML specifications of=20 different TML media or individual implementations. Each TML=20 specification shall provide detailed description on how to meet this=20 requirement.=20 =20 8. Acknowledgements=20 The authors would like to thank Joel M. Halpern, Huaiyuan Ma, et al=20 for their invaluable comments during evolution of the document.=20 =20 9. References=20 =20 [RFC3654] H. Khosravi, et al., Requirements for Separation of IP=20 Control and Forwarding, RFC 3654, November 2003.=20 =20 [RFC3746] L. Yang, et al., Forwarding and Control Element Separation=20 (ForCES) Framework, RFC 3746, April 2004.=20 =20 [ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft- ietf-forces-protocol-08.txt, work-in-progress, Mar. 2006. =20 =20 [ForCES-Model] J. Halpern, E. Deleganes, ForCES Forwarding Element=20 Model, draft-ietf-forces-model-06.txt. work-in-progress, Oct. 2006.=20 =20 10. Author's Address=20 =20 Weiming Wang=20 Zhejiang Gongshang University=20 149 Jiaogong Road=20 Hangzhou 310035=20 P.R.China=20 Phone: +86-571-28877721=20 =20 W. Wang Expires May, 2007 [Page 24]=20 =0CInternet Draft ForCES TML SP Nov., 2006=20 =20 =20 EMail: wmwang@mail.zjgsu.edu.cn=20 =20 Jamal Hadi Salim=20 Znyx Networks=20 195 Stafford Rd. West=20 Ottawa, Ontario=20 Canada=20 Phone: =20 Email: hadi@znyx.com =20 =20 =20 Alex Audu=20 Garland SoftWorx=20 Garland, Texas=20 USA=20 =20 Phone:=20 Email: alex.audu@garlandnetworx.com=20 =20 Copyright Statement =20 =20 Copyright (C) The Internet Society (2006). This document is subject=20 to the rights, licenses and restrictions contained in BCP 78, and=20 except as set forth therein, the authors retain all their rights. =20 =20 This document and the information contained herein are provided on=20 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE=20 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE=20 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR=20 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=20 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 =20 =20 W. Wang Expires May, 2007 [Page 25]=20 =0C ------=_NextPart_000_0082_01C70005.D45C3E40-- 2006 Message-Id: Date: Fri, 3 Nov 2006 12:06:39 -0500 From: "Joel M. Halpern" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt p.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Actually, I think that the model document probably uses both "attribute" and "element" to refer to the same thing. And sometimes that thing is a capability. So, I would like a term other than capability for the components of the LFB classes (and structures). If that name is X, I think we should refer to what are currently called capabilities as capability-X. (whther the hyphen is actually required will depend upon what X is.) Yours, Joel M. Halpern At 12:00 PM 11/3/2006, Deleganes, Ellen M wrote: >Subject: RE: terminology wa Re: XML basics Re: LC model draft >draft-ietf-forces-model-07.txt >To: "Joel M. Halpern" , > >It looks like there is general agreement that the terminology ought to >be fixed because the current terminology is causing confusion (though it >would be good for more people to weigh in). > >I like the idea of replacing "attribute" with "capability". We more or >less equate these in the model document anyway. Section 3 states "FE >attributes provide information at the FE level, particularly the >capabilities of the FE at a coarse level". In this case, capabilities >describe the functions the FE can perform and capacity constraints. > >Renaming "element" is going to be more awkward because it doesn't look >like a simple case of replacing text. This is more an argument for >fixing this because it indicates the term is overloaded and confusing. >In one case element is used to describe a protocol element, in other >cases it is describing a data structure that is part of some other >structure (such as the array) or is an atomic data type contained within >a structure. I'm not sure how to disambiguate this, but I can see how >this can cause some level of confusion - not to mention the term element >has some connotation in XML. Unfortunately, I don't have a good >suggestion on how to fix this, prepending a prefix seems like the >easiest. > >Regards, >Ellen 2006 Message-Id: Date: Fri, 3 Nov 2006 11:08:47 +0100 From: "tom.petch" Subject: Re: IANA Considerations Re: LC model draft draft-ietf-forces-model-07.txt Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I would suggest ...ns:forces:model:... that is set up a forces namespace for all to use with one branch being the model. I see other WGs specifying :model:1.0 and opposed to :model-1.0 and while I understand the literal difference, I find to hard to see how this will play out in the longer term. Tom Petch ----- Original Message ----- From: "Joel M. Halpern" Sent: Tuesday, October 31, 2006 10:32 PM Subject: Re: IANA Considerations Re: LC model draft draft-ietf-forces-model-07.txt > Following up on Tom's suggestion, it looks like we should use a name > space along the lines of > urn:ietf:params:xml:ns:forcesModel-1.0 > rather than what is in the document currently: > http://ietf.org/forces/1.0/lfbmodel > > Unless someone speaks up to tell me I am breaking something, that is > what I will do. > > Thank you, > Joel M. Halpern > > At 04:17 AM 10/31/2006, tom.petch wrote: > >Whoops; I meant RFC4114, E.164 Number Mapping for the Extensible Provisioning > >Protocol, (not RFC4144), which gives an example of IANA considerations for the > >two urn: for an XML namespace and schema. > > > >My thanks to those who pointed this out to me off-list. > > > >Tom Petch > > > > > >----- Original Message ----- > >From: "tom.petch" > >Sent: Monday, October 30, 2006 5:51 PM > >Subject: IANA Considerations Re: LC model draft draft-ietf-forces-model-07.txt > > > > > > > I just came across a source of inspiration for a form of words for the XML > > > namespace in the IANA Considerations. I commend to you s6 of RFC4144. 2006 Message-Id: Date: Fri, 3 Nov 2006 09:00:34 -0800 From: "Deleganes, Ellen M" Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It looks like there is general agreement that the terminology ought to be fixed because the current terminology is causing confusion (though it would be good for more people to weigh in). I like the idea of replacing "attribute" with "capability". We more or less equate these in the model document anyway. Section 3 states "FE attributes provide information at the FE level, particularly the capabilities of the FE at a coarse level". In this case, capabilities describe the functions the FE can perform and capacity constraints. Renaming "element" is going to be more awkward because it doesn't look like a simple case of replacing text. This is more an argument for fixing this because it indicates the term is overloaded and confusing. In one case element is used to describe a protocol element, in other cases it is describing a data structure that is part of some other structure (such as the array) or is an atomic data type contained within a structure. I'm not sure how to disambiguate this, but I can see how this can cause some level of confusion - not to mention the term element has some connotation in XML. Unfortunately, I don't have a good suggestion on how to fix this, prepending a prefix seems like the easiest. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, October 31, 2006 2:33 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: terminology wa Re: XML basics Re: LC model draft draft-ietf-forces-model-07.txt What Joel thinks about the naming of the components of the LFB=20 Classes and structures is: It is going to be awkward to fix But keeping it as is would produce far more confusion for far more=20 people over the long term. So we seem to need to change the terms (element and attribute=20 referring components of the structures / LFB Classes.) Note that such a change will likely also affect the protocol=20 document, since it talks about these things as well. After that, I am willing to change them to almost anything. (But I=20 doubt it would help to declare that LFB Classes and structs have=20 Foos, and some Foos are also Bars. So better words are sought. I=20 believe I have one suggestion on file, but would love to see actual=20 discussion and input from other participants.) Yours, Joel At 03:24 PM 10/31/2006, Jamal Hadi Salim wrote: >What does Joel think about this?