Re: [Forces-protocol] Feedback: Section 6.4

["Wang,Weiming" <[e-mail]>]

Jamal,Hormuzd as well,

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


> Folks,
>
> The PATH is needed for _everything_ thats interfacing to any LFB
> attributes.
[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.


> 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.
Yes.
>
> 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).
Exactly.

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

> 4 means the attribute D
> 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

> 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
>
> On Wed, 2004-10-27 at 03:20, Khosravi, Hormuzd M wrote:
> > 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:[e-mail]]
> > Sent: Tuesday, October 26, 2004 3:59 AM
> > To: Wang,Weiming
> > Cc: Joel M. Halpern; Khosravi, Hormuzd M; [e-mail];
> > [e-mail]; [e-mail]; 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol