Re: [Forces-protocol] Feedback: Section 6.4

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

On Sun, 2004-10-24 at 08:19, Wang,Weiming wrote:

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

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


> >
> > - 6.4.1  Query Message
> >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |    Type = GET                 |               Length          |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                        Path(or Attribute ID?)                 |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                            Query Data                         |
> >                                                               .
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> > Should really be:
> >
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |    Type = GET                 |               Length          |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                        Path to queried data                   |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> [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.


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



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