Capwap Mailing List: Re: IESG Review Comment T24

[Pat Calhoun (pacalhou) (pcalhoun]

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