Subject: RE: [Forces-protocol] Header Section

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 22 Oct 2004 23:07:00 -0700

Sounds good, Jamal. Just wanted to make sure it got a pair of eyes on it
:)

BTW, I thought we had 3 bits for Priority in the Flags in the header.
When I just looked it was missing, 

Avri is this an XML problem with the draft??

Thanks
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 

On Fri, 2004-10-22 at 19:11, Khosravi, Hormuzd M wrote:
> Jamal,
> 
> Pls take care of the Header section, no one seems to be looking at it.
> 

Hormuzd,
Main comment on header was todo with version to remove the major minor
and just have one flat space. The other thing i dont remember is whether
we should get rid of the resvd field or not.
Some of the falgs need revisiting; however i think the revisit will make
more sense once the operations and data-path dust settles.

So my suggestion is lets have Avri make the changes to the major:minor
and probably get rid of the resvd field and leave the rest for the next
round.

Thoughts?

cheers,
jamal

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: [email-masked]
Date: Sat, 23 Oct 2004 02:45:25 -0400

> Avri is this an XML problem with the draft??

yes
fixed

i think i included Hormuzd's section 6 changes.

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

will include Weiming's latest changes after i receive them.

will try to do a read through and clean up + language edit tomorrow.

Are there any other changes that have been submitted that I have missed?

a.

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 23 Oct 2004 15:09:27 +0800

Avri,

Here is the updated xmls that incorparated comments from Robert.

thanks.
weiming

---

From: Robert Haas <[email-masked]>
Date: Sat, 23 Oct 2004 11:27:02 +0200

All,
Below is a new draft of the sections related to FE/Protocol LFBs. Please 
review.

I will also try to add a table summarizing the operations allowed in 
each type of PL message. I sent it in a previous message.

BTW, I find it a bit odd to have Query messages defined before Config 
messages in Section "Protocol Messages". Does anyone mind changing the 
order ?

Avri,
Please send the xml files once you have updated them. I'll then 
incorporate my text below directly taking suggestions/comments into 
account, unless you want to do it ;-)

BTW, we'll have to remove the State maintenance section and add a new 
chapter for these LFBs (new xml file ?).

Regards,
-Robert

-------------------------------------------------------------------------------------------------------------------
We can remove sections 3.3.2 and 3.3.3, and replace them with a single 
section that provides an overview of what these "special LFBs":

New section 3.3.2:

Whereas four key PL messages have a specific type assigned (Association 
Setup, Response, and Teardown, as well as Heartbeat) mostly for 
simplicity and monitoring reasons, all other PL messages follow the LFB 
structure as this provides more flexibility for future enhancements. In 
addition, this shows how the ForCES protocol itself can be controlled by 
the very same type of structures (LFBs) as it uses to control functions 
such as IP forwarding, filtering, etc.

To achieve this, the following LFBs are used: FE Protocol LFB, FE LFB, 
and CE LFB. These LFBs are detailed in Section XXX. An short description 
is provided here:

The FE Protocol LFB is a logical entity in each FE that is used to 
control the ForCES protocol. The CE operates on this LFB to subscribe or 
unsubscribe to Heartbeat messages, define the Heartbeat interval, or 
discover which ForCES protocol version and which TMLs the FE supports. 
The FE Protocol LFB also contains the various ForCES ID to be used: 
unicast IDs and table of the PL multicast IDs the FE must be listening to.
[TBD: I don't think we need a CE Protocol LFB]

The FE LFB (referred to as "FE attributes" in the model draft) should 
not be confused with the FE Protocol Object. The FE LFB is a logical 
entity in each FE and contains attributes relative to the FE itself, and 
not to the operation of the ForCES protocol between the CE and the FE. 
Such attributes can be FEState (refer to model draft), vendor, etc. The 
FE LFB contains in particular an table that maps a virtual LFB Instance 
ID to one or more Instance IDs of LFBs in the FE.

The CE LFB is the counterpart of the FE LFB. The CE LFB is a logical 
entity in each CE and contains attributes relative to the CE itself, and 
not to the operation of the ForCES protocol between the CE and the FE. 
This LFB can be used to convey event notifications from a CE to FEs. 
Some events may be sent by the CE without prior subscription by the FEs.

-------------------------------------------------------------------------------------------------------------------
The following section should be inserted just before the "Protocol 
Messages" section. It provides the detail (in english, not xml) of the LFBs.

Chapter X: FE, CE, and Protocol LFBs.

The following LFBs are used to control the operation of the ForCES 
protocol and interact with FEs and CEs.

Section X.1 FE Protocol LFB

The FE Protocol LFB is a logical entity in each FE that is used to 
control the ForCES protocol. The FE Protocol LFB can be manipulated 
using the standard PL messages. The FE Protocol LFB Class ID is assigned 
the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There 
must always be one and only one instance of the FE Protocol LFB in an 
FE. The values of the attributes in the FE Protocol LFB have pre-defined 
default values that are specified here. Unless explicit changes are made 
to these values using Config messages from the CE, these default values 
MUST be used for the operation of the protocol.

The FE Protocol Object consists of the following elements:
 
FE Protocol events that can be subscribed/unsubscribed:
    FE heartbeat
    FE TML events (TBD)
 FE Protocol capabilities (read-only):
    Supported ForCES protocol version(s) by the FE
    Supported ForCES FE model(s) by the FE
    Some TML capability description(s)
  FE Protocol attributes (can be read and set):
    Current version of the ForCES protocol
    Current version of the FE model
    FE unicast ID(s) (list)
    FE multicast ID(s) (list)
    Association Expiry Timer
    Heartbeat Interval
    Primary CE
    FE failover and restart policy

Section X.2

The FE LFB is a logical entity in each FE and contains attributes 
relative to the FE itself, and not to the operation of the ForCES 
protocol.  The FE LFB Class ID is assigned the value 0x2. The FE LFB 
Instance ID is assigned the value 0x1. There must always be one and only 
one instance of the FE LFB in an FE.

The FE LFB consists of the following elements:
 FE Events:
    FEAllEvents (subscribing to this corresponds to subscribing to all 
events below)
    FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failover)
    FE DoS alert
    FE capability change
  FE attributes:
    FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode 
