| Re: IESG Review Comment T24 | <– Date –> <– Thread –> |
From: Pat Calhoun (pacalhou) (pcalhoun cisco.com)
|
|
| Date: Fri, 20 Jun 2008 10:21:06 -0700 (PDT) | |
Great - closing issue 65 with no backward compatibility issues. PatC -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca [at] avaya.com] Sent: Friday, June 20, 2008 12:06 AM To: Pat Calhoun (pacalhou); Margaret Wasserman Cc: capwap [at] frascone.com Subject: RE: [Capwap] IESG Review Comment T24 OK with me. Dan > -----Original Message----- > From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] > Sent: Friday, June 20, 2008 3:15 AM > To: Margaret Wasserman > Cc: capwap [at] frascone.com > Subject: Re: [Capwap] IESG Review Comment T24 > > All, > > Having looked at this closer, the solution is actually really simple > and follows on Margaret's proposal. I am including here the new > proposed text, which maintains the original format in -10. The added > text is in the Data field description. > > <text> > 4.6.27. Image Data > > The Image Data message element is present in the Image Data Request > message sent by the AC and contains the following fields. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data Type | Data .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 27 for Image Data > > Length: >= 1 > > Opcode: An 8-bit value representing the transfer opcode. The > following enumerated values are supported: > > 1 - Image data is included > > 2 - Last Image Data Block is included (EOF) > > 5 - An error occurred. Transfer is aborted > > Data: The Image Data field contains up to 1024 > characters, and its > length is inferred from this message element's length field. If > the block being sent is the last one, the Opcode is set to 2. > The > AC MAY opt to abort the data transfer by setting the Opcode to > 5. > When the Opcode is 5, the Value field has a zero length. > > 4.6.28. Image Identifier > > The Image Identifier message element is sent by the AC to the WTP > and > is used to indicate the expected active software version that is to > be run on the WTP. The value is a variable length UTF-8 encoded > string, which is NOT zero terminated. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Data... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type: 28 for Image Identifier > > Length: >= 1 > > Data Length: Length of data field, with a maximum size of 65535. > > Data: A variable length UTF-8 encoded string containing the > firmware identifier to be run on the WTP, whose length MUST NOT > exceed 1024 octets. The length of this field is inferred from > this message element's length field. > </text> > > PatC > > -----Original Message----- > From: Pat Calhoun (pacalhou) > Sent: Wednesday, June 18, 2008 6:41 PM > To: Margaret Wasserman > Cc: capwap [at] frascone.com > Subject: Re: [Capwap] IESG Review Comment T24 > > So I frankly don't care, but I was trying to address the issue raised > by the IESG. Should I follow the desire of the chair or the AD? > > PatC > > -----Original Message----- > From: Margaret Wasserman [mailto:margaret [at] thingmagic.com] > Sent: Tuesday, June 17, 2008 9:56 AM > To: Margaret Wasserman > Cc: capwap [at] frascone.com > Subject: Re: [Capwap] IESG Review Comment T24 > > > I just spoke with Dan Romascanu on the phone (for a previously > scheduled CAPWAP status call), and I realized that my message about > this issue may have been unnecessarily terse... > > It is my understanding that we will always know the length of the > packet received at the CAPWAP layer, because it will be passed up to > us from the lower layer. Effectively, we will get a buffer and a data > length from the lower layer. I don't know of any system that wouldn't > provide that information. > > If we add a CAPWAP data length, we must always compare the CAPWAP data > length to the buffer length we received. This comparison could > theoretically result in one of three answers: > > (1) The CAPWAP data length indicates that the data ends at the end of > the lower-layer buffer. This is the expected case, and the only case > supported by the -10 version of the spec. In this case the CAPWAP > data length adds no value. > > (2) The CAPWAP data length indicates that the data ends before the end > of the lower-layer buffer. I don't believe that this should ever > happen because the other side should have passed its the correct > amount of CAPWAP data (and only that data) through DTLS and that's > what we should have recieved. I'm not sure whether we should accept > the data in this case or return an error. > > (3) The CAPWAP data length indicates that the data ends after the end > of the lower-layer buffer. In this case, we definitely have to return > an error, because we don't want to read off of the end of the lower > layer buffer. > > So, having a CAPWAP data length adds processing (to do this > comparison), and I don't see that it adds any value. It also breaks > compatibility with previous versions of CAPWAP (such as -10), so I > don't personally think we should add it. > > Margaret > > > > On Jun 17, 2008, at 11:51 AM, Margaret Wasserman wrote: > > > > > I'm personally not wild about changing the packet formats at this > > point, but there does appear to be a technical > justification for this > > change... > > > > Are there actually systems on which you wouldn't know the > packet size > > at this layer, though? Or is this just a theoretical technical > > justification? > > > > Margaret > > > > > > > > On Jun 16, 2008, at 11:35 AM, Pat Calhoun (pacalhou) wrote: > > > >> All, > >> > >> Here is the IESG Review Comment: > >> > >> T24 - Sections 4.6.27, 4.6.28 - should not these two messages > >> include length of the > >> Value fields? > >> > >> Originally, this was not included, because it could be inferred. > >> However, I can imagine a software architecture where the > packet size > >> is not known when the message elements are parsed. So I have added > >> them: > >> > >> <text> > >> 4.6.27. Image Data > >> [...] > >> > >> 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Data Type | Data Length | Data .... > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> [...] > >> > >> Data: Length of data field, with a maximum size of 1024. > >> > >> Data: The Image Data field contains up to 1024 characters. If > >> the > >> block being sent is the last one, the Opcode is set to 2. > >> The AC > >> MAY opt to abort the data transfer by setting the > Opcode to 5. > >> When the Opcode is 5, the Value field has a zero length. > >> > >> 4.6.28. Image Identifier > >> [...] > >> 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Vendor Identifier | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Value Length | Data... > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> [...] > >> > >> Data: Length of data field, with a maximum size of 65535. > >> > >> Data: A variable length UTF-8 encoded string containing the > >> firmware > >> identifier to be run on the WTP. > >> </text> > >> > >> PatC > >> _________________________________________________________________ > >> To unsubscribe or modify your subscription options, please visit: > >> http://lists.frascone.com/mailman/listinfo/capwap > >> > >> Archives: http://lists.frascone.com/pipermail/capwap > > > > _________________________________________________________________ > > To unsubscribe or modify your subscription options, please visit: > > http://lists.frascone.com/mailman/listinfo/capwap > > > > Archives: http://lists.frascone.com/pipermail/capwap > > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap > _________________________________________________________________ > To unsubscribe or modify your subscription options, please visit: > http://lists.frascone.com/mailman/listinfo/capwap > > Archives: http://lists.frascone.com/pipermail/capwap >
- Re: IESG Review Comment T24, (continued)
- Re: IESG Review Comment T24 Pat Calhoun (pacalhou), June 18 2008
- Re: IESG Review Comment T24 Margaret Wasserman, June 19 2008
- Re: IESG Review Comment T24 Pat Calhoun (pacalhou), June 19 2008
- Re: IESG Review Comment T24 Romascanu, Dan (Dan), June 20 2008
- Re: IESG Review Comment T24 Pat Calhoun (pacalhou), June 20 2008
Results generated by Tiger Technologies using MHonArc.