Capwap Mailing List: Re: IESG Review Comment T24

(continued)

Hi Pat,
On Jun 18, 2008, at 9:41 PM, Pat Calhoun (pacalhou) wrote:
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?

This isn't really how it works...  Dan expressed an opinion about the  
spec.  I expressed a dissenting opinion.  Neither of us just gets to  
decide...  We should see if others in the WG have an opinion and  
whether there is any consensus on the issue.  It might be helpful if  
Dan responds to my message to explain his reasoning, point out flaws  
in my argument and/or say that he has changed his mind.
I would guess that most of the WG members have not stayed current  
with the >100 messages that have come out in the past few days.   
Maybe once you and Dan are done resolving all of the non-contentious  
issues, one of us could send a message summarizing the remaining  
issues and asking for others' opinions?
Margaret

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

Re: IESG Review Comment T24	<– Date –> <– Thread –>
From: Margaret Wasserman (margaretthingmagic.com)
Date: Thu, 19 Jun 2008 05:09:01 -0700 (PDT)