[Note: this replies the State Maintenance messages])
    MIID table (a list of virtual LFB Instance IDs that map to a list of 
Instance IDs of LFBs in that FE [Refer to Zsolt's note])
    FE Behavior Exp. Timer
    HA Mode
    [the attributes below were previously under Query message]
    Inter-FE topology
    Intra-FE topology

Section X.3

The CE LFB is a logical entity in each CE and contains attributes 
relative to the CE itself, and not to the operation of the ForCES protocol.

The FE LFB consists of the following elements:
  CE Events:
    CEAllEvents (subscribing to this corresponds to subscribing to all 
events below) [Do we want to allow an FE to explicitely subscribe to CE 
events ?]
    CEStatusChange (events that signal CE 
Up/Down/Active/Inactive/Failover)  [Such events do not necessarily need 
to be subscribed to, they can fire even without subscription and inform 
the FE]

[TBD: what else do we need in the CE LFB ?]

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

---

From: "Weiming Wang" <[email-masked]>
Date: Sat, 23 Oct 2004 21:49:20 +0800

Hi Robert,

A general comment is:
I think the difference and the sameness of the FE protocol LFB and FE LFB with
the general FE model LFBs should be specifically addressed.

I can see the sameness is:

1. a LFB class id and an instance id are used to address them.
2. contains attributes, capabilities and events that can be operated via
protocol messages.

I can see the difference is:

1. These LFBs will be lunched along the time the FE is started, before first
ForCES protocol message is sent or received, and whose status  should not be
allowed being changed by protocol messages then. Any status operation toward
these LFBs will result in operation error.
2. a defaut value for these LFB attributes are needed , and the instance IDs for
these LFBs are also predefined (I suppose LFBs defined by FE model, whose
instance is configured by PL msg). (you'v described this point)
3. These LFBs will be defined as black blocks that do not have any input or
output ports from FE LFB topology viewpoint.
4. Followed 3, these LFBs will then not be included in FE LFB topology.

can now only think of these, we may have more later.

Some more comments pls see inline for.

regards,
weiming

----- Original Message -----
From: "Robert Haas" <[email-masked]>

All,

BTW, I find it a bit odd to have Query messages defined before Config
messages in Section "Protocol Messages". Does anyone mind changing the
order ?
[Weiming]It's ok to me, and I also see it's not very normal compared with other
systems. One difference with ForCES system is it' query message is first used
than config msg(query capability). Anyway, i agree to change.

Avri,

Regards,
-Robert

--------------------------------------------------------------------------------
-----------------------------------
We can remove sections 3.3.2 and 3.3.3, and replace them with a single
section that provides an overview of what these "special LFBs":

New section 3.3.2:

[Weiming]I just see some repeats here of this section with followed specific
section.

--------------------------------------------------------------------------------
-----------------------------------
The following section should be inserted just before the "Protocol
Messages" section. It provides the detail (in english, not xml) of the LFBs.

The following LFBs are used to control the operation of the ForCES
protocol and interact with FEs and CEs.
[Weiming]I think more description include the difference and the sameness of
these LFBs with FE model LFBs) should be described here.

The FE Protocol LFB is a logical entity in each FE that is used to
control the ForCES protocol. The FE Protocol LFB can be manipulated
using the standard PL messages.
[Weiming]Except the LFB state operations.

The FE Protocol LFB Class ID is assigned
the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There
must always be one and only one instance of the FE Protocol LFB in an
FE. The values of the attributes in the FE Protocol LFB have pre-defined
default values that are specified here. Unless explicit changes are made
to these values using Config messages from the CE, these default values
MUST be used for the operation of the protocol.
[Weiming] do we need to tell which attributes whose value should be preset
default values?

    FE unicast ID(s) (list)
    FE multicast ID(s) (list)
[Weiming] Can these two be one attribute, only with two tables?

    Association Expiry Timer
    Heartbeat Interval
    Primary CE
    FE failover and restart policy
[Weiming] I suppose to and CE failover or  leave policy, because it is
important. It will tell what FE will do if it finds it can not connect to a CE
and get command from it. By using this plicy, CE can in advance tell the FE to
go inactive, totally go down, or just do whatever it can (graceful restart?) if
CE fails.

Section X.2

The FE LFB consists of the following elements:
 FE Events:
    FEAllEvents (subscribing to this corresponds to subscribing to all
events below)
    FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failover)
    FE DoS alert
    FE capability change
  FE attributes:
    FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode
[Note: this replies the State Maintenance messages])
    MIID table (a list of virtual LFB Instance IDs that map to a list of
Instance IDs of LFBs in that FE [Refer to Zsolt's note])
    FE Behavior Exp. Timer
    HA Mode
    [the attributes below were previously under Query message]
    Inter-FE topology
    Intra-FE topology
[Weiming] although I'm not very sure of other's thoughts, I think the attribute
for FE DoS Protect policy should be needed.  This attribute will be transfered
to TML layer via something (API ?).

Section X.3

[Weiming] should be CE LFB?

[TBD: what else do we need in the CE LFB ?]
[Weiming] I see the CE LFB may only have events attributes appearing to FEs. I
don't think CE attributes should be defined.
--
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: [email-masked]
Date: Sat, 23 Oct 2004 14:17:15 -0400

On 23 okt 2004, at 05.27, Robert Haas wrote:

> All,
> Below is a new draft of the sections related to FE/Protocol LFBs. 
> Please review.

http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-01-4.txt
includes changes i have received so far and includes the text you sent.

> each type of PL message. I sent it in a previous message.

i missed that.  do you want me to build the table?

> messages in Section "Protocol Messages". Does anyone mind changing the 

Moved.

> account, unless you want to do it ;-)

with 1-2 days left to finish, i don't mind making the changes.  as i 
will be going through cleaning up format, fixing some xrefs and doing a 
language edit, it would be easiest at this point if people just send me 
text changes.

i.e. not whole new text, but something of the sort:

old text:
bla bla bla

new text:
better bla, better bla, better bla.

(regular unix diffs work just fine. :-)

but if this is not ok with you, then i will send youi the changed xml 
files.

> chapter for these LFBs (new xml file ?).

At an earlier request, i removed the State maintenance section (i 
think).  let me know what you want inserted.

i will probably put out another version later today/tonight.

cheers
a.

---

From: Robert Haas <[email-masked]>
Date: Sat, 23 Oct 2004 20:52:30 +0200

Weiming,
Thanks for your valuable comments. I'll send an update to the text 
shortly. See some answers in-line.
Regards,
-Robert

>4. Followed 3, these LFBs will then not be included in FE LFB topology.
Agreed.

>chapter for these LFBs (new xml file ?).
It's on purpose, because the section below will only appear a few pages 
later.

Done.

>[Weiming]Except the LFB state operations.
Agreed. Removed the sentence from text.

>[Weiming] do we need to tell which attributes whose value should be preset
We will have to describe each attribute in more details at some point. 
Not now.

>[Weiming] Can these two be one attribute, only with two tables?
FE unicast should actually not be a list (otherwise how does the FE 
decide which ID to use as Sender ?)

>go inactive, totally go down, or just do whatever it can (graceful restart?) if
I thought that what you decribed is actually captured under the name "FE 
failover and restart policy" Or what does that mean ?

>to TML layer via something (API ?).
Added.

>don't think CE attributes should be defined.
OK

---

From: Robert Haas <[email-masked]>
Date: Sat, 23 Oct 2004 20:53:42 +0200

All,
Attached is the text updated according to Weiming's comments.

Regards,
-Robert

New section 3.3.2:

The following section should be inserted just before the "Protocol 
Messages" section. It provides the detail (in english, not xml) of the 
LFBs.

The FE LFB, CE LFB, and FE Protocol LFB are used to control the 
operation of the ForCES protocol and interact with FEs and CEs.
Although these LFBs have the same form and interface as other LFBs, they 
are special in many respects: they have fixed well-known LFB Class and 
Instance IDs. They are statically defined (no dynamic instantiation 
allowed) and their status cannot be changed by the protocol: any 
operation to change the state of such LFBs (for instance, in order to 
disable the LFB) must result in an error. Moreover, these LFBs must 
exist before the first ForCES message can be sent or received. All 
attributes in these LFBs must have pre-defined default values. Finally, 
these LFBs do not have input nor output ports and do not integrate into 
the intra-FE LFB topology.

control the ForCES protocol. The FE Protocol LFB Class ID is assigned 

   FE unicast ID
   CE failover and restart policy [XXX: what is the diff with FE failover ?]
 
[TBD: define default values for each attribute if applicable]

Section X.2

[Note: this replaces the State Maintenance messages])
   FE DoS protection policy

