Re: [Forces-protocol] Feedback: Section 6.4

[Jamal Hadi Salim <[e-mail]>]

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

On Wed, 2004-10-27 at 10:22, Wang,Weiming wrote:
> 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