Capwap Mailing List: New Issue 105: Intro to section 4.8 incorrect

[Pat Calhoun (pacalhou) (pcalhoun]

Yes, you have a point that the introduction to section 4.8 is incorrect.
It also states that the variables in the section are valid when the WTP
does discovery of the AC, while many of the variables have nothing to do
with AC discovery. I am therefore proposing:

<text>
   This section defines the CAPWAP protocol variables, which are used
   for various protocol functions. Some of these variables are
   configurable, while others are counters or have a fixed value. For
non
   counter related variables, default values are specified. However,
   when a WTP's variable configuration is explicitly overridden by an
AC,
   the WTP MUST save the new value.
</text>
 
PatC
-----Original Message-----
From: Yong Zhang [mailto:yozhang [at] gmail.com] 
Sent: Friday, June 20, 2008 11:08 AM
To: Pat Calhoun (pacalhou)
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] questions
ondraft-ietf-capwap-protocol-specification-10.txt

For my questiion4. I didn't notice 4.8.7 exist. So it does not need to
change the name.

The first sentence in 4.8 said "A WTP or AC that implements the CAPWAP
Discovery phase MUST allow for
   the following variables to be configured by system management".
Maybe you need to rephrase this, since 4.8.2/3/4/9 are not configurable.

Thanks!

Yong

On Fri, Jun 20, 2008 at 10:50 AM, Pat Calhoun (pacalhou)
<pcalhoun [at] cisco.com> wrote:
> 1.   4.7.10 MaxFailedDTLSSessionRetry is not a timer. Should it be put
> in 4.8?
> <PRC> Correct, and this was already raised by Dan in his review and it

> has been moved to 4.8 already.
>
> 2.  4.8.2/3/4 are running time counters. They are not configurable.
> Should they be removed from here?
> <PRC> No, these are counters, and I believe they are appropriate in 
> this section. Yes, they are not configurable.
>
> 3.  4.8.8 ReportInterval. Is it a CAPWAP timer? Should it be in 4.7?
> This one seems not defined in the state machine transition. Is this 
> for
> 4.7.14 StatisticsTimer?
> <PRC> Yes, this needs to move to section 4.7, and it is referenced in 
> the Decryption Error Report message element. I have created issue 104 
> as an editorial issue.
>
> 4. 4.8.9 RetransmitCount. I think it should be called 
> MaxRetransmitCount. And "This is a monotonically increasing counter"
> need to be removed.
> <PRC> I'm ok changing the name if people think it provides more
clarity.
> However, it is a monotonically increasing counter - everytime a packet

> is transmitted, a RetransmitCount++ instruction is required.
>
> PatC
>