Section X.3

The CE LFB consists of the following elements:
 CE Events:

---

From: Jamal Hadi Salim <[email-masked]>
Date: 23 Oct 2004 15:04:58 -0400

I think it is fair to separate in the acknowledgements the original
proposal authors from others. Right now they are all lumped as:

"The authors of this draft would like to acknowledge and thank all the
 protocol proposal authors"

Sorry, thats all i read so far ;-> But i do plan to scrutinize this version.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 23 Oct 2004 15:12:26 -0400

I think we need to add a definition for attribute.
As far as iam concerned there is no such thing as a "attribute ID".
What you specify is a path similar to an OID. Whether that path
happens to be on an attribute, a table, an entry is not important
because that wuill be the lement you are pointing to.
so lets remove this from the query section

-----
       Editorial Note:  There is a debate on whether we should use a
                        'Path' or simply an 'Attribute ID' or a 'Table
                        ID' here at the protocol layer.  A Path is used
                        for data indexing for a table, while an
                        'Attribute ID' or a 'Table ID' only specify
                        which attribute or table to use, leaving table
                        index to be included in followed data.
----

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Sat, 23 Oct 2004 21:15:57 +0200

Thanks Avri.  I sent out a note with my updated section after Weiming's 
comments, your note crossed mine ... So I've added a diff below so you 
can edit the text more easily now.

A few comments:
 Remove section 3.3.2 (FE Protocol Object)
 Rename current section 3.3.3 (FE Object) to "FE, FE, and FE Protocol LFBs"
 Typo "An short description" in section above
 Text I wrote with [] should be transformed into Editorial notes (and 
maybe rephrase them to look less stupid ;-)

rha@aigle:~$ diff -B -b --unified LFBs-rha.txt.old LFBs-rha.txt.new
--- LFBs-rha.txt.old    2004-10-23 20:57:18.000000000 +0200
+++ LFBs-rha.txt.new    2004-10-23 20:56:24.000000000 +0200
@@ -18,11 +18,12 @@

