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 | >> . . >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >
- Config Response typo Evangelos Haleplidis
- Re: Config Response typo Avri Doria
- Re: Config Response typo Avri Doria