Re: Config Response typo

Avri Doria <avri@psg.com> Fri, 29 February 2008 13:37 UTC

Message-Id: <FRI.29.FEB.2008.143749.0100.>
Date: Fri, 29 Feb 2008 14:37:49 +0100
From: Avri Doria <avri@psg.com>
Subject: Re: Config Response typo
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)

Hi,

fixed in http://psg.com/~avri/forces/draft/draft-ietf-forces-protocol-14.txt

will submit once submissions reopen.

a.

On 25 Feb 2008, at 20:54, Evangelos Haleplidis wrote:

> Greetings to the list,
>
> I believe there is a typo in the Protocol ver13 draft:
>
> Page 44 for Config Response:
>
> |    Config    |   LFBselect  |   (SET-RESPONSE |   | Section 7.6.2 |
> |   Response   |              | SET-PROP-RESPONSE | |               |
> |              |              |    DEL-RESPONSE |   |               |
> |              |              |  COMMIT-RESPONSE)+  |               |
>
> It should be:
>
> |    Config    | (LFBselect)+ |   (SET-RESPONSE |   | Section 7.6.2 |
> |   Response   |              | SET-PROP-RESPONSE | |               |
> |              |              |    DEL-RESPONSE |   |               |
> |              |              |  COMMIT-RESPONSE)+  |               |
>
> I was wondering
>
> As it is written in the Config Response:
>
> It indicates whether the Config was successful or not on the FE and
> also
> gives a detailed response regarding the configuration result of each
> component.
>
> Regards,
> Evangelos Haleplidis.
>
>



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" <ehalep@gmail.com>

> 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:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Joel M. Halpern
> Sent: Tuesday, April 01, 2008 4:05 AM
> To: FORCES@PEACH.EASE.LSOFT.COM
> 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                            |
>>     .                                                               .
>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>
>