-The following LFBs are used to control the operation of the ForCES 
protocol and interact with FEs and CEs.
+The FE LFB, CE LFB, and FE Protocol LFB are used to control the 
operation of the ForCES protocol and interact with FEs and CEs.
+Although these LFBs have the same form and interface as other LFBs, 
they are special in many respects: they have fixed well-known LFB Class 
and Instance IDs. They are statically defined (no dynamic instantiation 
allowed) and their status cannot be changed by the protocol: any 
operation to change the state of such LFBs (for instance, in order to 
disable the LFB) must result in an error. Moreover, these LFBs must 
exist before the first ForCES message can be sent or received. All 
attributes in these LFBs must have pre-defined default values. Finally, 
these LFBs do not have input nor output ports and do not integrate into 
the intra-FE LFB topology.

-The FE Protocol LFB is a logical entity in each FE that is used to 
control the ForCES protocol. The FE Protocol LFB can be manipulated 
using the standard PL messages. The FE Protocol LFB Class ID is assigned 
the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There 
must always be one and only one instance of the FE Protocol LFB in an 
FE. The values of the attributes in the FE Protocol LFB have pre-defined 
default values that are specified here. Unless explicit changes are made 
to these values using Config messages from the CE, these default values 
MUST be used for the operation of the protocol.
[diff is removal of the sentence "The FE Protocol LFB can be manipulated 
using the standard PL messages."]
+The FE Protocol LFB is a logical entity in each FE that is used to 
control the ForCES protocol. The FE Protocol LFB Class ID is assigned 
the value 0x1. The FE LFB Instance ID is assigned the value 0x1. There 
must always be one and only one instance of the FE Protocol LFB in an 
FE. The values of the attributes in the FE Protocol LFB have pre-defined 
default values that are specified here. Unless explicit changes are made 
to these values using Config messages from the CE, these default values 
MUST be used for the operation of the protocol.

@@ -33,15 +34,18 @@
    Current version of the ForCES protocol
    Current version of the FE model
-   FE unicast ID(s) (list)
+  FE unicast ID
    FE multicast ID(s) (list)
    Association Expiry Timer
    Heartbeat Interval
    Primary CE
    FE failover and restart policy
+  CE failover and restart policy [XXX: what is the diff with FE failover ?]
+
+[TBD: define default values for each attribute if applicable]

 Section X.2

@@ -53,11 +57,12 @@
    FEStatusChange (events that signal FE Up/Down/Active/Inactive/Failover)
    FE DoS alert
    FE capability change
  FE attributes:
-   FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode 
[Note: this replies the State Maintenance messages])
+  FEStatusChange (to set the FE in Active, Inactive, or Shutdown mode 
[Note: this replaces the State Maintenance messages])
    MIID table (a list of virtual LFB Instance IDs that map to a list of 
Instance IDs of LFBs in that FE [Refer to Zsolt's note])
    FE Behavior Exp. Timer
    HA Mode
+  FE DoS protection policy
    [the attributes below were previously under Query message]
    Inter-FE topology
    Intra-FE topology
@@ -67,8 +72,8 @@

- The FE LFB consists of the following elements:
+The CE LFB consists of the following elements:
  CE Events:
    CEAllEvents (subscribing to this corresponds to subscribing to all 
events below) [Do we want to allow an FE to explicitely subscribe to CE 
events ?]
    CEStatusChange (events that signal CE 
Up/Down/Active/Inactive/Failover)  [Such events do not necessarily need 
to be subscribed to, they can fire even without subscription and inform 
the FE]

Regards.
-Robert

[email-masked] wrote:

>> messages in Section "Protocol Messages". Does anyone mind changing 
>> the order ?
>
>
> Moved.
>
>>
>> Avri,
> will be going through cleaning up format, fixing some xrefs and doing 
> a language edit, it would be easiest at this point if people just send 
> me text changes.
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: 23 Oct 2004 15:19:34 -0400

> 4. Followed 3, these LFBs will then not be included in FE LFB topology.

The ports are optional for any LFB.

> can now only think of these, we may have more later.

Sounds like you caught all. We need to list the attributes and
capabilities.

cheers,
jamal

---

From: [email-masked]
Date: Sat, 23 Oct 2004 15:57:44 -0400

>        Editorial Note:  There is a debate on whether we should use a

done.

> proposal authors from others.

instead i just removed the words about original proposals.  but still 
lumped.

i also added the command/message table

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 23 Oct 2004 16:07:20 -0400

comments:

- section 6.1 should have title "Core ForCES LFBs"

- 6.1.1  FE Protocol LFB
"Protocol LFB have pre-defined default values that are specified here."

What? Where?

- 6.1.2  FE LFB
 
MIID table : Have we decided this is the mode we are using?
Should this be under editorial note?

Other things:
+ FELFBInstancelist missing
+ FENeighborList missing
+ FEStatusChange should probably be just "FEStatus"

What is
FE Behavior Exp.  Timer ?
Also we probably need some things like
+ FEPrivateData which will contain things like name, vendor,
model and other proprietary info

- 6.1.3  CE LFB
I sense this is useful. 
Can someone list CE events the FE maybe interested in?

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 23 Oct 2004 16:22:39 -0400

- Section 6.2.1

 	     +--- T = Operation = SHOW
   		      |
   		      +-- FE NAME

What is the point of having this one operation called SHOW just
for this? Is it an operation at all given its position in the hierachy?
PENAME may have been a better name.

In the diagram: 
+ LFB Instance ID  and LFB Class ID 
should those just be set to 0x1? We already know thats where they are
going.
+ Type = operation, using the word "type" is confusing since it is also
used in the main header. I dont think we can avoid using the word type
in TLVs; my suggestion is we consider changing the main header type to 
"command". Thoughts? It is a command after all.
+ comment on SHOW applies here as well

+ "HBI will be exchanged with the CE using this LFB" ???

-6.2.2  Association Setup Response Message

In the diagram: 
+ LFB Instance ID  and LFB Class ID 
should those just be set to 0x1? We already know thats where they are
going.
+         
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Type = operation Show  |               Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   FE Object LFB (optional)                    ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What is that?

+ "HBI will be exchanged with the CE using this LFB" ???

+ Type = T.reason  ?

This brings up that we need the following speacial TLVs.

FORCES_REASON, FORCES_RESULT, FORCES_NAME.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 23 Oct 2004 16:36:50 -0400

section 6.3

And in general i hope those are seen as sample layouts of the message;
i.e hopefully, nobody sees that layout as the way they must build the
message with an ADD and a DEL etc.

- 6.3.1  Config Message

+ "Config data"   should be "Config data and path"

+ Type is bad to describe operations. That should be operations

+ UPDATE/REPLACE, DEL ALL are really flag extensions which will become
clear once we have path-data noise cleared. Suggest you remove.

+ What is PACKET SUBSCRIBE/UNSUBSCRIBE?

- 6.3.2  Config Response Message

Why do we have " Operation Result "
As far as i can see it is sufficient to look at the Main header type,
a operation, path and its associated data.
Unless this is meant to be a less verbose result?

+ BTW, what is the point of mentioning "single or Array LFB
       specific result entries" or result might be TLV. Just say the 
presentation of the data is stuill under discussion.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 23 Oct 2004 16:48:54 -0400

"The ForCES query and query response messages are used for one ForCES
   element (CE or FE) to query other ForCES element(s) for various kinds
   of information. "

Isnt everything an LFB? Why not say that its for querying LFBs?

- 6.4.1  Query Message

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = GET                 |               Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Path(or Attribute ID?)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Query Data                         |
                                                              .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Should really be:

|    Type = GET                 |               Length          |
|                        Path to queried data                   |

- 6.4.2  Query Response Message

I think the deviation from the norm in laying out the response
will make it more programming work. 
Looking at main header one should be able to tell how to parse the 
contents and what they mean.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 23 Oct 2004 17:02:28 -0400

- 6.5  Event Notification and Response Messages

"An event definition
   made by ForCES protocol, ForCES FE model, or by vendors will state if
   the event needs subscription or not."

Events will be defined in the XML as attributes; i.e they will have a
path to them that can be used by the config message to subscribe to.
I think it is important to at least say that.

- 6.5.1  Event Notification Message

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = REPORT              |               Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Path(or Event ID?)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Event Data                         |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Should be:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    OPER = REPORT              |               Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Path and  Data                         |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 23 Oct 2004 17:07:21 -0400

1) The packet redirect section, I think we can leave as is for now but
should open up a lot of discussion later.

2) Events - I have some implementation experiences/questions in regards
to when you have hierachies of subscrisable events.
Example: "tell me when table changes vs tell me when entry X of table
changes". Lets talk afte rdraft goes out.

3) Section 6.7 - heartbeat section; seems to be missing some things.
Double check please.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 24 Oct 2004 19:40:52 +0800

Jamal,

Firstly, I think it may be unwise to remove some editorial note when the isuuse
is still under discussion. I can clearly see many different opinions regarding
the issue. Then, some of my thougt on adding such an editorial note as below.

Regards,
Weiming
----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>

> As far as iam concerned there is no such thing as a "attribute ID".
[Weiming] Then, I just can not see how we can recognize different attributes in
a LFB. Note that a 'Path' is a ID that is used and defined by USERS rather than
standadized by IETF, therefore it's impossible to recoganize different
attributes by 'path', and more, if the attribute ID is defined by USERS, there
will be no interoperability. What I see the 'Attribute ID' is a standardized by
IANA Identifier that is assigned to different attributes in all LFBs.

> happens to be on an attribute, a table, an entry is not important
I see it may be important, the reason is as above.
> so lets remove this from the query section
[Weiming]I'v already put the 'path' as main select and the 'attribute ID/table
ID' as a select for discussion. I don't have any intention to deny the 'path'.
Therefore, I don't think it's reasonable currently to remove the note.

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 24 Oct 2004 19:54:27 +0800

Robert,

----- Original Message -----

[Weiming] I agree your idea that these two may be merged. Say it as 'CE and FE
failover policy' ?

> +[TBD: define default values for each attribute if applicable]
[Weiming] this editorial note is not needed anymore, fore I'v already removed
the following items.

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 24 Oct 2004 20:00:02 +0800

Avri,

----- Original Message -----
From: <[email-masked]>
Subject: 01-5

> >        Editorial Note:  There is a debate on whether we should use a
It may be more fit to do so before we have decided it regarding this issue.

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 24 Oct 2004 20:19:12 +0800

Jamal,

Thank you for scrutinizing the sections one by one.

Cheers,
Weiming
----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
Subject: [Forces-protocol] Feedback: Section 6.4

> Isnt everything an LFB? Why not say that its for querying LFBs?
[Weimig]it's just a top level description I think we need. i don't think it
conflict with the ideas of LFBs. Maybe we can add one more sentense as "The
information of a ForCES element all reside in LFBs in the element, therefore,
query message will actually query the LFBs for kinds of information." Does it
work?

