Re: Protocol Draft - KEYINFO-TLV

Greetings again to the list,

I have a new question regarding the KeyInfoTLV.

Page 45:
       KEYINFO-TLV := KeyID FULLDATA-TLV

Page 46 About KeyData.
      *  The key's data is the data to look for in the array, in the
         fields identified by the key field.  The information is encoded
         according to the rules for the contents of a FULLDATA-TLV, and
         represent the field or fields which make up the key identified
         by the KeyID.

If I understand this correctly then the KeyInfoTLV should look like this:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type = KeyInfo         |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             KeyID                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type = FullData        |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Value=KeyData                         |
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If this is the case, then does the KeyInfo Length contains also the length
of the KeyData?

Also, since there is only one KeyID, wouldn't the following format be more
useful:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        Type = KeyInfo         |               Length          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             KeyID                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            KeyData                            |
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Whereas "KeyData_Length = Length - 8" and a different TLV for the KeyData is
not needed?

Is there a specific reason why KeyData is needed as a different TLV? From
the BNF I understand that the Key and the Fulldata (KeyData) go, when used,
together. Why split them?

Regards,
Evangelos Haleplidis.

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email protected]] On Behalf Of Wang,Weiming
Sent: Tuesday, April 01, 2008 6:03 PM
To: [email protected]
Subject: Re: Protocol Draft - KEYINFO-TLV

Hi Evangelos,

From the contecptual point of view,  the KeyID is a type of  "IDs" as
explained in p.45, which occupying the same length (32bits). Whereas, I
agree that applying a text like KeyID(32bits)  in the KeyID term explanation
paragraph might make things more clear. 

On the graph description of the Path-Data-TLV, I just think current BNF is a
clear and efficient method. At the time we chose the BNF, we had made some
considerations like the inefficiency for graph to describe duplicate TLVs
case and the self-contained TLV case. 

Thanks a lot for the careful review.

Thanks,
Weiming

----- Original Message -----
From: "Evangelos Haleplidis" <[email protected]>

> Greetings,
> 
> My question was what the size of the KeyID, in terms of the protocol 
> message, is. Are the KeyIDs 4 bytes long? I couldn't find any 
> specification in the protocol draft, and I believe there should be one 
> in there, or an explanation of how to get it. Or is it derived by the
KeyInfoTLV's L value?
> I couldn't find a text that explains that also. 
> 
> Also, how many keys can there be in an array? Will there be more than 
> 127 (1byte)? Is there a need for 4 bytes? Since for each array we can 
> have individual numbering.
> 
> Regards,
> Evangelos Haleplidis.
> 
> -----Original Message-----
> From: Forwarding and Control Element Separation 
> [mailto:[email protected]] On Behalf Of Joel M. Halpern
> Sent: Tuesday, April 01, 2008 4:05 AM
> To: [email protected]
> Subject: Re: Protocol Draft - KEYINFO-TLV
> 
> The KeyData is, I believe a FULLDATA TLV, as it can be any form of 
> data, and may need its own length.
> 
> The KeyID is an ID, as defined in the model.  There can be multiple 
> keys, each made up of multiple values.  The keyid tells you wha tkey 
> is being used.  Please look at the model and let us know if there is a 
> need for more text on that.
> 
> Yours,
> Joel M. Halpern
> 
> Evangelos Haleplidis wrote:
>> Greetings again to the list,
>> 
>> I have some comment regarding the KEYINFO-TLV.
>> 
>> 1. As with the PathData TLV there was no Graph, so I made up one. I 
>> include it in the end of the mail.
>> 2. About the KeyID, it is not specified specific in the document what 
>> the size is. I guess it is an integer, shouldn't it be specified for
> clarity?
>> How many Keys may exist for a specific table? Could/Should the KeyID 
>> be limited to less than 4 bytes?
>> 3. In Page 45 it is written:
>>        KEYINFO-TLV := KeyID FULLDATA-TLV Shouldn't it be changed to:
>>        KEYINFO-TLV := KeyID KEYDATA
>>        KEYDATA := FULLDATA-TLV
>> Or
>>        KEYINFO-TLV := KeyID KeyData
>> This would be in accordance with the examples also in the appendix.
>> 
>> Regards,
>> Evangelos Haleplidis.
>> 
>> ===============================
>> KeyInfo-TLV Graph
>> 
>>      0                   1                   2                   3
>>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |        Type = KeyInfo         |               Length          |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |                             KeyID                             |
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>     |                            KeyData                            |
>>     .                                                               .
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> 
>