Capwap Mailing List: Re: IESG Review Comment T24

[Pat Calhoun (pacalhou) (pcalhoun]

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