Capwap Mailing List: Re: Issue 30: Inconsistent state tracking on AC prior toDTLSEstablishment

[Charles Clancy (clancy]

Scott,

> I'm really surprised you helped Pat design these state machine
> changes, after saying pretty much the same things I say above in your
> response to his issuer tracker post. Was there some compelling
> argument that changed your mind? If so, please share it - I am not
> intransigent in my position, but from what I can see, what you guys
> are proposing makes no sense, and only serves to make the state
> machine in the document conform to an implementation which maintains
> discovery state.

Issue #30 was originally about maintaining state from Discovery to DTLS 
setup, which we can all agree is a bad idea.  In an attempt to better 
clarify how the AC state machine works, to prevent implementors from 
doing stupid things, the idea of global state and per-WTP state emerged, 
and the state machine tries to capture that.

The idle->discovery->idle loop is global AC state, and not per-WTP.  It 
represents the global AC listener thread receiving a discovery request, 
and sending a discovery response, but has nothing to do with per-WTP state.

In my opinion, the changes will make it harder for an implementor to 
create an implementation that creates per-WTP state before it is 
required, and helps protect against DoS attacks.

I think we're all in agreement about the design goals, but are 
misunderstanding each others' ways to meet those goals.

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland