Subject: RE: [Forces-protocol] Feedback: Section 6.4

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 27 Oct 2004 00:20:03 -0700

Jamal, Weiming,

I finally got the chance to read some of these emails...sorry for not
responding earlier. In general, we will need the concept of PATH atleast
for Query messages (GET), but I don't believe from any of the emails
that I have read so far that there was any concensus on what this would
look like. Jamal has a reasonable proposal which needs more discussion
and refinement.

Some specific comments on Jamal's proposal so far...

Where is the Table ID ? Is this part of the path IDs?
I don't believe we need any Flags in the path, this is similar to the
comment that Joel had as well.
Also, for Config msgs, I think the path can be part of the data itself,
but lets discuss this further...cause I am not sure if you guys agree
with this,

Talk to you soon,

regards
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Tuesday, October 26, 2004 3:59 AM
To: Wang,Weiming
Cc: Joel M. Halpern; Khosravi, Hormuzd M; [email-masked];
[email-masked]; [email-masked]; Ligang Dong; Robert Haas
Subject: Re: [Forces-protocol] Feedback: Section 6.4

On Tue, 2004-10-26 at 00:01, Wang,Weiming wrote:

> 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.
> 

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

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

---

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

Folks,

The PATH is needed for _everything_ thats interfacing to any LFB
attributes. 
Think of it as an SNMP OID - you need that _everytime_
To get to where the table etc fits in, please read the two docs i posted
to speed up the discussion; 

Heres a cutnpaste from one of those docs:

path-data
----------
The layout is still under discussion and so is left out from this text.

Each accessible attribute within an LFB is expected to have a 32 bit
identifier.

The path-data will have a map derived from the static class attribute
IDs as well as those derived from variable content such table indices 
(derived at runtime).

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.
Since the model team has asserted that class definitions can 
only change (version) in ways that leave existing references intact 
and usable it means backward compatibility is supported.

----------------------

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 27 Oct 2004 22:22:31 +0800

Jamal,Hormuzd as well,

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

> The PATH is needed for _everything_ thats interfacing to any LFB
[Weiming] I agree you say that path is needed for every attributes in LFB.
 My opinion is the path is composed of at least two parts:
 The ID to describe which attribte it is --- this I call it "Attribute ID", (and
Hormuzd called "Table ID"?)
 The Index ID to describe which entry inside the attribute IF THE ATTRIBUTE IS A
TABLE --- this we usualy called "table Index".

Then, my opinion is (I think Hormuzd also think so) the 'Attribute ID' part
should appear in our protocol layer, but the Index ID will not appear in the
protocol layer. Instead, it should appear in the data field. Why? because,

1) Not every attribute is a table, therefore not every attribute need such table
index. But 'Attribute ID' is always needed.

2) Even in the table case, to put the table index in the data field means to let
the LFB definer to have much flexibility to define the index - the length of the
index, the format, etc,  rathan than to be uniformly defined for all LFBs by our
protocol.

3) In this way, we can also easily implement all the operations as you mentioned
below.

4) Also note that the 'Attribute ID'is explicitly defined in XML definition of
LFBs(e.g. ID=6 in your noop.xml), while the table index will not appear in the
xml, that means the table index is a kind of data while the attribute ID is a
specific field, from the protocol viewpoint.

> Heres a cutnpaste from one of those docs:
Yes.
> IDs as well as those derived from variable content such table indices
Exactly.

> 1, meaning the full array B
Agreed. Note here 1 is as I mean 'Attribute ID'

> 3, meaning the full structure named F.
Agreed. 3 is another attribute ID.

> 2, 7 meaning the full structure in the seventh entry of the array C.
The protocol only pay attention to the 2 ID, while leaving the 7 being inluded
in the data field.

> 2, 8, 2, 9 meaning the 9th number in the array in the structure in the
The protocol layer only pay attention to the 2 ID, leaving the 8,2,9 in the data
field. Whatever format the LFB model may use to define the path.

Cheers,
Weiming

---

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

Weiming,

Yes, the two are different in the sense that one is defined at static
xml definition time and the other created at runtime. However,
if you give me a series of 32 bits defining a path which includes table
Ids and rows and cells, i can tell you 100% of the time where that path
will lead. There is _zero_ ambiguity.

Note there are circumstances where it may make sense like in the case
of block operations (eg operate on table indices 100-200) - this is
probably your main point (as mentioned in your point #3). This does not
make the block operation part of the "data" like you said. All it says
is "this is how you get to the data". 

cheers,
jamal

---

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

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

> will lead. There is _zero_ ambiguity.
We can just let the first fields of the data being IDs for table index, which is
really identical with the one whole path, but leaving more flexibiligy for every
different LFBs to define the IDs. This means:
Op TLV = AttributeID <Data> (or you may call it as : Path <Data>, but the path
here is only an Attribute type ID).
Data := <IDs for indexing> <...>

In this way, if the LFB needs the indexing IDs, it will be there, if not, there
will be none.

Thanks.
Weiming