Subject: [Capwap] Editorial - WTP Event Request

From: "Saravanan Govindan" <[email-masked]>
Date: Mon, 3 Jul 2006 15:02:10 +0800

All,

I would like to suggest an editorial update to Section 9.5 (WTP Event
Request). 

This is based on earlier discussions of how WTP Event Request serves as
an implicit keep alive mechanism for the WTP. I believe this observation
can be made explicit in this section.

I suggest the following after the 1st paragraph of Section 9.5;

"The exchange of WTP Event Request serves as an implicit keep alive
mechanism for the WTP. The arrival of a WTP Event Request message at the
AC indicates the WTP is operational. In cases where WTP Event Request is
not exchanged, explicit keep alive is used (see Section 7)."

The current text in Section 7 refers to maintaining the control
communication channel, whereas the suggestion above refers to the WTP as
a whole. 

Comments?

Saravanan

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

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

---

From: Scott G Kelly <[email-masked]>
Date: Mon, 03 Jul 2006 06:20:16 -0700

Hi Saravanan,

I thought there was general agreement that if *any* authenticated 
control traffic (not just an event request) is observed during the echo 
interval, this is implicit proof of liveness, and no echo request is 
required for that interval. Having text like what's suggested below 
(that only references the event request) might lead people to 
incorrectly conclude that only an event request can obviate the need for 
an echo exchange.

Why should we have text which confers this special status only on the 
event request, rather than on all/any authenticated control channel traffic?

Scott

Saravanan Govindan wrote:
> I suggest the following after the 1^st paragraph of Section 9.5;
> 
>  
> 
> “The exchange of WTP Event Request serves as an implicit keep alive 
> not exchanged, explicit keep alive is used (see Section 7).”
> 
>  
> 
> ------------------------------------------------------------------------
>