2006
Message-Id: <MON.10.APR.2006.140359.0530.>
Date: Mon, 10 Apr 2006 14:03:59 +0530
From: "Dutta, Pranjal" <pdutta@riverstonenet.com>
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

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi All,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks in advance,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Pranjal<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C65C79.83CABEF0--


2006
Message-Id: <MON.10.APR.2006.124410.0400.>
Date: Mon, 10 Apr 2006 12:44:10 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.10.APR.2006.115925.0400.>
Date: Mon, 10 Apr 2006 11:59:25 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: One question Linux Netlink as an IP Services Protocol (RFC 3549)
Comments: To: "Dutta, Pranjal" <pdutta@riverstonenet.com>
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: <MON.10.APR.2006.115535.0400.>
Date: Mon, 10 Apr 2006 11:55:35 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Model: Filtering
Comments: To: Ellen M <ellen.m.deleganes@intel.com>, "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.10.APR.2006.083302.0400.>
Date: Mon, 10 Apr 2006 08:33:02 -0400
From: =?gb2312?Q?Dong_Ligang?= <donglg@MAIL.HZIC.EDU.CN>
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" <dro@zurich.ibm.com>
> 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" <dro@zurich.ibm.com>
> > > 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: <FRI.7.APR.2006.142719.0400.>
Date: Fri, 7 Apr 2006 14:27:19 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: Model: Filtering
Comments: To: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com> 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: <FRI.7.APR.2006.141327.0400.>
Date: Fri, 7 Apr 2006 14:13:27 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: Model: Filtering
Comments: To: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com> 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.
><<Ellen - maybe it doesn't make sense to be able to set filters or
>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: <FRI.7.APR.2006.114510.0800.>
Date: Fri, 7 Apr 2006 11:45:10 +0800
From: "Wang,Weiming" <wmwang@mail.zjgsu.edu.cn>
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" <wmwang@mail.zjgsu.edu.cn>
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" <dro@zurich.ibm.com>
> 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" <dro@zurich.ibm.com>
> > > 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: <FRI.7.APR.2006.112134.0700.>
Date: Fri, 7 Apr 2006 11:21:34 -0700
From: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>
Subject: Re: Model: Filtering
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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.
><<Ellen - maybe it doesn't make sense to be able to set filters or
>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: <FRI.7.APR.2006.094822.0700.>
Date: Fri, 7 Apr 2006 09:48:22 -0700
From: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>
Subject: Re: Model: Filtering
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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.
<<Ellen - This seems like a pain to support, can you think of a usage
case where the CE might want to subscribe to an event for the majority
of the elements of a table, but not all? Or to later unsubscribe to an
event for a specific element? If so, then the model needs to be able to
support this.>>

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?
<<Ellen - I would say maybe to i), but no to ii). If you could say yes
to i), then it may be easier to support the scenario you point out in
iii). I don't think you need ii) if you define i). I envision this to be
a hierarchical scheme where i) is the default, but an individual element
could override the default setting. Wasn't this done in the schema
somewhere else?>>
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.
<<Ellen - agree with the above that it is even more complicated and
confusing.>>
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.
<<Ellen - I'm not exactly sure that I follow your scenario above. Here
are a few different interpretations of the scenario: CE subscribed to
event E1 for the table that has filter C1, where element X in the table
set a filter C2 for the same event. I would expect that the CE would get
notified in the case either when event E1 for an element in the table
(not X) met the conditions for filter C1 or event E1 met the conditions
for filter C2 for element X. The CE would also be notified where either
C1 or C2 occurred for element X in the case where C2 was set for an
event other than E1. The CE would not be notified if C1 and C2 occurred
on element X for event E1.>>
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?
<<Ellen - My assumption is that if different parameters are set for a
particular element in the table, it is treated like an override of the
"default" settings. Thus the "default" setting for the table no longer
applies to that element, and only the new settings apply. I think that
would be simpler than using some hybrid approach.>>

I was trying to avoid that complexity.  It may be that we can not avoid
it.
<<Ellen - maybe it doesn't make sense to be able to set filters or
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?>>

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 <eventSubscript> 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: <TUE.4.APR.2006.202920.0400.>
Date: Tue, 4 Apr 2006 20:29:20 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: Model: Filtering
Comments: To: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com> 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 <eventSubscript> 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: <TUE.4.APR.2006.085155.0700.>
Date: Tue, 4 Apr 2006 08:51:55 -0700
From: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>
Subject: Re: Model: Filtering
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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 <eventSubscript> 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: <MON.3.APR.2006.211830.0400.>
Date: Mon, 3 Apr 2006 21:18:30 -0400
Comments: RFC822 error: <W> MESSAGE-ID field duplicated. Last occurrence was retained.
From: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.3.APR.2006.211641.0400.>
Date: Mon, 3 Apr 2006 21:16:41 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.3.APR.2006.211451.0400.>
Date: Mon, 3 Apr 2006 21:14:51 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: Model: derivedFrom
Comments: To: hadi@znyx.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

