Re: [Forces-protocol] Feedback: Section 6.4

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

Hormuzd,

I'm very busy again during this weekdays. Pls allow me to do it during this
weekend. I'l post something in detail then.

Regards,
Weiming
----- Original Message -----
From: "Khosravi, Hormuzd M" <[e-mail]>
To: "Wang,Weiming" <[e-mail]>; <[e-mail]>
Cc: "Joel M. Halpern" <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; "Ligang Dong"
<[e-mail]>; "Robert Haas" <[e-mail]>
Sent: Friday, October 29, 2004 3:37 AM
Subject: RE: [Forces-protocol] Feedback: Section 6.4


Weiming,

I think it would be good if you summarized both approaches for PATH
(Advantages, Disadvantages, etc) and send out an email to the group to
discuss and decide. I do see my advantages to your approach and this is
definitely a viable option for Config messages. For Query messages, the
path will be more involved with all the IDs, etc (since there will be no
data)

Thanks
Hormuzd

-----Original Message-----
From: Wang,Weiming [mailto:[e-mail]]
Sent: Wednesday, October 27, 2004 8:07 AM
To: [e-mail]
Cc: Khosravi, Hormuzd M; Joel M. Halpern; [e-mail];
[e-mail]; [e-mail]; Ligang Dong; Robert Haas
Subject: Re: [Forces-protocol] Feedback: Section 6.4


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


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