> - 6.4.1  Query Message
[Weiming] This may be better described in the followed description. So, Avri,
could you please add the 'Path to queried data' after the Path description, just
before the [[Under discussion and TBD]

Again, I think it may be better to leave the discussion topic on attribute
ID/table ID here.

---

From: "Wang,Weiming" <[email-masked]>
Date: Sun, 24 Oct 2004 20:22:56 +0800

----- Original Message -----
> I think it is important to at least say that.
[Weiming]OK. Avri, pls help to add this. Thanks.

> - 6.5.1  Event Notification Message
[Weiming]Do you think the "path' and the 'data' will be mixed?

---

From: Jamal Hadi Salim <[email-masked]>
Date: 24 Oct 2004 09:07:10 -0400

Weiming,

> the issue. Then, some of my thougt on adding such an editorial note as below.

Is the concept of path still under discussion Weiming? Thats not my
impression. And if not, why does it matter if the path is constructed
from a single attribute or via table of table7 index 3 which is table8 ?

> IANA Identifier that is assigned to different attributes in all LFBs.

The attribute IDs are defined by the person(s) who create the XML.
The document/ClassID - that i can see as being owned by IANA.

> Therefore, I don't think it's reasonable currently to remove the note.

I think we need to define how a path is selected once; then use the word
path everywhere. I dont think that it matters if theres a table involved
or not. Neither if its a single attribute that has nothing to do with a
table.
Is the above still under discussion? Thats not the impression i have.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 24 Oct 2004 09:16:34 -0400

> query message will actually query the LFBs for kinds of information." Does it

So while you are defining that at the top; i think its also important to
have a subsection somewhere which says something along the lines of:

---
Every attribute within an LFB will have a unique 32 bit ID defined
during the LFB definition. This allows mapping any attribute within an
LFB to a path not unlike the SNMP OID. 

Below is an illustration of a complex example and how the different
attributes could be accessed.

Assume LFB Class A.
It contains two Arrays, B, and C (assigned identifiers 1 and 2)
A also contains a structure of type Stoo with a human name F.
F is assigned ID 3.
A also contains two attributes, D and E assigned identifiers 4 and 5.
Array B is an array, indexed as a table, whose contents are int32s.
Array C is an array, indexed as a table, whose contents are a structure 
named Star.
Stoo type structures contain elements X and Y, each characters, 
assigned identifiers 1 and 2.
Star contains An element N (a sting), assigned identifier 1, and an
array 
Arr, assigned identifier 2, indexed as a table, containing int32s.

To reference entities within an LFB instance of Class A, selectors
are as follows:

1, meaning the full array B
3, meaning the full structure named F.
2, 7 meaning the full structure in the seventh entry of the array C.
4 means the attribute D
2, 8, 2, 9 meaning the 9th number in the array in the structure in the 
eigth slot of the array C.
Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct 
type definition.
-------

> Again, I think it may be better to leave the discussion topic on attribute

Read my text above on examples. If you still think that this is still
under discussion, lets tag it as so for now just so we can release the
draft. My opinion is that we have agreement on the path concept.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 24 Oct 2004 09:17:59 -0400

> [Weiming]Do you think the "path' and the 'data' will be mixed?

Path is clear. Data is under discussion. 
You will have path and data associated with it.

cheers,
jamal

---

From: [email-masked]
Date: Sun, 24 Oct 2004 12:37:56 -0400

> It may be more fit to do so before we have decided it regarding this 

As i said in an earlier note, i can always put things back in.  I don't 
actually remove these things on the first pass, I just comment them out 
in the xml files.  and if someone complains, I can uncomment them.  
Basically I am trying to find the rough consensus point - though I 
freely acknowledge that I can only recommend where i think that point 
is. At this point any issue that can't be resolved needs to go to the 
WG and the chairs for determination of the rough consensus.  Frankly I 
thought we had rough consensus on the issue.  It certainly seemed to be 
reflected in the decisions being made on the text.

At this point there are only 20 hours left before I need to submit the 
draft.  I have been reading the list rather faithfully and trying to 
understand which issues have been resolved and which have not.  I 
honestly thought this debate had been resolved.  If I make a mistake, 
and i acknowledge that i do make mistakes i will roll back the text. 
And since this is not the final version, anything can be changed - 
especially if/when we start to get some WG community feedback.

Note: if, my editorial judgments are disturbing, and I try to make as 
few as I think this group can bear, I will pass on the document to 
someone else. Having said that, I think it is time to start making 
decisions and bringing them to the WG who are, in point of fact, the 
owners of the draft.

Anyhow, over the next 20 hours I will try to remain available as much 
as possible to get a draft out that meets this team's rough consensus.

Incidentally I have now uncommented that note - i.e. it will show up 
again in 01-7 unless it gets resolved between then and now.

Another point.  I have not managed to do the work necessary to activate 
the issues database, but will try to do so before the IETF.  In my 
opinion, it is time to start moving these disagreements from the text 
into an issues database in an effort to drive this document to 
completion - our milestone is March 05 - only 5 months away at this 
point.

also, how many of the team will be at the meeting.  We really should 
have a face to face session to resolve as many issues as possible.  I 
will be arriving in DC Saturday morning (for the HIP RG  seminar) and 
will remain in town until the following Saturday morning

a.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 24 Oct 2004 13:42:40 -0400

Hi Avri,

> reflected in the decisions being made on the text.

Just keep up the good work.
I think people may be confused if you are actually following the
discussion (since you are unusually quiet) hence the comments you may
have seen. 
But now that we know you are - you should be allowed to exercise your
editorial powers on things IMO. What you are doing
in keeping the old text around when the person who made the changes
to that section hasnt responded is a very good idea.

> especially if/when we start to get some WG community feedback.

The path issue has been resolved; i think we may be just talking past
each other. The issue thats still open is the data packing.

> decisions and bringing them to the WG who are, in point of fact, the 

The WG should see the draft after we are done i think. I wouldnt say we
are.

> as possible to get a draft out that meets this team's rough consensus.

Great.

> completion - our milestone is March 05 - only 5 months away at this 

This would be nice.

> will remain in town until the following Saturday morning

I plan to be there.

cheers,
jamal

---

From: [email-masked]
Date: Sun, 24 Oct 2004 17:37:57 -0400

> discussion (since you are unusually quiet) hence the comments you may

for the most part i was fine with the conclusions folks were coming up 
with.  in my attempt to reman as impartial in this group as possible, i 
only get vocal when things really concern me.  in many cases, i saw a 
lot of the disagreements as of the 6 of 1 and a 1.2 dozen of the other 
variety, with either option being workable.  in those cases where i 
thought it mattered, things went in a direction i was comfortable with, 
so why say "me too".

also due to my schedule, i have often been delayed many days in reading 
the email. so, often, by the time i read through the exchange there was 
very little left to say.

> each other. The issue thats still open is the data packing.

can someone offer a note that expresses the still open conflict that 
all parties can agree with? the one i put back does not really express 
the still open issue as far as i can tell.

> The WG should see the draft after we are done i think. I wouldnt say we

i tend to disagree with this.  now that this is a WG document, and the 
WG is the owner of the doc, i believe they should have more frequent 
snapshots and should be brought into the discussions.

but i defer to the team and the chairs on this issue.

>> as possible to get a draft out that meets this team's rough consensus.

except that i am not seeing any edits from anyone.

15 hours to go, and i plan to sleep some of them if at all possible.

i am currently working on a 00 - 01 change list appendix. which will 
show up in 01-7.

a.

---

From: Jamal Hadi Salim <[email-masked]>
Date: 24 Oct 2004 21:15:00 -0400

> thought it mattered, things went in a direction i was comfortable with, 

Understood.

> the still open issue as far as i can tell.

In response to Weiming, I posted some text describing the path concept
but i am not sure where best that goes.
A path defines how to get to data being accessed; how that data gets
shipped around is still a question mark. There has been a proposal from
Steve/Zsolt which is insufficient to cover all known scenarios.
I think this needs to be discussed seriously in the meeting.

> but i defer to the team and the chairs on this issue.

It is my opinion that sometimes it is easier to make progress with a
smaller team. I actually dont think Weiming and I are disagreeing with
each other for example; i just think we may be talking past each other.
It is clear that the issue of data packing is still open. I still wanna
hear from Weiming if he thinks the path issue is open - in which case we
would need to involve more people.  

> i am currently working on a 00 - 01 change list appendix. which will 

I think you should submit by 8am Eastern whatever verion you have then.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 25 Oct 2004 11:41:22 +0800

Jamal,

Hormuzd, pls also give some feadback. I also add Joel to the list again for the
discussion.

Regards,
Weiming
----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
Subject: Re: [Forces-protocol] Re: querry message (path vs attribute)

> from a single attribute or via table of table7 index 3 which is table8 ?
[Weiming]Jamal, it's really a under discussion topic. I can see different view
other than from me, you may miss me one person :), but it's true we have more. I
stopped the discussion for I paid more attention to draft rewriting. At least I
think Hormuzd also has some different views.
> The document/ClassID - that i can see as being owned by IANA.

