Capwap Mailing List: Re: IESG Review Comment T24

[Romascanu, Dan (Dan) (dromasca]

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
>