Subject: [Capwap] questions on draft-ietf-capwap-protocol-specification-10.txt

From: "Yong Zhang" <[email-masked]>
Date: Tue, 17 Jun 2008 18:32:10 -0700

Hi,

I have a question on the state machine in the AC side:

In page 24/25.  it is said:

AC: join -> image data happens when the AC receives the image data
request from WTP.
AC: join -> configure happens immediately after the AC transmits the join resp.

Does the WTP only send the image data request after it receives the
join resp?  If so,
the AC will not be able to go into the image data state. Did I miss
something here?

Also, Page 76, 4.6.29 image information. The length should be 20
instead of 18, right?

Where can I find an latest version of this draft? Since I joined the
email list last week, I saw
a lot of emails on the spec. changes.

Thanks!

Yong
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

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

Thanks for raising those two issues. They were real, and I have created
two issues to track them 102 and 103. I have created two separate
threads to monitor these two issues.

I will publish the updated spec once we are done dealing with the issues
raised during the IESG review.

PatC 

-----Original Message-----
From: Yong Zhang [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2008 6:32 PM
To: [email-masked]
Subject: [Capwap] questions
ondraft-ietf-capwap-protocol-specification-10.txt

Hi,

AC: join -> image data happens when the AC receives the image data
request from WTP.
AC: join -> configure happens immediately after the AC transmits the
join resp.

Does the WTP only send the image data request after it receives the join
resp?  If so, the AC will not be able to go into the image data state.
Did I miss something here?

Also, Page 76, 4.6.29 image information. The length should be 20 instead
of 18, right?

Where can I find an latest version of this draft? Since I joined the
email list last week, I saw a lot of emails on the spec. changes.

Thanks!

Yong

---

From: "Yong Zhang" <[email-masked]>
Date: Thu, 19 Jun 2008 11:51:24 -0700

Thanks for the response. I also saw the following issues:

1.   4.7.10 MaxFailedDTLSSessionRetry is not a timer. Should it be put in 4.8?

2.  4.8.2/3/4 are running time counters. They are not configurable.
Should they be removed from here?

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?

4. 4.8.9 RetransmitCount. I think it should be called
MaxRetransmitCount. And "This is a monotonically increasing counter"
need to be removed.

Thanks!

Yong

---

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

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

---

From: "Yong Zhang" <[email-masked]>
Date: Fri, 20 Jun 2008 11:08:25 -0700

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 26 Jun 2008 04:43:49 -0700

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:[email-masked]] 
Sent: Friday, June 20, 2008 11:08 AM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] questions

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

> <PRC> No, these are counters, and I believe they are appropriate in 
> this section. Yes, they are not configurable.
>
> the Decryption Error Report message element. I have created issue 104 
> as an editorial issue.
>

---

From: "Yong Zhang" <[email-masked]>
Date: Mon, 30 Jun 2008 08:23:42 -0700

This change is OK for me.

Yong