[Weiming] Even if the attribute(type) ID will only be defined by XML which
define LFBs (I still see the necessity for IANA to standardize the ID), it has
already meant the ID will not be assigned by USERS. Then, if you want to have
'path' include the ID, I suppose we should leave a specific section for the ID,
and the use of the section will be limited only for attribute type ID. To do
like this, I more prefer to have it as a separate spicific field. Note that I'm
not saying in any case, the 'path' is useless, I just suppose it can be put in
Data field. Actually hat I think the more reasonable addressing map for LFB
should be as follows:

                                LFB class
                               /      \
                        LFB Instance  ...
                        /    \
             Attribue Type   ...
                /         \
    Path to entries inside  ...

Rather than:
                                        LFB class
                                       /      \
                                LFB Instance  ...
                                /        \
               Path to  entries   ...
                /         \
        Attribute Type    ...

The path can really be defined in Data as:

Data : = Path <Entry>

Can you tell me what's the harm if we just define the 'path' one step down to
the Data field. I just see it more flexible.

> path everywhere.
[Weiming]So can you give more definition for the 'Path' then? Does it include
'AttributeTypeID'?

>I dont think that it matters if theres a table involved

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 25 Oct 2004 11:44:52 +0800

----- Original Message -----

> A also contains two attributes, D and E assigned identifiers 4 and 5.
[Weiming]I suppose the attribute identifier (4, 5) will be assigned by XML as
you mentioned (I see some necessity to be defined by IANA). Definitely, user
will not be able to define the ID, or there will be no operabitlity.

> Interpreting the string 2, 8, 2, 9 clearly requires knowing the correct
[Weiming]Followed by above comments, a very simple question is how will you
address the D and E attributes as you mentioned as two different attributes? I
see it's possible only if you save a section inside the 32bit 'path'
specifically for attribute type ID. That means this section are not allowed
freely used by users. Because of this, i then prefer to have a specific field
(AttributeTypeID, which I refered as attribute ID) for it. Note that I'm not
saying 'path' is useless, I just think it can be followed in Data field.

cheers,
weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: 25 Oct 2004 00:18:52 -0400

On Sun, 2004-10-24 at 23:41, Wang,Weiming wrote:
> already meant the ID will not be assigned by USERS.

Not defined by users, rather static - defined at LFB XML template
creation time. OTOH, there are some more dynamic IDs that are usable
such as a table index.

>  Then, if you want to have

Why do you have the attribute type? To get to the attribute i.e to know
its path, you dont need to know its type.

> the Data field. I just see it more flexible.

Above is what we have been refering to as path-data. Entry is the data.

> [Weiming]So can you give more definition for the 'Path' then? Does it include

'AttributeTypeID' is not needed to get to the element. But the ID is
needed. I have attached the noop LFB we looked at a while back, it may
help reminding you a little ;->

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 25 Oct 2004 00:29:24 -0400

> will not be able to define the ID, or there will be no operabitlity.

Right. As an example in noop.xml i posted earlier, foo1 has ID of 3
and foo2 has ID of 4. Thats defined when noop.xml was defined.

> saying 'path' is useless, I just think it can be followed in Data field.

Lets take an example of noop, since the xml for that is there and its a
very simple example.

