Re: KEYDATA was Re: ipv6 was Re: LC model draft draft-ietf-forces-model-07.txt

Then clearly we need better text.

I will try here to provide an explanation, so that next time folks 
can check if the text better explains the goal.

Arrays have indices.  Indices are always 32 bit integers. An array 
can have a fixed or variable number of entries.  For variable size 
arrays, there can be a declared maximum, and the FE may place a 
smaller maximum on the size.
The path to an array element consists of the path to the array, 
followed by the subscript, optionally followed by additional path if 
one is trying to get a more specific piece of the array element.

In addition, there is content keying.  This allows the CE to 
reference an element of the array by the value stored in the array 
rather than by the index.  Only elements which are declared to form a 
content key can be used as a content key.  Content keys must be 
unique in an array.
To reference an element by a content key, one uses a path, with an 
option indicating that there is a content key.  A TLV contains the 
content keying information.  There can be nested path-data TLVs to 
allow one to select elements from within the array element.

So, content keying is an alternate way of selecting an array 
element.  Any field or combination of fields in the array element can 
be declared to be a content key, and can be used for a content key reference.

Yours,
Joel M. Halpern

PS: I personally consider the entire content keying notion gratuitous 
and unnecessary complexity.  But the working group agreed that it was 
worth having, so I will do my best to explain it in the 
document.  But I don't have to like it.

At 03:36 AM 10/27/2006, tom.petch wrote:
>---- Original Message -----
>From: "Joel M. Halpern" <[email protected]>
>To: <[email protected]>
>Sent: Friday, October 27, 2006 1:27 AM
>Subject: Re: ipv6 was Re: LC model draft draft-ietf-forces-model-07.txt
>
>
> > KEYDATA can be anything.  It can be a simple integer.  It can be a
> > string.  It can be an entire struct.
> >
> > Basically, when we decided to allow content based element selection,
> > we concluded that we could not restrict the type of content that
> > served as the key.
> >
>
>Obviously, I had not picked this up.  I suggest adding something to 
>that effect
>to 4.5.3. What I read, and did not - still do not - understand, was
>   "Arrays MUST only be subscripted by integers, and will be presumed to
>       start with index 0.
>
>       In addition to their subscripts, arrays may be declared to have
>       content keys."
>
>I expect an array to have an index, of one of more elements, and do not
>understand the difference here between an index and a content 
>key.  Content key
>has overtones of a CAM for me, but obviously there is more to it than that.
>
>Issue 99?
>
>Tom Petch
>
> > Yours,
> > Joel M. Halpern
> >
> > At 07:47 AM 10/26/2006, tom.petch wrote:
> > >So is there any constraint on what type of data a KEYDATA can be?  I was
> > >assuming it would be numeric of fixed length but you are 
> suggesting it can be
> > >(almost) anything.  I note that the examples I see in -protocol 
> are type u32.
> > >
> > >Tom Petch