2006 Message-Id: Date: Mon, 10 Apr 2006 14:03:59 +0530 From: "Dutta, Pranjal" Subject: One question Linux Netlink as an IP Services Protocol (RFC 3549) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65C79.83CABEF0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65C79.83CABEF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, In Netlink design of Linux at present for RT_NETLINK we have facilities to add and del routes from FIB, but not route update (for example if the next hop changes for a prefix). While next hop for a prefix changes we are then going to delete the existing prefix and add the same prefix with a new next-hop right? Was there any specific reason why Update was not included. Pls correct me if I am missing a very basic thing. =20 Thanks in advance, Pranjal ------_=_NextPart_001_01C65C79.83CABEF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

= In Netlink design of Linux at present for RT_NETLINK we have facilities to add and del routes from FIB, but not = route update (for example if the next hop changes for a prefix). While next = hop for a prefix changes we are then going to delete the existing prefix and add = the same prefix with a new next-hop right? Was there any specific reason why = Update was not included. Pls correct me if I am missing a very basic = thing.

Thanks in advance,

Pranjal

------_=_NextPart_001_01C65C79.83CABEF0-- 2006 Message-Id: Date: Mon, 10 Apr 2006 12:44:10 -0400 From: "Joel M. Halpern" Subject: Re: Model: Filtering Comments: To: hadi@znyx.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed What you have written make sense. However ... 1) I can not find a sensible way in the element identifier encoding to structure the identifiers for events such that one can say "I want Event X for all elements of the identified table" and "I want all the events defined on the object or objects identified by identifier Y." It is presumably possible to do both. But can we do it without making the logic so confusing that implementation will be difficult? If not, which one is more important. (I picked the first. The second would require a different approach to element declaration and identification. But if it is what we need, lets figure out how to do it.) 2) The current notification filter model defines the filters for a specific event on a specific element. It can easily be extended to define the filters for a specific event on a table. Including fields to identify the relationship between an event property and any containing event property can be done. But I am again concerned about complexity. Remember that the point of the filters is to avoid excessive information delivery, but not to replicate functionality that better belongs in the CE. Element inter-dependence is really a CE notion. Yours, Joel M. Halpern At 11:55 AM 4/10/2006, Jamal Hadi Salim wrote: >On Fri, 2006-07-04 at 14:27 -0400, Joel M. Halpern wrote: >[..] > > Joel > > > > At 02:21 PM 4/7/2006, Deleganes, Ellen M wrote: > >[..] > >I haven't read the thread with a focus; however, it does seem the >discussion hovers around something we were faced in our implementation >in recursiveness of events. To be noted that we are not totally >conforming to what the model defines at the moment - but hopefully the >experience may help get the model in shape. > >- We assume that events are recursive; this differs slightly from the >current model. IOW, if you say "I subscribe to events on table A", then >you receive all events on table A. >- We assume that the majority of subscriptions will be of the form above >and exceptions will be minimal. We have always found this to be the case >for us in all LFBs with tables. Note, this is not unlike the firewall >model of saying "accept from all" as a default. The design goal for us >in using this scheme was to reduce computation by adding ability to add >exceptions (which are rare). The other model would have been a negative >"reject all" and then an exception list of the positives. > >Given the above assumptions: >* exceptions are added in a given subscription as filters. > >Example: >You subscribe to: port_table/_all_indices_/flags_column_change >which will give you all events of all flags changing all the time. >Assume there are multiple flag values which may change. > >But you could specify a negative filter such as: >"I am not interested in flags/oper_status" >which means you only receive events for flags as long as they are not >oper_status. > >Any newly added rows are not in the exception list, so they naturally >are part of the same subscription and filter. > >I hope this makes sense since i typed it in a rush. > >cheers, >jamal 2006 Message-Id: Date: Mon, 10 Apr 2006 11:59:25 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: One question Linux Netlink as an IP Services Protocol (RFC 3549) Comments: To: "Dutta, Pranjal" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Hi there, This is the wrong list to post such questions to. I am going to answer this time, but please post in linux mailing lists such as linux-net or netdev in the future. An update is an add with an NLM_F_REPLACE flag. The flags are explained in section 2.3.2. If you are familiar with BSD routing sockets, the equivalents are also defined in that section. cheers, jamal On Mon, 2006-10-04 at 14:03 +0530, Dutta, Pranjal wrote: > Hi All, > > In Netlink design of Linux at present for RT_NETLINK we > have facilities to add and del routes from FIB, but not route update > (for example if the next hop changes for a prefix). While next hop for > a prefix changes we are then going to delete the existing prefix and > add the same prefix with a new next-hop right? Was there any specific > reason why Update was not included. Pls correct me if I am missing a > very basic thing. 2006 Message-Id: Date: Mon, 10 Apr 2006 11:55:35 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model: Filtering Comments: To: Ellen M , "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Fri, 2006-07-04 at 14:27 -0400, Joel M. Halpern wrote: [..] > Joel > > At 02:21 PM 4/7/2006, Deleganes, Ellen M wrote: [..] I haven't read the thread with a focus; however, it does seem the discussion hovers around something we were faced in our implementation in recursiveness of events. To be noted that we are not totally conforming to what the model defines at the moment - but hopefully the experience may help get the model in shape. - We assume that events are recursive; this differs slightly from the current model. IOW, if you say "I subscribe to events on table A", then you receive all events on table A. - We assume that the majority of subscriptions will be of the form above and exceptions will be minimal. We have always found this to be the case for us in all LFBs with tables. Note, this is not unlike the firewall model of saying "accept from all" as a default. The design goal for us in using this scheme was to reduce computation by adding ability to add exceptions (which are rare). The other model would have been a negative "reject all" and then an exception list of the positives. Given the above assumptions: * exceptions are added in a given subscription as filters. Example: You subscribe to: port_table/_all_indices_/flags_column_change which will give you all events of all flags changing all the time. Assume there are multiple flag values which may change. But you could specify a negative filter such as: "I am not interested in flags/oper_status" which means you only receive events for flags as long as they are not oper_status. Any newly added rows are not in the exception list, so they naturally are part of the same subscription and filter. I hope this makes sense since i typed it in a rush. cheers, jamal 2006 Message-Id: Date: Mon, 10 Apr 2006 08:33:02 -0400 From: =?gb2312?Q?Dong_Ligang?= Subject: Re: Tentative Minutes Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="gb2312" hi, David&Patrick In the implementation of our ForTER, the TML SP draft and TCP+UDP TML dra= ft=20 have already shown feasible. Therefore, it is appropriate to let these=20= document be WG documents now. This change will be helpful to our project.= regards Dong, Ligang =20 > ----- Original Message -----=20 > From: "Patrick Droz" > Subject: Re: Tentative Minutes >=20 >=20 > > Hi Weiming, > >=20 > > I discussed this with David. We are fine to make it a WG document. > > But we would like to get a time line until when you want to have > > the document done. We still hope to wrap up things during this > > year. > >=20 > > Thanks, > > Patrick > >=20 > > Weiming Wang wrote: > > > Hi Chairs, Hormuzd, and all, > > >=20 > > > A general comment to this updated TML is, it has made great changes= =20 and very good progress. I especially appreciate the changes made with the= =20 following points: > > >=20 > > > 1. eliminated the inter-TML messages. This is the most important=20= change. > > > 2. used PL-TML service primitives for multicast setup. > > >=20 > > > These ideas are exactly the TML SP draft and TCP+UDP TML draft=20 originally suggested (pls see=20 http://www3.ietf.org/proceedings/05nov/slides/forces-2.pdf and=20 http://www3.ietf.org/proceedings/05nov/slides/forces-3.pdf ), therefore I= 'm=20 quite confident that we have come to a basically consistent platform and=20= can syncronize well on these drafts, only with small coordinations maybe=20= needed later. > > >=20 > > > Note that the TML Service Primitive has just been updated as: > > > http://www.ietf.org/internet-drafts/draft-hadi-forces-tmlsp-00.txt > > > It is 00 version because we missed submittion of the draft since la= st=20 IETF meeting, but it is really a new one, with new updates also. > > >=20 > > > Because of this, we do ask the WG to consider the TML SP draft as t= he=20 WG document. > > >=20 > > > The TCP+UDP TML draft ( http://www.ietf.org/internet-drafts/draft- wang-forces-iptml-01.txt ) has also been updated incorparating Joel's and= =20 other's comments from last meeting by eliminating specific congestion=20 control algorithms. We have already a consensus that TCP+UDP TML is=20 essentially necessary besides TCP+DCCP TML. This draft also proposed the=20= ideas above which made current TMLs syncronized in some way. Because of=20= this, we also ask the WG to consider the TCP+UDP TML as the WG document. > > >=20 > > > Thanks very much. > > >=20 > > > Weiming > > >=20 > > > ----- Original Message -----=20 > > > From: "Patrick Droz" > > > Subject: Tentative Minutes > > >> --------------------------------------------------- > > >> > > >> TCP/IP based TML for ForCES Update by Hormuzd > > >=20 > > >> So we would have a=20 > > >> synchronization problem but this particular document is not even a= =20 WG=20 > > >> document and it has not been updated for quite some time. But as t= he=20 > > >> TCP/IP TML document is close to last call this is kind of a proble= m.=20 So=20 > > >> an alternative could be to keep the TML service interface usage=20= model=20 > > >> maintained as a section in the draft. > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > > --=20 > > Dr. Patrick Droz | dro@zurich.ibm.com > > IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > > Saumerstrasse 4 | Tel. +41-44-724-85-25 > > CH-8803 Rueschlikon/Switzerland | Fax. +41-44-724-85-78 > > 2006 Message-Id: Date: Fri, 7 Apr 2006 14:27:19 -0400 From: "Joel M. Halpern" Subject: Re: Model: Filtering Comments: To: "Deleganes, Ellen M" intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed That was the question that I was trying (apparently badly) to start with. Currently, that is defined not to work. It would take only a few lines of text to declare it legitimate. It would take a few more lines to specify the interaction between a table level filter and the element level filter. From where I sit, the table level operations are a significant complexity to implement, with the filters harder than the subscribe. However, a good argument can be made that if we are going to permit table level subscribe, then we ought to permit table level filters. It would be good to hear from other folks, particularly those who are looking at implementing, on both the utility and complexity of these issues. Yours, Joel At 02:21 PM 4/7/2006, Deleganes, Ellen M wrote: >Yes, I understand that it is not possible for a single subscribe action >to subscribe to more than one event for a table. By the same token, one >cannot set the same filters for multiple events in a single operation. >What I meant to ask is whether it would be possible to set the same >filters or thresholds for a single event that is associated with all >elements in the table. > >Regards, >Ellen 2006 Message-Id: Date: Fri, 7 Apr 2006 14:13:27 -0400 From: "Joel M. Halpern" Subject: Re: Model: Filtering Comments: To: "Deleganes, Ellen M" intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The definition of events allows for multiple events to be defined for a single attribute. And there can be (as is necessary) different events tied to different elements of a structure, where the structure may be the contents of the elements of an array. The subscription structure does not allow for a single subscribe action to subscribe to these multiple events. We would have to structure the identifiers very differently to allow a single operation to subscribe to all these events. Yours, Joel M. Halpern At 12:48 PM 4/7/2006, Deleganes, Ellen M wrote: >I was trying to avoid that complexity. It may be that we can not avoid >it. ><thresholds on the table as a whole in order to avoid such complexity, >but you would still have to explain scenario 1 because it sounded like >an element in a table could be assigned multiple events - or is that >true?>> 2006 Message-Id: Date: Fri, 7 Apr 2006 11:45:10 +0800 From: "Wang,Weiming" Subject: Re: Tentative Minutes MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi, Could you show some of your comments on this work related to TML? Actually not very sure what the ever silence to our work mean. in an irrelevant and even wrong technical way, or just not cared much? Positive or negative comments would all help us greatly. Thanks very much. Weiming ----- Original Message ----- From: "Weiming Wang" Subject: Re: Tentative Minutes > Hi Patrick and David, > > Thanks very much for the response. > > As far as we can do, we expect to make our best efforts to settle all the issues of TML SP and related individual TMLs before the next IETF meeting so as to make them ready for LC by that time. We further expect these documents fully done before 67th IETF meeting in Nov. > > Note that we have had implementations on the TML SP and the TCP+UDP TML also, which will greatly help the progress. > > Thanks, > Weiming > > ----- Original Message ----- > From: "Patrick Droz" > Subject: Re: Tentative Minutes > > > > Hi Weiming, > > > > I discussed this with David. We are fine to make it a WG document. > > But we would like to get a time line until when you want to have > > the document done. We still hope to wrap up things during this > > year. > > > > Thanks, > > Patrick > > > > Weiming Wang wrote: > > > Hi Chairs, Hormuzd, and all, > > > > > > A general comment to this updated TML is, it has made great changes and very good progress. I especially appreciate the changes made with the following points: > > > > > > 1. eliminated the inter-TML messages. This is the most important change. > > > 2. used PL-TML service primitives for multicast setup. > > > > > > These ideas are exactly the TML SP draft and TCP+UDP TML draft originally suggested (pls see http://www3.ietf.org/proceedings/05nov/slides/forces-2.pdf and http://www3.ietf.org/proceedings/05nov/slides/forces-3.pdf ), therefore I'm quite confident that we have come to a basically consistent platform and can syncronize well on these drafts, only with small coordinations maybe needed later. > > > > > > Note that the TML Service Primitive has just been updated as: > > > http://www.ietf.org/internet-drafts/draft-hadi-forces-tmlsp-00.txt > > > It is 00 version because we missed submittion of the draft since last IETF meeting, but it is really a new one, with new updates also. > > > > > > Because of this, we do ask the WG to consider the TML SP draft as the WG document. > > > > > > The TCP+UDP TML draft ( http://www.ietf.org/internet-drafts/draft-wang-forces-iptml-01.txt ) has also been updated incorparating Joel's and other's comments from last meeting by eliminating specific congestion control algorithms. We have already a consensus that TCP+UDP TML is essentially necessary besides TCP+DCCP TML. This draft also proposed the ideas above which made current TMLs syncronized in some way. Because of this, we also ask the WG to consider the TCP+UDP TML as the WG document. > > > > > > Thanks very much. > > > > > > Weiming > > > > > > ----- Original Message ----- > > > From: "Patrick Droz" > > > Subject: Tentative Minutes > > >> --------------------------------------------------- > > >> > > >> TCP/IP based TML for ForCES Update by Hormuzd > > > > > >> So we would have a > > >> synchronization problem but this particular document is not even a WG > > >> document and it has not been updated for quite some time. But as the > > >> TCP/IP TML document is close to last call this is kind of a problem. So > > >> an alternative could be to keep the TML service interface usage model > > >> maintained as a section in the draft. > > > > > > > > > > > > > > > > -- > > Dr. Patrick Droz | dro@zurich.ibm.com > > IBM Zurich Research Laboratory | http://www.zurich.ibm.com/~dro > > Saumerstrasse 4 | Tel. +41-44-724-85-25 > > CH-8803 Rueschlikon/Switzerland | Fax. +41-44-724-85-78 > > 2006 Message-Id: Date: Fri, 7 Apr 2006 11:21:34 -0700 From: "Deleganes, Ellen M" Subject: Re: Model: Filtering Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I understand that it is not possible for a single subscribe action to subscribe to more than one event for a table. By the same token, one cannot set the same filters for multiple events in a single operation. What I meant to ask is whether it would be possible to set the same filters or thresholds for a single event that is associated with all elements in the table. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Friday, April 07, 2006 11:13 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Model: Filtering The definition of events allows for multiple events to be defined for=20 a single attribute. And there can be (as is necessary) different=20 events tied to different elements of a structure, where the structure=20 may be the contents of the elements of an array. The subscription structure does not allow for a single subscribe=20 action to subscribe to these multiple events. We would have to structure the identifiers very differently to allow=20 a single operation to subscribe to all these events. Yours, Joel M. Halpern At 12:48 PM 4/7/2006, Deleganes, Ellen M wrote: >I was trying to avoid that complexity. It may be that we can not avoid >it. ><thresholds on the table as a whole in order to avoid such complexity, >but you would still have to explain scenario 1 because it sounded like >an element in a table could be assigned multiple events - or is that >true?>> 2006 Message-Id: Date: Fri, 7 Apr 2006 09:48:22 -0700 From: "Deleganes, Ellen M" Subject: Re: Model: Filtering Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My comments are embedded: Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Tuesday, April 04, 2006 5:29 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Model: Filtering When an event definition is used for a table element, with a name for=20 the subscript, then the definition is indicating that the event is=20 defined for each extant element of the table. A CE can subscribe to that event for any individual element of the=20 table, or it can subscribe to the event for the entire table. ** Note that we have not defined what happens if the CE: a) subscribes to the event for the entire table b) and then unsubscribes to the event for a specific element. <> We should probably define this explicitly, with regard to: i) Is the CE still listed as subscribed to the event for the table? ii) is the CE listed as subscribed to the event for each element of the table? <> iii) if a new element is created in the table, is the CE still=20 subscribed for the event to that element? (The real gotcha here is that we probably want the answer to iii to=20 be yes. But I don't know how to do that easily while still allowing=20 the CE to unsubscribe to a specific element.) Now, if the CE has subscribe to the event for the table, the CE can=20 set thresholds for the event on a per element basis. As you say, it would seem simple and natural for the CE to set=20 thresholds or filters for the table as a whole. However, the meaning if the CE also sets a condition on a specific=20 element is even more confusion than the above. <> 1) Suppose that the CE has subscribed to the table with filter=20 C1. And then subscribes to an element with C2. Does it get notified=20 if C1 or C2 occurs (as would be the case if the subscription to the=20 element listed conditions C1 and C2)? Or does the CE only receive=20 the notification if C2 occurs (the condition on the element, ignoring=20 the table. <> 2) What if the CE has subscribed to the table and the element with=20 the same condition, but different parameters (different hysteresis,=20 or a different suppress count, or... Does the specific one=20 apply? Does whichever one goes off apply? <> I was trying to avoid that complexity. It may be that we can not avoid it. <> Yours, Joel At 11:51 AM 4/4/2006, Deleganes, Ellen M wrote: >Joel, > >I see from Section 4.7.6.1 that you can assign the same event to all >elements in the table by having the element contain a >name rather than a numeric field. Can the name be arbitrary, so long as >it doesn't conflict with any field or structure names used within the >LFB? > >Given that you can assign the same event for all elements in a table, >I'm a little surprised that you can't set the threshold at the same time >that applies to all elements. This could lead to the following >confusion, though. If one is able to subscribe to an event for all >elements in the table, what does exceeding the threshold mean? Is the >report generated when the sum of the events for any element in the table >exceeds the threshold? Or is it only when the threshold is exceeded for >the event for a particular element in the table? (The former would be >more difficult to implement because now you have to keep a sum across >the events for all elements in the table.) > >I am also assuming from your comment that it is possible that multiple >events could be assigned to an element in an array, or to the array >itself. In this case, one would have to subscribe to the different >events one at a time. > >Regards, >Ellen 2006 Message-Id: Date: Tue, 4 Apr 2006 20:29:20 -0400 From: "Joel M. Halpern" Subject: Re: Model: Filtering Comments: To: "Deleganes, Ellen M" intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed When an event definition is used for a table element, with a name for the subscript, then the definition is indicating that the event is defined for each extant element of the table. A CE can subscribe to that event for any individual element of the table, or it can subscribe to the event for the entire table. ** Note that we have not defined what happens if the CE: a) subscribes to the event for the entire table b) and then unsubscribes to the event for a specific element. We should probably define this explicitly, with regard to: i) Is the CE still listed as subscribed to the event for the table? ii) is the CE listed as subscribed to the event for each element of the table? iii) if a new element is created in the table, is the CE still subscribed for the event to that element? (The real gotcha here is that we probably want the answer to iii to be yes. But I don't know how to do that easily while still allowing the CE to unsubscribe to a specific element.) Now, if the CE has subscribe to the event for the table, the CE can set thresholds for the event on a per element basis. As you say, it would seem simple and natural for the CE to set thresholds or filters for the table as a whole. However, the meaning if the CE also sets a condition on a specific element is even more confusion than the above. 1) Suppose that the CE has subscribed to the table with filter C1. And then subscribes to an element with C2. Does it get notified if C1 or C2 occurs (as would be the case if the subscription to the element listed conditions C1 and C2)? Or does the CE only receive the notification if C2 occurs (the condition on the element, ignoring the table. 2) What if the CE has subscribed to the table and the element with the same condition, but different parameters (different hysteresis, or a different suppress count, or... Does the specific one apply? Does whichever one goes off apply? I was trying to avoid that complexity. It may be that we can not avoid it. Yours, Joel At 11:51 AM 4/4/2006, Deleganes, Ellen M wrote: >Joel, > >I see from Section 4.7.6.1 that you can assign the same event to all >elements in the table by having the element contain a >name rather than a numeric field. Can the name be arbitrary, so long as >it doesn't conflict with any field or structure names used within the >LFB? > >Given that you can assign the same event for all elements in a table, >I'm a little surprised that you can't set the threshold at the same time >that applies to all elements. This could lead to the following >confusion, though. If one is able to subscribe to an event for all >elements in the table, what does exceeding the threshold mean? Is the >report generated when the sum of the events for any element in the table >exceeds the threshold? Or is it only when the threshold is exceeded for >the event for a particular element in the table? (The former would be >more difficult to implement because now you have to keep a sum across >the events for all elements in the table.) > >I am also assuming from your comment that it is possible that multiple >events could be assigned to an element in an array, or to the array >itself. In this case, one would have to subscribe to the different >events one at a time. > >Regards, >Ellen 2006 Message-Id: Date: Tue, 4 Apr 2006 08:51:55 -0700 From: "Deleganes, Ellen M" Subject: Re: Model: Filtering Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joel, I see from Section 4.7.6.1 that you can assign the same event to all elements in the table by having the element contain a name rather than a numeric field. Can the name be arbitrary, so long as it doesn't conflict with any field or structure names used within the LFB?=20 Given that you can assign the same event for all elements in a table, I'm a little surprised that you can't set the threshold at the same time that applies to all elements. This could lead to the following confusion, though. If one is able to subscribe to an event for all elements in the table, what does exceeding the threshold mean? Is the report generated when the sum of the events for any element in the table exceeds the threshold? Or is it only when the threshold is exceeded for the event for a particular element in the table? (The former would be more difficult to implement because now you have to keep a sum across the events for all elements in the table.) I am also assuming from your comment that it is possible that multiple events could be assigned to an element in an array, or to the array itself. In this case, one would have to subscribe to the different events one at a time. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Monday, April 03, 2006 6:18 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Model: Filtering [Hit send too soon.] The model supports subscribing to an event for all elements of the table. The model does not support subscribing to all events for a given=20 table. (The ID structure is such that there is no ID for a subscribe=20 element that would mean that.) The question I was raising is whether one should be able to set the=20 thresholds for an event for all elements of a table. Yours, Joel M. Halpern At 02:51 PM 4/3/2006, Jamal Hadi Salim wrote: >On Sun, 2006-02-04 at 18:16 -0400, Joel M. Halpern wrote: > > The current thresholding and general filtering is defined only at the > > individual event level. Filters can not be set on an entire array of > > events (although a CE can subscribe to the entire array of events.) > > This is noted in an editor's note at the end of section 4.7.6.1 as a > > limitation. > > > >Not sure i followed. One should be able to target a table and subscribe >for "all events on the table", no? 2006 Message-Id: Date: Mon, 3 Apr 2006 21:18:30 -0400 Comments: RFC822 error: MESSAGE-ID field duplicated. Last occurrence was retained. From: "Joel M. Halpern" Subject: Re: Model: Filtering Comments: To: hadi@znyx.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed [Hit send too soon.] The model supports subscribing to an event for all elements of the table. The model does not support subscribing to all events for a given table. (The ID structure is such that there is no ID for a subscribe element that would mean that.) The question I was raising is whether one should be able to set the thresholds for an event for all elements of a table. Yours, Joel M. Halpern At 02:51 PM 4/3/2006, Jamal Hadi Salim wrote: >On Sun, 2006-02-04 at 18:16 -0400, Joel M. Halpern wrote: > > The current thresholding and general filtering is defined only at the > > individual event level. Filters can not be set on an entire array of > > events (although a CE can subscribe to the entire array of events.) > > This is noted in an editor's note at the end of section 4.7.6.1 as a > > limitation. > > > >Not sure i followed. One should be able to target a table and subscribe >for "all events on the table", no? 2006 Message-Id: Date: Mon, 3 Apr 2006 21:16:41 -0400 From: "Joel M. Halpern" Subject: Re: Model: Filtering Comments: To: hadi@znyx.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The model supports subscribing to an event for all elements of the table. The model At 02:51 PM 4/3/2006, Jamal Hadi Salim wrote: >On Sun, 2006-02-04 at 18:16 -0400, Joel M. Halpern wrote: > > The current thresholding and general filtering is defined only at the > > individual event level. Filters can not be set on an entire array of > > events (although a CE can subscribe to the entire array of events.) > > This is noted in an editor's note at the end of section 4.7.6.1 as a > > limitation. > > > >Not sure i followed. One should be able to target a table and subscribe >for "all events on the table", no? 2006 Message-Id: Date: Mon, 3 Apr 2006 21:14:51 -0400 From: "Joel M. Halpern" Subject: Re: Model: derivedFrom Comments: To: hadi@znyx.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed is the inheritance mechanism. You include it, with the name of the parent as the content, in a definition. That means that the definition is a child of the named parent. An instance of the child has all the properties of the parent, and any additional items declared in the child. Inheritance only allows for augmentation. A child can not override parent element declaration except for extension. To elaborate on the extension, suppose one has a structure definition X, and a structure definition Y derived from X. Then one has an LFB Class definition A, with an element I of type X. One can have an LFB Class definition B derivedFrom A. B can add new elements. It can also declare that I is of type Y rather than X. However, it can not change I from a struct to an array, or to some other struct that is not a child of X. This is actually defined in the document. I can easily believe that the wording is not clear, and would appreciate suggested text. Yours, Joel M. Halpern PS: As far as I can tell, this can be treated independently of versioning. Thinking by others to confirm or contradict that would be a good idea. At 02:42 PM 4/3/2006, Jamal Hadi Salim wrote: >On Sun, 2006-02-04 at 18:15 -0400, Joel M. Halpern wrote: > > The description of in section 4.7.1 has an editor's > > note about versions. > > > > We have no useful description of versioning. (See separate item.) > > > > I propose to simply remove the editor's ntoe that says that > > derivedFrom needs a version reference. I think it doesn't need a > > version reference. The only reason for a version number would be to > > say "this is only useful with versions of the parent after version > > X." That is probably rarely needed, and would significantly > > complicate the XML. (Every derivedFrom would have a and > > element, even if the parentVersion were 1.0.) > > > >Isnt this needed for inheritance? >BTW, that is not very clear how inheritance is going to be done. I have >always been worried about inheritance and augmentation as things that >may be hand-waved; i think i can see augmentation via #include maybe? >It would have very useful to have examples of xml that shows the two >features maybe? Or even dilute their references somehow. > >cheers, >jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 14:51:04 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model: Filtering Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-02-04 at 18:16 -0400, Joel M. Halpern wrote: > The current thresholding and general filtering is defined only at the > individual event level. Filters can not be set on an entire array of > events (although a CE can subscribe to the entire array of events.) > This is noted in an editor's note at the end of section 4.7.6.1 as a > limitation. > Not sure i followed. One should be able to target a table and subscribe for "all events on the table", no? > I propose to change this to simply state the restriction. > If folks feel strongly that we need to allow such filtering, speak > up. In particular, we need to be careful about what happens if the > filter is defined both on the array and on the individual element, > with different conditions or different values of the conditions. > > There is also a note in 4.8.3.3 asking for a better description of > the event count filtering algorithm. > > I propose to remove the note. If someone sends a better description, > I will use it. > I am waiting for the dust to settle then plan to read the doc back2back. I think i may have seen that text too many times and sometimes staying away from it for a while is helpful to see it in a different light. Hopefully other people will comment. cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 14:47:53 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model: Event BaseID Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-02-04 at 18:14 -0400, Joel M. Halpern wrote: > In section 4.7.6 there is a description of how the baseID for events > is defined and used. > There is an alternative described in the editor's note. > > If no one speaks up, I will remove the editor's note and go with what is there. > The main issue seems to be related to inheritance. Inheritance seems to spring in a few places with unanswered questions. As i suggested in earlier email, we should probably make it out of scope perhaps for this revision? No harm in talking about it, but the model semantics shouldnt expect it. cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 14:45:20 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model: String properties Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-02-04 at 18:21 -0400, Joel M. Halpern wrote: > This is not actually an existing editors note. > > While going through this, I realized that the element properties > (4.8.1, 4.8.2, and 4.8.3) had nothing about String and > octetstring. Those are variable length items. It seems to me useful > to be able to get the length without getting the string. It also > seems useful to know what limit the FE places on the length (since it > may be a smaller limit than the LFB calls for.) > > So I propose to add a String / Octetstring Properties section to this > part, giving those additional pieces of information. reasonable. cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 14:44:35 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model: Versioning Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-02-04 at 18:16 -0400, Joel M. Halpern wrote: > The description of LFB Versioning is section 3.2.7 is very > vague. There ought to be an editor's note indicating that more text > is needed. So I am pretending the note is there. > > I propose to add additional text after the last sentence of the first > paragraph. > The version number for C' only relates to the information added > by the class C'. It does not > relate to the information in the base class C. The C portion of > a C' instance will be of the version > of C supported by the FE. > > I propose to add an additional short paragraph that reads: > Versioning is not technically restricted by backwards > compatibility. Any change can be made. > It is anticipated that versioning will only be used to change the > type of an element, or to remove > information that has been determined to be no longer > useful. Adding elements is better > handled through the inheritance mechanism. > > I will also add an LFBVersion element to the SupportLFBType > information in the FE Object. Reasonable. Note, we have always had it as indicated in the xml i posted. cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 14:42:23 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model: derivedFrom Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-02-04 at 18:15 -0400, Joel M. Halpern wrote: > The description of in section 4.7.1 has an editor's > note about versions. > > We have no useful description of versioning. (See separate item.) > > I propose to simply remove the editor's ntoe that says that > derivedFrom needs a version reference. I think it doesn't need a > version reference. The only reason for a version number would be to > say "this is only useful with versions of the parent after version > X." That is probably rarely needed, and would significantly > complicate the XML. (Every derivedFrom would have a and > element, even if the parentVersion were 1.0.) > Isnt this needed for inheritance? BTW, that is not very clear how inheritance is going to be done. I have always been worried about inheritance and augmentation as things that may be hand-waved; i think i can see augmentation via #include maybe? It would have very useful to have examples of xml that shows the two features maybe? Or even dilute their references somehow. cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 14:33:54 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model: LFB Attribute Manipulation Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-02-04 at 18:14 -0400, Joel M. Halpern wrote: > Section 7 of the document has text about FE topology. I will clean > that up to clarify that the FE topology information comes from a > combination of the configured neighbor table, LFBs that support > neighbor discovery, and CE based operations. > Reasonable - For Refer to my desire to review the FEO and the sample FEO xml i posted for this section. As i mentioned earlier, it is possible to also have >1 interface between neighboring FEs within the same broadcast domain. > Section 7.6 specifically says that it is a place-holder. Obviously, > that can not stay as is. There is also an editor's note about > additional operations, which really is a protocol note. > > I propose to replace the contents of section 7.6 with a short section > indicating that the identifiers declared by LFB Classes, using the > model schema, are used by the protocol to reference and manipulate > LFB attributes. > Reasonable cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 14:30:07 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model: Class name uniqueness Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-02-04 at 18:14 -0400, Joel M. Halpern wrote: > The LFB Schema provides for naming of LFB Class Definitions in the > element of the Element of the > element. This is described in section 4.7. > > In order for names to be useful, they need to be unique across all > documents. This is not a protocol constraint, as the protocol uses > only the numbers. We could create a multi-part naming structure for > LFB Classes. I would prefer not to. > The simplest way I can see to do this is to create an IANA registry > of LFB Class Names and IDs. This will avoid collision of either > names or numbers. > > I propose replacing the editors note with a paragraph that indicates > that an IANA registry will be created. > I will also add text to section 4.7 referring to the class ID, and > indicating that the ID is also included in the registry. > I will add an IANA considerations section creating the registry, and > an appendix putting IDs 1 and 2 (for the FE Object and the FE > Protocol Object) into the registry. > I think we would need an IANA registry; with some IDs reserved to be private. Keeping both name and ID as unique is valuable (although in our implementation, from a code level todate, we have respected only the ID). cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 14:26:45 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model: LFB Definitions Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-02-04 at 18:12 -0400, Joel M. Halpern wrote: > The model draft currently says that it will contain a list of LFBs to > meet the requirements of the requirements document. It says this at > the end of the introduction to section 6. > > There is an editor's note calling for a reference. Instead, I intend > to remove the paragraph, as the model no longer contains the > library. In fact, I will remove the rest of section 6, and instead > indicate that a separate document or set of documents will be used to > fulfill the requirements given. > Joel, it does seem fair to just remove paragraph above section 6.1; the one that starts with "The FE model also .." The rest of the text seems reasonable since all it does is provide examples listed from the requirements RFC. The only conflict would be in referencing a document that is incomplete for the list of LFBs - I hope that doesnt slow down progress. In hindsight the list of LFBs should probably never have been in the requirements, rather should have been part of the WG charter or even a revision of the charters next steps. cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 14:21:08 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model: Configured Neighbor Table[3] Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-02-04 at 18:11 -0400, Joel M. Halpern wrote: > The configured neighbor table (section 5.3.4) is probably > wrong. This table is NOT intended to represent information from > discovery protocols. It is intended to allow an FE to be configured > with information about neighbor FEs. > > [Prejudicial aside: I have argued on the list that this is not > necessary. I lost the argument, so I can not simply remove the section.] > I really think we oughta review this (you know my views on this subject since i have expressed them many times). Who wanted to insist on MAC addresses for example? I hope its not our friends from the NPF. > I need some input on what to put here. > Refer to the FEobject for how we have been using it. cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 14:18:53 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model: default value specification[2] Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-02-04 at 18:09 -0400, Joel M. Halpern wrote: > We have no syntax defined for specify the default value of something > that is byte[n] or octetstring[n]. > This absence is mentioned in the editor's note in section 4.7.4. > > I propose to remove the note and ignore the problem. > ACK from here. cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 14:16:35 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Model: FE Attributes [1] Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-02-04 at 18:09 -0400, Joel M. Halpern wrote: > Section 5.3 notes that the FE Attributes in the FE Object is woefully > incomplete. > I believe this to be true. > However, without input I can not repair this. > > In the absence of text I will remove the note and we will simply be > insufficient. Infact the FEobject itself has undergone a few changes over time. Ive attached the variant we use (unfortunately old syntax still until this dust settles; hopefully that doesnt distract the message). I note Weiming said he was going to have something to say about this; however, can we have a more fuller review of the FEObject? This may settle a few of this The only thing, off top of my head, that i will change is add ability to add more interfaces to neighboring FEs (we could have anywhere between 1-4 single hop in our setup) cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 14:00:33 -0400 From: Jamal Hadi Salim Organization: ZNYX Networks Subject: Re: Outstanding Model issues Comments: To: "Joel M. Halpern" Content-Type: text/plain Mime-Version: 1.0 Content-Transfer-Encoding: 7bit On Sun, 2006-02-04 at 18:13 -0400, Joel M. Halpern wrote: [..] > If no one speaks up, the resolution will be applied to the > document. (I realize that silence does not equal consent. But I > have to resolve the items somehow. And you still get the chance to > complain at WG last call and again at IETF last call...) > Good idea Joel. I am hoping this will speed up any protocol level concerns at IESG. > There are 11 notes to follow. I will pace them to try to avoid > tripping any email filters. > Your emails arrived out of order (this was the 4th one for example). I will go sequantially and hope the order of response is not a big deal. Would be a good idea next time if order matters to enumerate them in the subject as well. cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 11:46:17 -0700 From: "Deleganes, Ellen M" Subject: Re: Model: String properties Comments: To: hadi@znyx.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Joel and Jamal. Adding a properties section to include the length and the limits an FE places on the length are reasonable items to add. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim Sent: Monday, April 03, 2006 11:45 AM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Re: Model: String properties On Sun, 2006-02-04 at 18:21 -0400, Joel M. Halpern wrote: > This is not actually an existing editors note. >=20 > While going through this, I realized that the element properties=20 > (4.8.1, 4.8.2, and 4.8.3) had nothing about String and=20 > octetstring. Those are variable length items. It seems to me useful=20 > to be able to get the length without getting the string. It also=20 > seems useful to know what limit the FE places on the length (since it=20 > may be a smaller limit than the LFB calls for.) >=20 > So I propose to add a String / Octetstring Properties section to this=20 > part, giving those additional pieces of information. reasonable. cheers, jamal 2006 Message-Id: Date: Mon, 3 Apr 2006 11:43:58 -0700 From: "Deleganes, Ellen M" Subject: Re: Model: Class name uniqueness Comments: To: "Joel M. Halpern" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Joel's proposal. Although it will take longer to get an IANA registry approved, this seems to be the better approach than to further complicate the naming structure for LFB classes. Regards, Ellen -----Original Message----- From: Forwarding and Control Element Separation [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern Sent: Sunday, April 02, 2006 3:14 PM To: FORCES@PEACH.EASE.LSOFT.COM Subject: Model: Class name uniqueness The LFB Schema provides for naming of LFB Class Definitions in the=20 element of the Element of the =20 element. This is described in section 4.7. In order for names to be useful, they need to be unique across all=20 documents. This is not a protocol constraint, as the protocol uses=20 only the numbers. We could create a multi-part naming structure for=20 LFB Classes. I would prefer not to. The simplest way I can see to do this is to create an IANA registry=20 of LFB Class Names and IDs. This will avoid collision of either=20 names or numbers. I propose replacing the editors note with a paragraph that indicates=20 that an IANA registry will be created. I will also add text to section 4.7 referring to the class ID, and=20 indicating that the ID is also included in the registry. I will add an IANA considerations section creating the registry, and=20 an appendix putting IDs 1 and 2 (for the FE Object and the FE=20 Protocol Object) into the registry. Yours, Joel M. Halpern 2006 Message-Id: Date: Mon, 3 Apr 2006 09:49:02 +0800 From: "Wang,Weiming" Subject: Re: Model: FE Attributes MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Joel, I may be able to input something soon in this regards. thanks, Weiming ----- Original Message ----- From: "Joel M. Halpern" Sent: Monday, April 03, 2006 6:09 AM Subject: Model: FE Attributes > Section 5.3 notes that the FE Attributes in the FE Object is woefully > incomplete. > I believe this to be true. > However, without input I can not repair this. > > In the absence of text I will remove the note and we will simply be > insufficient. > > Yours, > Joel M. Halpern 2006 Message-Id: Date: Sun, 2 Apr 2006 18:21:25 -0400 From: "Joel M. Halpern" Subject: Model: String properties Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed This is not actually an existing editors note. While going through this, I realized that the element properties (4.8.1, 4.8.2, and 4.8.3) had nothing about String and octetstring. Those are variable length items. It seems to me useful to be able to get the length without getting the string. It also seems useful to know what limit the FE places on the length (since it may be a smaller limit than the LFB calls for.) So I propose to add a String / Octetstring Properties section to this part, giving those additional pieces of information. Yours, Joel M. Halpern 2006 Message-Id: Date: Sun, 2 Apr 2006 18:16:34 -0400 From: "Joel M. Halpern" Subject: Model: Versioning Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The description of LFB Versioning is section 3.2.7 is very vague. There ought to be an editor's note indicating that more text is needed. So I am pretending the note is there. I propose to add additional text after the last sentence of the first paragraph. The version number for C' only relates to the information added by the class C'. It does not relate to the information in the base class C. The C portion of a C' instance will be of the version of C supported by the FE. I propose to add an additional short paragraph that reads: Versioning is not technically restricted by backwards compatibility. Any change can be made. It is anticipated that versioning will only be used to change the type of an element, or to remove information that has been determined to be no longer useful. Adding elements is better handled through the inheritance mechanism. I will also add an LFBVersion element to the SupportLFBType information in the FE Object. Yours, Joel M. Halpern 2006 Message-Id: Date: Sun, 2 Apr 2006 18:16:23 -0400 From: "Joel M. Halpern" Subject: Model: Filtering Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The current thresholding and general filtering is defined only at the individual event level. Filters can not be set on an entire array of events (although a CE can subscribe to the entire array of events.) This is noted in an editor's note at the end of section 4.7.6.1 as a limitation. I propose to change this to simply state the restriction. If folks feel strongly that we need to allow such filtering, speak up. In particular, we need to be careful about what happens if the filter is defined both on the array and on the individual element, with different conditions or different values of the conditions. There is also a note in 4.8.3.3 asking for a better description of the event count filtering algorithm. I propose to remove the note. If someone sends a better description, I will use it. Yours, Joel M. Halpern 2006 Message-Id: Date: Sun, 2 Apr 2006 18:15:21 -0400 From: "Joel M. Halpern" Subject: Model: derivedFrom Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The description of in section 4.7.1 has an editor's note about versions. We have no useful description of versioning. (See separate item.) I propose to simply remove the editor's ntoe that says that derivedFrom needs a version reference. I think it doesn't need a version reference. The only reason for a version number would be to say "this is only useful with versions of the parent after version X." That is probably rarely needed, and would significantly complicate the XML. (Every derivedFrom would have a and element, even if the parentVersion were 1.0.) Yours, Joel M. Halpern 2006 Message-Id: Date: Sun, 2 Apr 2006 18:14:21 -0400 From: "Joel M. Halpern" Subject: Model: LFB Attribute Manipulation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Section 7 of the document has text about FE topology. I will clean that up to clarify that the FE topology information comes from a combination of the configured neighbor table, LFBs that support neighbor discovery, and CE based operations. Section 7.6 specifically says that it is a place-holder. Obviously, that can not stay as is. There is also an editor's note about additional operations, which really is a protocol note. I propose to replace the contents of section 7.6 with a short section indicating that the identifiers declared by LFB Classes, using the model schema, are used by the protocol to reference and manipulate LFB attributes. Yours, Joel M. Halpern 2006 Message-Id: Date: Sun, 2 Apr 2006 18:14:21 -0400 From: "Joel M. Halpern" Subject: Model: Event BaseID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed In section 4.7.6 there is a description of how the baseID for events is defined and used. There is an alternative described in the editor's note. If no one speaks up, I will remove the editor's note and go with what is there. Yours, Joel M. Halpern 2006 Message-Id: Date: Sun, 2 Apr 2006 18:14:10 -0400 From: "Joel M. Halpern" Subject: Model: Class name uniqueness Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The LFB Schema provides for naming of LFB Class Definitions in the element of the Element of the element. This is described in section 4.7. In order for names to be useful, they need to be unique across all documents. This is not a protocol constraint, as the protocol uses only the numbers. We could create a multi-part naming structure for LFB Classes. I would prefer not to. The simplest way I can see to do this is to create an IANA registry of LFB Class Names and IDs. This will avoid collision of either names or numbers. I propose replacing the editors note with a paragraph that indicates that an IANA registry will be created. I will also add text to section 4.7 referring to the class ID, and indicating that the ID is also included in the registry. I will add an IANA considerations section creating the registry, and an appendix putting IDs 1 and 2 (for the FE Object and the FE Protocol Object) into the registry. Yours, Joel M. Halpern 2006 Message-Id: Date: Sun, 2 Apr 2006 18:13:05 -0400 From: "Joel M. Halpern" Subject: Outstanding Model issues Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed I will be sending separate messages for each outstanding editor's note in the Forces Model document. Each note will describe with issue, and describe the proposed resolution. Each note will include "Model:" in the subject. I will include the section number where the editors note occurs early in the description. If no one speaks up, the resolution will be applied to the document. (I realize that silence does not equal consent. But I have to resolve the items somehow. And you still get the chance to complain at WG last call and again at IETF last call...) There are 11 notes to follow. I will pace them to try to avoid tripping any email filters. Yours, Joel M. Halpern 2006 Message-Id: Date: Sun, 2 Apr 2006 18:12:14 -0400 From: "Joel M. Halpern" Subject: Model: LFB Definitions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The model draft currently says that it will contain a list of LFBs to meet the requirements of the requirements document. It says this at the end of the introduction to section 6. There is an editor's note calling for a reference. Instead, I intend to remove the paragraph, as the model no longer contains the library. In fact, I will remove the rest of section 6, and instead indicate that a separate document or set of documents will be used to fulfill the requirements given. Yours, Joel M. Halpern 2006 Message-Id: Date: Sun, 2 Apr 2006 18:11:04 -0400 From: "Joel M. Halpern" Subject: Model: Configured Neighbor Table Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The configured neighbor table (section 5.3.4) is probably wrong. This table is NOT intended to represent information from discovery protocols. It is intended to allow an FE to be configured with information about neighbor FEs. [Prejudicial aside: I have argued on the list that this is not necessary. I lost the argument, so I can not simply remove the section.] I need some input on what to put here. Yours, Joel M. Halpern 2006 Message-Id: Date: Sun, 2 Apr 2006 18:09:37 -0400 From: "Joel M. Halpern" Subject: Model: FE Attributes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Section 5.3 notes that the FE Attributes in the FE Object is woefully incomplete. I believe this to be true. However, without input I can not repair this. In the absence of text I will remove the note and we will simply be insufficient. Yours, Joel M. Halpern 2006 Message-Id: Date: Sun, 2 Apr 2006 18:09:37 -0400 From: "Joel M. Halpern" Subject: Model: default value specification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed We have no syntax defined for specify the default value of something that is byte[n] or octetstring[n]. This absence is mentioned in the editor's note in section 4.7.4. I propose to remove the note and ignore the problem. Alternative resolutions are sought. Yours, Joel M. Halpern