<derivedFrom> 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 <derivedFrom> 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 <parentName> and
> > <parentVersion> 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: <MON.3.APR.2006.145104.0400.>
Date: Mon, 3 Apr 2006 14:51:04 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Model: Filtering
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.3.APR.2006.144753.0400.>
Date: Mon, 3 Apr 2006 14:47:53 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Model: Event BaseID
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.3.APR.2006.144520.0400.>
Date: Mon, 3 Apr 2006 14:45:20 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Model: String properties
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.3.APR.2006.144435.0400.>
Date: Mon, 3 Apr 2006 14:44:35 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Model: Versioning
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.3.APR.2006.144223.0400.>
Date: Mon, 3 Apr 2006 14:42:23 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Model: derivedFrom
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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 <derivedFrom> 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 <parentName> and
> <parentVersion> 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: <MON.3.APR.2006.143354.0400.>
Date: Mon, 3 Apr 2006 14:33:54 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Model: LFB Attribute Manipulation
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.3.APR.2006.143007.0400.>
Date: Mon, 3 Apr 2006 14:30:07 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Model: Class name uniqueness
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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
> <name> element of the <LFBClassDef> Element of the <LFBClassDefs>
> 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: <MON.3.APR.2006.142645.0400.>
Date: Mon, 3 Apr 2006 14:26:45 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Model: LFB Definitions
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.3.APR.2006.142108.0400.>
Date: Mon, 3 Apr 2006 14:21:08 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Model: Configured Neighbor Table[3]
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.3.APR.2006.141853.0400.>
Date: Mon, 3 Apr 2006 14:18:53 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Model: default value specification[2]
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.3.APR.2006.141635.0400.>
Date: Mon, 3 Apr 2006 14:16:35 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Model: FE Attributes [1]
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.3.APR.2006.140033.0400.>
Date: Mon, 3 Apr 2006 14:00:33 -0400
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: Outstanding Model issues
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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: <MON.3.APR.2006.114617.0700.>
Date: Mon, 3 Apr 2006 11:46:17 -0700
From: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>
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: <MON.3.APR.2006.114358.0700.>
Date: Mon, 3 Apr 2006 11:43:58 -0700
From: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>
Subject: Re: Model: Class name uniqueness
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
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
<name> element of the <LFBClassDef> Element of the <LFBClassDefs>=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: <MON.3.APR.2006.094902.0800.>
Date: Mon, 3 Apr 2006 09:49:02 +0800
From: "Wang,Weiming" <wmwang@mail.zjgsu.edu.cn>
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" <joel@stevecrocker.com>
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: <SUN.2.APR.2006.182125.0400.>
Date: Sun, 2 Apr 2006 18:21:25 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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: <SUN.2.APR.2006.181634.0400.>
Date: Sun, 2 Apr 2006 18:16:34 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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: <SUN.2.APR.2006.181623.0400.>
Date: Sun, 2 Apr 2006 18:16:23 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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: <SUN.2.APR.2006.181521.0400.>
Date: Sun, 2 Apr 2006 18:15:21 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Model: derivedFrom
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

The description of <derivedFrom> 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 <parentName> and
<parentVersion> element, even if the parentVersion were 1.0.)

Yours,
Joel M. Halpern


2006
Message-Id: <SUN.2.APR.2006.181421.0400.>
Date: Sun, 2 Apr 2006 18:14:21 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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: <SUN.2.APR.2006.181421.0400.>
Date: Sun, 2 Apr 2006 18:14:21 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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: <SUN.2.APR.2006.181410.0400.>
Date: Sun, 2 Apr 2006 18:14:10 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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
<name> element of the <LFBClassDef> Element of the <LFBClassDefs>
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: <SUN.2.APR.2006.181305.0400.>
Date: Sun, 2 Apr 2006 18:13:05 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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: <SUN.2.APR.2006.181214.0400.>
Date: Sun, 2 Apr 2006 18:12:14 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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: <SUN.2.APR.2006.181104.0400.>
Date: Sun, 2 Apr 2006 18:11:04 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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: <SUN.2.APR.2006.180937.0400.>
Date: Sun, 2 Apr 2006 18:09:37 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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: <SUN.2.APR.2006.180937.0400.>
Date: Sun, 2 Apr 2006 18:09:37 -0400
From: "Joel M. Halpern" <joel@stevecrocker.com>
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