The class NOOP is 5. owned by IANA.
It has a simple table called datatable whose ID is 6. Defined at xml
creation.
To point to first entry of datatable: 6,1
to point to foo1 within entry 2 of datatable: 6,2,3
to point to foo2 of entry 3 of datatable: 6,3,4

I hope this clears it. I have attached two docs i worked on to 
clarify this.

As i said earlier, the path issue is resolved but not the data packing.
Of course if you disagree we could continue that discussion.
As you will notice in these docs, the text clearly states that the 
data packing is not resolved.

cheers,
jamal

---

From: [email-masked]
Date: Mon, 25 Oct 2004 01:17:24 -0400

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

Changes to 01-7

- removed ETRI from front header - seemed unfair to list one company.
- changed format listing all authors to be a paragraph instead of list 
for aesthetic reason;  it broke across a page break and looked silly.
- added changes section - though it is not complete yet.
- re-inserted note on path vs. 'attribute id' discussion
- some language editing.  a bunch more needs to be done.  i will 
probably work for another hour or so tonight, but this is essentially 
what i plant to submit before the deadline.  if i work to much longer 
tonight i will submit it before going to sleeep so that i don't miss 
the morning deadline.

a.

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 26 Oct 2004 11:17:08 +0800

----- Original Message -----
> It has a simple table called datatable whose ID is 6.
>Defined at xml creation.
[Weiming] Let me call this ID an 'attribute ID'. Also in your XML, you'v called
the table an attribute, right?

> To point to first entry of datatable: 6,1
[Weiming]I'm glad to see this. It also means you'v agreed that the 'path'
includes one subsection  which is for attribute ID, right? Now the problem is,
how many bits are you going to use for such ID, 8 bits or 16bits? I suppose you
will not use a variable size for this ID. Whether the ID length is variable or
not, we  then can both reasonably think the 'path' as composed of follows:
                Path : = AttributeID  Index
 that really matches my idea. I also think  it mathces your idea too as
presented in your example here as 6.1, 6.2.3, etc.

To summarize, what I proposed actually include two thoughts:
a) Attribute ID is necessary;
b) the attribute ID should appear in the protocol layer. The followed Index can
be included in Data field, becaue not all attributes need Index (they may only
have one entry).

I'm not sure if above helps or not.

Cheers,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 Oct 2004 23:48:36 -0400

Remember that there may be structures inside structures, or arrays inside 
structures inside arrays inside structures, ...

Hence, a path is a sequence of identifiers, each of which is either a 
subscript or an element identifier within the containing scope (initially 
the LFB classs definition, then progressive the structures selected by the 
earlier path elements.
For simplicity, I suggest we make all the identifiers 32 bits.

Yours,
Joel

---

From: [email-masked]
Date: Mon, 25 Oct 2004 23:55:20 -0400

> For simplicity, I suggest we make all the identifiers 32 bits.

I certainly agree with this point.

a.

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 26 Oct 2004 12:01:21 +0800

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: [Forces-protocol] Feedback: Section 6.4

> Hence, a path is a sequence of identifiers,
I suppose you are proposing the 'path' is variable in length, which  I think may
be not the original idea of a path as a 32 bit index for table only.
If it is, i think the idea mathces more to what I proposed. Definitely, I think
the first ID appearing in the sequence is the attribute ID.

>each of which is either a
I have no doubt to agree with this. Just need to calrify that a path is more
than 32 bits long, or there will be not enough bits.

Thank you.
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: 26 Oct 2004 06:59:06 -0400

> than 32 bits long, or there will be not enough bits.

Aha! I think i see where the misunderstanding is;->
Weiming sees either a path like 6 or 1,2,3,4 as represented by _one_
_fixed_ sized element. In which case you have to find a way to pack both
representations into that fixed size element.

The suggested "path" representation is in fact _variable_.
>From the notes i sent earlier to you, the suggestion is:

----
 A possible path-data layout. 
----------------------------

OPER_TLV : = <PATH-DATA>
PATH-DATA := flags IDcount <IDs> [BLOCK_OR_KEY_NOTATION] [DATA]
The operational TLV contains an opcode in the T part. Its V
contains the PATH-DATA.
Opcodes discussed so far:
* SET (create, modify or both depending on PATH-DATA flags}
* DEL (remove an existing entity specified by PATH-DATA }
* GET (Access a entity specified in PATH-DATA }
* EV_S (subscribe to an event defined in PATH-DATA }
* EV_U (unsubscribe to an event defined in PATH-DATA }
-> IDs := a series of 32bit IDs (whose size is given by IDcount)
defining the path.
-> flags are used to further refine the operation to be applied
on the ID_TLV.
-> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension
defined in section 4.2 and 4.3 of [1]
-> DATA : = Optional variable sized data dependent on PATH
and applied operations (eg GET will not have DATA).

-------

Well read the rest of the doc; and for completion the notes posted by
Steve/Zsolt.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Oct 2004 07:05:03 -0400

The path from the LFB instance to the element being targeted (by the SET or 
GET) is variable in length.  (I was going to write "must be variable in 
length".  One could craft a very complex mechanism to assign ids from a 
flat space to every such multi-step path.  But it does not seem a good idea.)

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: 29 Oct 2004 09:05:09 -0400

Folks,

I am gonna start queueing (inot a queue that holds only one message)
issues i think are unresolved (we either didnt get to completion on call
or havent discussed them to satisfaction to close them).

- Section 6.2.1

Is it an operation at all given its position in the hierachy?
PENAME may have been a better name.

I didnt explain this well on the call.
Where operation is showing up is the wrong spot for the grammar which
says operation comes after LFBSelection.
It is therefore not an operation. Hence the suggestion to call it
PENAME.

In the diagram: 

In the diagram: 

What is that?

+ Type = T.reason  ?

cheers,
jamal