Subject: [Capwap] IESG Review Comment T24

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 16 Jun 2008 08:35:45 -0700

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 17 Jun 2008 14:19:55 +0200

OK with me. 

Dan

> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: Monday, June 16, 2008 6:36 PM
> To: [email-masked]
> Subject: [Capwap] IESG Review Comment T24
> 
> All,
> 
>    T24 - Sections 4.6.27, 4.6.28 - should not these two 
> messages include length of the 
>    Value fields? 
> 
> 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

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 17 Jun 2008 11:51:55 -0400

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

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 17 Jun 2008 12:10:26 -0400

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 17 Jun 2008 12:55:43 -0400

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 18 Jun 2008 18:25:21 -0700

OK, closing issue 65.

PatC 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2008 5:20 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: RE: [Capwap] IESG Review Comment T24

OK with me. 

Dan

>    T24 - Sections 4.6.27, 4.6.28 - should not these two messages 
> include length of the
>    Value fields? 
> 
> 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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 18 Jun 2008 18:41:10 -0700

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:[email-masked]] 
Sent: Tuesday, June 17, 2008 9:56 AM
To: Margaret Wasserman
Cc: [email-masked]
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

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 19 Jun 2008 08:08:54 -0400

Hi Pat,

> 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

> scheduled
> packet
> comparison),

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 19 Jun 2008 17:15:16 -0700

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
     |   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
     |                             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: [email-masked]
Subject: Re: [Capwap] IESG Review Comment T24

PatC 

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]]
Sent: Tuesday, June 17, 2008 9:56 AM
To: Margaret Wasserman
Cc: [email-masked]
Subject: Re: [Capwap] IESG Review Comment T24

Margaret

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 20 Jun 2008 09:05:40 +0200

OK with me. 

Dan

> Sent: Friday, June 20, 2008 3:15 AM
> To: Margaret Wasserman
> Cc: [email-masked]
> 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
> 
> 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 
> 
> 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.
> 
> 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
> 
> 
> 
> packet size

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 20 Jun 2008 10:20:52 -0700

Great - closing issue 65 with no backward compatibility issues.

PatC 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Friday, June 20, 2008 12:06 AM
To: Pat Calhoun (pacalhou); Margaret Wasserman
Cc: [email-masked]
Subject: RE: [Capwap] IESG Review Comment T24

OK with me. 

Dan

> 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
> 
> 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
> 
> 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.
> 

> of the lower-layer buffer.  I don't believe that this should ever 
> 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.
>