Subject: [Capwap] ME issues

From: "Yong Zhang" <[email-masked]>
Date: Thu, 3 Jul 2008 12:00:08 -0700

I saw some place define the me len use ">", and some place use ">=".
Maybe we should unify them into one format.

4.6.4   > 0   to >= 1

4.6.5  > 2  to >= 2       Here is an error!!

4.6.7

Num of Entries:   The number of instances of the Type/MAC Addresses
      fields in the array.  This value MUST NOT exceed 1024.

1024 should be 255. NOT exceed 255 mean it can be 255.

4.6.9 same as 4.6.7
4.6.18 same as 4.6.7

4.6.31 >0  to >=1

4.6.36 >=1 to >=6   this is an error.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Yong Zhang" <[email-masked]>
Date: Thu, 3 Jul 2008 13:30:40 -0700

1(reason) + 1(length) + 2(me type) + 2(me len)

4.6.37 len should be 4.

4.6.40 should be >= 22

4 (Vendor ID) + 4+4+1 (Model Number) + 4+4+1(Serial Number)

4.6.47 >0   to >=1

4.6.34 should define the "State" use a similar way used by 4.6.50
define the 'Static"

4.8.5 IdleTimeout is a timer. maybe need to be put into 4.7

4.7.11 ResponseTimeout, and 4.7.16 WaitJoin can be removed, since they
are not used any more.

6.2 Join Response
Should MUST ME be defined earlier than MAY ME?

8.9 Clear Config Response:

   The Clear Configuration Request message MUST include the following
   message element.

   o  Result Code, see Section 4.6.35

Shoule be RESPONSE here.

9.1 Figure 7. Is this a reasonable case?

If images are same, the WTP will go into Configure state.

9.1.1

  The decision that new firmware is to be downloaded to the WTP can
   occur in one of two ways:

      When the WTP joins the AC, the Join Response message includes the
      Image Identifier message element, which informs the WTP of the
      firmware it is expected to run. if the WTP does not currently have
      the requested firmware version, it transmits an Image Data Request
      message, with the appropriate Image Identifier message element.
      If the WTP already has the requested firmware, it simply resets.

Remove "If the WTP already has the requested firmware, it simply resets."?

9.6 Data transfer req

What's the use of Data transfer mode 4.6.17? The Data Transfer Data
has the mode field.

9.7 Data Transfer Response

   Upon receipt of a Data Transfer Response message, the WTP transmits
   more information, if more information is available.

What's this meaning of this? If the crash data or memory dump is too
large, WTP will segment
them, and transfer them using multiple Data transfer req messages.
The AC should maintain the
data offset by itself?   Or you want to say, the WTP will first sent
crash dump. It will send the memory
dump after it receives the response?

Yong

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 3 Jul 2008 13:31:47 -0700

I have created issue 140 to track this. 

> 4.6.4   > 0   to >= 1
I think in the end, unless there is an error, it doesn't matter.
However, if you believe it reads better, then OK.

> 4.6.5  > 2  to >= 2       Here is an error!!
Yes, this is an issue that I have fixed.

> 1024 should be 255. NOT exceed 255 mean it can be 255.
Oh right - being it is a one octet field, 255 is the max. I have made
the change.

> 4.6.31 >0  to >=1
It means the same thing, but if you believe it helps, ok.

> 4.6.36 >=1 to >=6   this is an error.
I agree - this needs to be fixed.

PatC

-----Original Message-----
From: Yong Zhang [mailto:[email-masked]] 
Sent: Thursday, July 03, 2008 12:00 PM
To: [email-masked]
Subject: [Capwap] ME issues

4.6.4   > 0   to >= 1

4.6.7

4.6.9 same as 4.6.7
4.6.18 same as 4.6.7

4.6.31 >0  to >=1

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 3 Jul 2008 14:11:02 -0700

I have created Issue 141 to track these issues.
 
> 1(reason) + 1(length) + 2(me type) + 2(me len)
You raised this already in issue 140, so I am claiming it is a duplicate
and rejecting this one.

> 4.6.37 len should be 4.
Yes, this is a bug. It needs to be 4. 

> 4 (Vendor ID) + 4+4+1 (Model Number) + 4+4+1(Serial Number)

No, the correct value is in fact 14 since the Vendor ID is only presence
once, not once for each sub-element. The sub-element mentions that two
board elements MUST be present, which is 14 octets.

> 4.6.47 >0   to >=1
Again, I don't see a problem here, but will make the change if you think
it is clearer.

> 4.6.34 should define the "State" use a similar way used by 4.6.50
define the 'Static"
This would break interoperability, as it would change the values used.
I'd like to make sure that no one objects to break -10 compatibility.
This is a fairly small nit.

> 4.8.5 IdleTimeout is a timer. maybe need to be put into 4.7
Yes, that probably makes sense.

> 4.7.11 ResponseTimeout, and 4.7.16 WaitJoin can be removed, since they
are not used any more.
PAT WAITING ON YONG's RESPONSE.

> Should MUST ME be defined earlier than MAY ME?
This doesn't really break anything. I'm not sure we need to address
this.

>    o  Result Code, see Section 4.6.35
Correct. This is a valid editorial issue.

> If images are same, the WTP will go into Configure state.

No, actually the text was not providing enough information. The text is
now:
<text>
   Figure 7 provides an example in which the WTP has the image specified
   by the AC in its non-volative storage, but is not its current running
   image.  In this case, the WTP opts to NOT download the firmware and
   immediately reset to the requested image.
</text>

> Remove "If the WTP already has the requested firmware, it simply
resets."?
Again, the text was not sufficient. It now reads:

<text>
            If the WTP already has
		the requested firmware in its non-volatile flash, but is
not its 
		currently running image, it simply resets to run the
proper firmware.
</text>

> What's the use of Data transfer mode 4.6.17? The Data Transfer Data
has the mode field.
That is very repetitive, and unnecessary. I would propose removing the
mode from 4.6.16, and simply using the message element defined in
4.6.17. I checked, and it is ONLY used during the data transfer request,
so I do not see any harm. However, this breaks -10, and is only
repetitive. I want to make sure that there are no concerns in making
this change from others in the WG.

> What's this meaning of this? If the crash data or memory dump is too
large, WTP will segment them, and transfer them 
> using multiple Data transfer req messages.
Yes, this is a series of back and forth, where the WTP will, if
necessary, break the information to be sent across multiple packets. The
CAPWAP transmission layer will ensure it is reassembled in the proper
order. Maybe I'm not understanding the question you are asking.

PatC

-----Original Message-----
From: Yong Zhang [mailto:[email-masked]] 
Sent: Thursday, July 03, 2008 1:31 PM
To: [email-masked]
Subject: Re: [Capwap] ME issues

4.6.37 len should be 4.

4.6.40 should be >= 22

4.6.47 >0   to >=1

4.6.34 should define the "State" use a similar way used by 4.6.50 define
the 'Static"

6.2 Join Response

Shoule be RESPONSE here.

9.1.1

Remove "If the WTP already has the requested firmware, it simply
resets."?

9.6 Data transfer req

What's the use of Data transfer mode 4.6.17? The Data Transfer Data has
the mode field.

large, WTP will segment them, and transfer them using multiple Data
transfer req messages.

Yong

---

From: "Yong Zhang" <[email-masked]>
Date: Thu, 3 Jul 2008 14:27:37 -0700

> This doesn't really break anything. I'm not sure we need to address
I saw other message definitions always put MUST MEs in the beginning.

then how the AC knows it has received all the debug data from the WTP?

Yong

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 7 Jul 2008 09:13:59 -0700

> I saw other message definitions always put MUST MEs in the beginning.

Well, I think this is really a nice to have, but while looking at the
issue you are pointing out, I *just* noticed that there is a cut/paste
error in this section since the text includes:
<bad text>
   One of the following message elements MUST be included in the
   Discovery Response Message:
</bad text>

Clearly, that should have been a Join Response, so since I'm add it, I
will reorder the text to make sure that it is consistent with the rest
of the message definitions, and fix the cut/paste error.

> Yes, this is a series of back and forth, where the WTP will, if
necessary, break the information to be sent across 
> multiple packets. The CAPWAP transmission layer will ensure it is
reassembled in the proper order. Maybe I'm not 
> understanding the question you are asking.
> 

I see the point you are raising, and this is something we fixed for the
image transfer. Because of the scope of the issue, I will create a
separate issue to track this one. So let's continue this conversation in
a separate thread, which I will initiate shortly.

PatC
> Yong

On Thu, Jul 3, 2008 at 2:11 PM, Pat Calhoun (pacalhou)
<[email-masked]> wrote:
> You raised this already in issue 140, so I am claiming it is a 
> duplicate and rejecting this one.
>
>> 4.6.37 len should be 4.
> No, the correct value is in fact 14 since the Vendor ID is only 
> presence once, not once for each sub-element. The sub-element mentions

> that two board elements MUST be present, which is 14 octets.
>
>> 4.6.47 >0   to >=1
> Again, I don't see a problem here, but will make the change if you 
> think it is clearer.
>
>                the requested firmware in its non-volatile flash, but 
> is not its

> 4.6.17. I checked, and it is ONLY used during the data transfer 
> request, so I do not see any harm. However, this breaks -10, and is 
> only repetitive. I want to make sure that there are no concerns in 
> making this change from others in the WG.
>
> necessary, break the information to be sent across multiple packets. 
> The CAPWAP transmission layer will ensure it is reassembled in the 
> proper order. Maybe I'm not understanding the question you are asking.
>
> PatC
>