Subject: Re: [Capwap] Proposed resolution to Issue 177 WTP Reboot Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01 operations

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 28 Nov 2006 15:38:29 -0800

Given the session is secured at the point the join is sent, I am
lukewarm with option 2.
 
That said, given the config state occurs right afterwards, I see little
benefit, but am willing to agree.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Tuesday, November 28, 2006 3:11 PM
	To: Pat Calhoun (pacalhou)
	Cc: Michael Montemurro; [email-masked]
	Subject: Re: [Capwap] Proposed resolution to Issue 177 WTP
Reboot Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01
operations

	Yes, that's the only reason I can see for including the info.

	On 11/28/06, Pat Calhoun (pacalhou) <[email-masked] > wrote:

		Do you anticipate the AC may decide not to allow the
join to proceed because of the reboot statistics? Note that accepting
the join is now rather trivial compared to the actual DTLS session that
had to be established beforehand.

		Pat Calhoun
		CTO, Wireless Networking Business Unit
		Cisco Systems

________________________________

			From: Dorothy Stanley
[mailto:[email-masked]] 
			Sent: Tuesday, November 28, 2006 2:47 PM
			To: Pat Calhoun (pacalhou)
			Cc: Michael Montemurro; [email-masked]
			Subject: Re: [Capwap] Proposed resolution to
Issue 177 WTP Reboot Statisticsbelongs in the Join/was Re: A commentary
on CAPWAP-01 operations

			Pat,
			
			In the current draft, the AC has no indication
of the stability of the 
			WTP before it accepts the Join Request. The
value for adding
			WTP Reboot statistics to the Join Request is  to
provide the reboot statistics, 
			if they are available.
			
			There seemed to be three options to addressing
this comment:
			1) Reject the comment, no change to the draft.
			2) Provide the option for the WTP to send the
Reboot statistics to the AC in the Join Request
			3) Require the WTP to send the Reboot
statistics.to the AC in the Join Request
			
			I proposed option 2, allowing the WTP to provide
them if available. This option
			seems to allow for your stated preference.
			
			Dorothy

			On 10/9/06, Pat Calhoun (pacalhou)
<[email-masked]> wrote: 

				I personally prefer to start maintaining
configuration and status state on the WTP after the join is complete. Is
there a problem that arises with the current draft? Is this just a
personal preference, or is there a bug?

				Pat Calhoun
				CTO, Wireless Networking Business Unit
				Cisco Systems

________________________________

				From: Dorothy Stanley
[mailto:[email-masked]] 
				Sent: Friday, September 29, 2006 2:22 PM
				To: Michael Montemurro
				Cc: [email-masked]
				Subject: [Capwap] Proposed resolution to
Issue 177 WTP Reboot Statisticsbelongs in the Join/was Re: A commentary
on CAPWAP-01 operations

				All,
				 
				Issue 177, "WTP Reboot Statistics
belongs in the Join"
				is listed below:
				29) WTP Reboot Statistics belongs in the
Join, and the reasons listed
				are not clear enough.
				
				<PRC> Doesn't really matter whether this
is included in the
				configuration or the join, but if the WG
agrees to move it. We can

				clarify some of the reasons, as long as
it provides value.
				Believing that there may be times when
it is desirable for the WTP to provide 
				information to the AC about its
stability, the proposed resolution to Issue 177 is 
				to insert the following text at the end
of
				Section 6.1 "Join Request":
				 
				The following message element may be
included in the Join Request message:
				- WTP Reboot Statistics, see Section
4.4.44.
				 
				Comments please,
				 
				Thanks,
				 
				Dorothy

				On 6/30/06, Michael Montemurro
<[email-masked]> wrote: 

				David, Pat,
				 
				I created issues 150-198 to deal with
the points in David's email. Happy hunting!
				 
				Mike

				On 6/27/06, Pat Calhoun (pacalhou)
<[email-masked] > wrote: 

				Going through David's lengthy document,
he has raised an interesting
				number of points that I believe require
issues to be created. At one 
				point I'm paraphrasing Dave's comments
in order to be brief, and
				introducing my own numbering scheme.
				
				1) Can message elements be in any order?
(I believe they should be)
				
				<PRC> Yes, and I suspect we need to
include text to make it more 
				obvious.

				2) Are all specified message elements
required? (The obvious answer is
				"yes", but this document doesn't discuss
versioning. For example, what
				if in a new version of CAPWAP an
additional message element was to be 
				added. Would a new message type be
created and the additional message
				element added to it, or the existing
type reused?)
				
				<PRC> This is a great question, and one
that does need to be addressed
				in the spec. In the Diameter protocol we
dealt with this issue by 
				including a "Mandatory to implement"
bit. If any AVP was received, whose
				bit was set, yet was not recognized,
then the request had to be
				rejected.
				
				<PRC> We could consider something
similar here, but I believe with the 
				firmware download component of the
protocol it may be less of an issue -
				although not guaranteed. I would hope
(and expect) that as the CAPWAP
				protocol extends, the AC would push new
firmware to the WTP. This does 
				require that the initial part of the
state machine be fairly static, and
				this could be an area where the
"Mandatory to implement" bit could be
				useful as it would allow the AC to fall
back to older protocol behavior. 
				
				3) CAPWAP-01 doesn't do a good job of
indicating which message elements
				can be repeated.
				
				<PRC> Another good point. When we list
the message elements, we should
				note whether the frequently is 0-1
(meaning absent or once), 1 (only 
				once) or 0+ (meaning any number of them
could be present.

				4) Can "additional" message elements be
added to a message? (I believe
				so for reporting capabilities,
statistics, and     events. For
				configuration, there is nothing in the
protocol that says what happens
				when one end gets an configuration
element it doesn't know about.
				Should it be ignored, and the other
elements processed, or should the
				complete operation     failed?) 
				
				<PRC> The "Mandatory to implement" bit
above could address this issue.
				If an unrecognized message element is
found to have the bit set, then
				the whole message needs to be rejected.
If the bit is not set, the 
				message element may be safely ignored.

				5) The config has a concept of "default
value" for each configuration
				attribute. However, the default values
are not clearly specified. This
				needs to be resolved to be able to
support "default values". 
				
				<PRC> Another good point raised by
David.

				6) the documentation of which "binding
specific" message elements are to
				be included with CAPWAP messages is not
consistent, and is difficult to 
				follow.
				
				<PRC> Has this been addressed in the
latest (-02) document?

				7) There are some message elements that
cause "actions". This approach
				to protocol design is problematic and
should be eliminated. 
				
				<PRC> Could you be more specific as well
as provide guidance on what you
				would like to see?

				8) The message types are inconsistently
named, and do not follow the
				conventions of well designed protocols.
Can the operations be named 
				consistently with the following
terminology:
				  1) request/response (used to
get/set/perform action)
				  2) report/ack (use to tell the other
side something)
				
				<PRC> Could you provide your thoughts on
which messages fall within 
				which one of your categories?

				9) Many of the configuration items, and
status items are not listed in
				one section with definitions. (Well make
it two sections - one for
				CAPWAP and the other which is "binding"
specific.) For example, not all 
				of the time period lengths are
identified and specified in section 4.5.
				
				<PRC> Unfortunately, the document has
gone back and forth a few times
				and before we opt to change the
structure of the document, I'd like to 
				ensure that we have broad agreement on
what we want - with the
				understanding that we will never make
everyone happy.

				10) each operation should have listed in
which states it can be sent and
				received
				
				<PRC> I do not understand your comment.

				11) All strings, such as WTP location,
should be changed from US-ASCII
				encoding to UTF-8 encoding.
				
				<PRC> Agreed.
				
				12) The term "mobile" is not really
accurate when describing wireless 
				interfaces, since wireless does not
imply      mobile. Can we just use
				the techie term "STA" instead.
				
				<PRC> I agree we should use the term
Station, or STA for short.

				13) The WTP Descriptor message element
contains too much information, 
				lacks clarity on the WTP encryption
field and includes version numbers,
				which should be in string form.
				
				<PRC> To the first point, I disagree. I
think there is value in knowing
				everything about the WTP. The AC vendors
can expose whatever information 
				they want, but I don't believe anything
is unnecessary.
				
				<PRC> To the second point, this is one
of those areas where the concept
				of the technology binding creates
complexity. Given that we cannot
				simply discuss 802.11i at this point,
the only thing we can do is punt
				to another section in the technology
binding section. That said, I agree
				with Dave that the 802.11 binding
section is too light in this area.
				However, I would much prefer that
instead of trying to address this 
				specific issue, we discuss whether we
should even be supporting the mode
				of operation where 802.11i is performed
in the AC - especially with the
				introduction of DTLS to secure the data
plane. Right now, it just feels 
				like we have too many options and I am
worried that interoperability
				will be severely impacted (not to
mention protocol complexity).
				
				<PRC> To the last point, I have no
issues with including text stating 
				that the version numbers should be in
string form.

				14) The WTP Descriptor information is
not required at Join time.
				
				<PRC> Well, as far as I can tell, I
think there's value in knowing
				whether the WTP can even be supported by
the AC. So the more info is 
				provided by the WTP, the better the AC
can determine whether it should
				just ignore the WTP or not. This could
be done because it knows that the
				firmware running on the WTP is not
compatible, and it has no new
				firmware to download.

				15) Are the values in the WTP Frame
Encryption a capabilities bit, or an
				enum?
				
				<PRC> Looks like an enum to me. Not sure
what Dave would prefer the text
				to read. There are various other similar
comments throughout, which I 
				will not repeat here.

				16) The Discovery Response is broken.
The AC SHOULD NOT be providing any
				info to a WTP (or something that claims
to be a WTP). Also, the AC
				should tell the WTP what to do next,
with choices: 1) Ok to try to join, 
				2) don't try to join, 3) try
discover on a list of
				returned ACs)
				
				<PRC> I don't believe there is an issue
with sending the AC's
				information to the WTP, but would
solicit input from the list. That 
				said, some of the information in the AC
Descriptor is required, such as
				the current load on the AC. No point is
trying to join if he AC
				indicates it's already at max capacity.
				<PRC> I believe if the AC does not
return the response, then it implies 
				(2). Otherwise, it is (1). (3) is
handled during the join or configure
				process, which I believe is right.

				17) Is AC Name text?
				
				<PRC> Yes, and same with WTP Name.

				18) Primary Discovery are not required. 
				
				<PRC> Disagree. Required for failover.

				19) The text does not make it clear that
the contents of the WTP
				Location is informative only, and as
Dave calls it, a "scratchpad".
				
				<PRC> Well, to be honest, I thought the
example "next to the fridge" 
				made it clear that the information did
not derive from any scientific
				formula. The description also states
this is a user-defined. I believe
				this should be good enough.

				20) Session is not required
				
				<PRC> I believe you may be correct that
with the transition to DTLS,
				this is no longer required.

				21) need to send "common name" as found
in the WTP CERT so that the AC
				can verify
				
				<PRC> The protocol currently relies on
the MAC address being the key
				that binds the certificate to the WTP. I
don't see a need to change
				this.

				22) Result code in Join Response is not
sufficient, for instance WTP HW 
				not supported.
				
				<PRC> Well, the protocol does not
require this because the Discovery
				Response would never be sent (as the
protocol stands today).

				23) AC IPv4/IPv6 Addr discusses
clustering, which is unnecessary. 
				
				<PRC> Agreed.

				24) Change Echo to Keepalive or
heartbeat.
				
				<PRC> I call it potato....

				25) What if all of the message elements
do not fit within a single
				CAPWAP control frame. 
				
				<PRC> We should address this.

				26) AC Name with Index is all messed
up...
				
				<PRC> Not really. You simply include
more than one, and the index field
				is clearly the priority. Don't
understand the Multi-AC comment. No 
				inter-AC protocol implied here.

				27) WTP Board Data belongs in the Join,
not configure.
				
				<PRC> Agreed, but wonder even more why
we are duplicating this
				information across both the WTP
Descriptor and the WTP Board Data 
				message elements.

				28) The WTP Static IPv4 Address should
not have the Static bit, but
				instead state that 0.0.0.0
<http://0.0.0.0/> means a static address is not to be used.
				
				<PRC> I don't have an issue with this
request, but in the end we have 
				the same function. The reason why I
state this is that we can refine
				this protocol until the cows come home,
and at one point we need to draw 
				a line in the sand.

				29) WTP Reboot Statistics belongs in the
Join, and the reasons listed 
				are not clear enough.
				
				<PRC> Doesn't really matter whether this
is included in the
				configuration or the join, but if the WG
agrees to move it. We can 
				clarify some of the reasons, as long as
it provides value. 

				30) The IEEE 802.11 WTP Radio
Configuration message element's BSSID
				field should be an array.
				
				<PRC> Disagree.

				30) The IEEE 802.11 WTP Radio
Configuration message element's Country
				Code is not clear enough.
				
				<PRC> The text points to the actual MIB
element in the 802.11-1999
				standard, which very clearly defines the
contents of the field. I don't 
				think there's value in replicating the
format of this field in the 
				CAPWAP standard.

				31) There seems like an awful lot of
additional configuration message
				elements that need to be specified here!
				
				<PRC> Having built a protocol based on
this, it's not clear to me what's 
				missing. I think it would be useful if
you provided concrete details on
				what's missing.

				32) Configuration Status is just plain
broken because any configuration 
				change operation may fail and there is
no           response to the 
				configuration changes specified in this
command.
				
				<PRC> There certainly is - I guess I
don't understand the concern.

				33) Use of Change State Event should
instead be Radio Admin State. 
				
				<PRC> Perhaps the two are not described
properly. The first is used by 
				the WTP to inform the AC that something
has occurred with a radio. The
				second is used by the AC to
enable/disable a radio.

				34) Report Timer needs to be in section
4.5 or 11
				
				<PRC> ok

				35) Should Idle Timeout be per radio, or
per WTP, and should the value
				be defined in section 4.5 or 11.
				
				<PRC> Per WTP, and yes. I believe it is
fine as it is. 

				36) WTP Fallback isn't well defined, and
should be removed. 
				
				<PRC> Disagree. I believe it is
necessary to create enough resiliency in
				the protocol/service.

				37) How are the "Rate Set" and
"Supported Rates" encoded. 
				
				<PRC> This was fixed in the -02 

				38) AC Timestamp doesn't belong in the
configuration, but instead in the
				join.
				
				<PRC> Not sure this really matters....

				39) Add MAC ACL Entry - this is so
strange and is being managed like no 
				other configuration data.
				
				<PRC> I do not understand the comment

				40) Decryption Error Report Period is
not defined in section 4.5 or 11
				
				<PRC> ok, and note that the information
has been moved to the IEEE 
				802.11 RSNA Error Report From Mobile

				41) Configuration Update Response.
today, there are primarily two types
				of configuration models. The first is
when config is changed, it is only
				changed in the volatile copy (the memory
or running). An explicit 
				command is needed to save the config to
nonvolatile storage. The second
				model has config both running (volatile)
and saved (nonvolatile) config
				changed when a config change is made.
And there might be a special
				command to have a config change apply to
only one. In this case, there
				is no need for a "save config to
nonvolatile" command. It is not clear
				what is suppose to be supported here in
CAPWAP, and how does CAPWAP 
				support devices with no or very limited
nonvolatile storage for config!
				
				<PRC> CAPWAP does not support WTPs with
no nonvolatile storage. The
				protocol has the AC push configs to the
WTP, which saves them at the 
				time they are received. I do not believe
anything else is required.

				42) Configuration Update Response
includes the Result Code message
				element, which includes values that do
not appear to be relevant for 
				this message, and there are plenty of
other failure cases
				
				<PRC> ok, but note that we are sharing a
common message element. Any
				suggestions on how to address your
issue?

				43) Change State Event Report. This
seems a little silly to be sent in 
				the "configure" state. It seems only
appropriate for the "run" state.
				Some might argue that even in the "run"
state it shouldn't be sent after
				a "config update" request that changes
the operational state. However, 
				in the "run" state, it may take a while
to have the operational state
				change to follow the admin state. Thus,
I think it is OK in the "run"
				state after config changes."
				
				<PRC> I believe this was addressed in
-02. 

				44) Clear Config Request. this operation
has several problems, which
				include:
				   1) currently, the CAPWAP-01 spec says
that this can only be done in
				the "run" state. This is silly. It
should also be possible in the 
				"configure" state.
				<PRC> I wonder why the AC would even
consider clearing the WTP's state
				before it even knows how it is
configured.
				
				   2) the value of "manufacturing
defaults" is not defined, and a poor 
				term to use, since it implies that that
each manufacturer can have
				different values. If so, then the AC
will have no knowledge of the
				config on the WTP! The problem of
"default config values" has already be 
				mentioned above. After each config
attribute has been defined with a
				default value, then the proper term
would be "CAPWAP config defaults".
				<PRC> Yes, you've raised this point
already, and I agree that it does 
				need to be addressed.
				
				   3) This operation is not defined to
have a response. This is broken,
				since any config change can fail. Also,
it is not defined what happens
				next. Does this cause the WTP to reboot
an start a "clean discovery"? 
				<PRC> This was addressed in -02

				45) Image Data Request. Yes, there are
actually three different "Image
				Data Request" messages. Which one is
determined          by which of the
				three message elements is contained.
This is completely silly! There 
				should be three separate operations!
Additionally, how does the WTP know
				which image to get? The AC should be
making that decision.
				
				<PRC> I believe the WTP is the only
device that knows what it's filename 
				should be. Why would an AC vendor know
about file naming conventions
				used by the WTP vendors? I believe your
other issues are discussed in
				the next items.

				46) Image Data Response. this is silly.
This operation can fail! There 
				needs to be message element that
indicates the          result.
				
				<PRC> How so? This is only used to send
firmware to the WTP. Not clear
				what could fail... Reading the image
from flash?

				47) Image Data Request. when starting
over again at the WTP start state, 
				the WTP shouldn't use the "normal"
discovery process, but instead "fast
				track" a connection back to the AC that
just downloaded the image. With
				a little more          work, we could
probably figure out a way to reuse 
				the old DTLS session.
				
				<PRC> To what gain? What is so expensive
about the discovery, and what
				happened if the AC was not longer
reachable?

				48) opcode - if this is here, might as
well also have a value that 
				indicates last block of the image file,
instead of looking at the block
				size.
				
				<PRC> But we're just changing for the
sake of changing - the protocol
				works as-is.

				49) since this operation does not have
the block number as a parameter, 
				the WTP must determine the block number
via the CAPWAP message header
				sequence number.  NOTE: DTLS does not
provide in-order delivery of
				packets. Also, this requires the WTP to
remember state. This message
				element should be re-engineered to have
the following subfields: 
				[edited]
				
				<PRC> The control header includes a
sequence number, and while we can
				change the current protocol to match
your recommendations, the protocol
				does work. If it ain't broken...

				50) Image Data Response. this is silly.
This operation can fail!  For 
				example, the WTP can run out of space to
store          the block, or
				there could be a failure in writing the
block to storage. (Or as "Image
				Data Request"(9.1a) is presently
specified, the checksum match could 
				fail.) There needs to be message element
that indicates the result.)
				Note: don't need a block number field,
since request and responses are
				paired.
				
				<PRC> We can include a result code

				51) Image Data Request. silly beyond
belief 
				
				<PRC> Beauty is in the eye of the
beholder ;-). Seriously, the protocol
				does work, so what exactly are you
looking for?

				52) Image Data Response. This is silly.
This operation can fail! There
				needs to be message element that
indicates the          result.
				
				<PRC> See above comment.
				
				53) Reset Request. ...
				
				<PRC> The comment is irrelevant now that
Clear Config has changed.

				54) Reset Response. this is silly. This
operation can fail! There needs
				to be message element that indicates the
result.
				
				<PRC> I sense a trend. I will stop
including these messages from now on.

				55)Duplicate IPv4 Address. how often is
this reported if the condition
				remains?
				
				<PRC> Only required once, I think, but
we may want to include some text
				covering that.

				56) the list of events seems
understated! 
				
				<PRC> Text and conditions please

				57) Data Transfer Request. Nice to have
- remove.
				
				<PRC> Disagree. Providing diagnostics
capabilities is required.

				58) Mobile Config Request. the actual
details of how this works on both 
				splitMAC and especially localMAC are not
well specified. That is, only
				the figures and text in sections 11.1.1
and 11.1.2 provide any clue as
				to events that would cause an AC to send
this message type. Also, there 
				are restrictions on combinations of
parameters that can be included in
				the message.
				
				<PRC> I wonder whether other folks agree
that more details are required.

				59) it doesn't say if one message can be
used to update more than one 
				STA. It should be able.
				
				<PRC> No, otherwise you end up with the
problem of associating specific
				message elements with a given mobile.
One mobile per request.

				60) IEEE 802.11 Mobile. shouldn't the
STA MAC address be included so 
				this message element can be matched with
a (4.4.8)Add Mobile message
				element?
				
				<PRC> I believe this is to your previous
point, but the protocol assumes
				one mobile per request.

				61) IEEE 802.11 Update Mobile QoS. s
this for data traffic to the AC? If
				so, then why is this an 802.11 message
element
				
				<PRC> Intended to be a way to push
policies to the WTP to prioritize
				mobile traffic.

				62) IEEE 802.11 WLAN Config Request. why
is a new message type that is
				802.11 specific needed to modify 802.11
WLANs? It seems like the
				existing "(8.4)Configuration Update
Request" message could be used.
				
				<PRC> To be more specific only. 

				63) note here there are information
elements to create, delete, and
				modify WLANs. However, for message type
"(10.1)Mobile Config Request",
				there is only add and delete (and the
"add" used to modify). 
				
				<PRC> Correct. The protocol requires the
AC to resend a new add with a
				different policy. No specific reason,
but if this is deemed
				inconsistent, we could change it.

				64) IEEE 802.11 Assigned WTP BSSID. The
mapping of WLAN IDs to BSSIDs 
				seems like it needs a little more work
				
				<PRC> What exactly would you like to
see?

				Pat Calhoun
				CTO, Wireless Networking Business Unit
				Cisco Systems

				> -----Original Message----- 
				> From: David T. Perkins
[mailto:[email-masked]]
				> Sent: Thursday, June 22, 2006 4:31 PM 
				> To: [email-masked] 
				> Subject: [Capwap] A commentary on
CAPWAP-01 operations
				>
				> HI, 
				>
				> I've attached a long file that
summarizes the operations in
				> CAPWAP-01.
				> Enjoy,
				> /david t. perkins 
	
_________________________________________________________________ 
				To unsubscribe or modify your
subscription options, please visit:
	
http://lists.frascone.com/mailman/listinfo/capwap 
				
				Archives:
http://lists.frascone.com/pipermail/capwap

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

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

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

---

From: "sujay gupta" <[email-masked]>
Date: Wed, 29 Nov 2006 13:21:54 +0530

Hi Dorothy,
Assuming an AC may not allow a WTP to join based on WTP Reboot
Stats.(possibly based on some user policy on the AC) thus  this parameter
should be included  in  Join Request is not too convincing.
Tomorrow a user policy may prohibit a WTP based say ex: on WTP Radio Stats
information, shall we go again and add to the Join Request another
parameter?
The implementation could send a Reset Request to the WTP after the
Configuration message exchange if it doesn't like the WTP Reboot Stats !
Best Regards,
Sujay

On 11/29/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
>
>  Given the session is secured at the point the join is sent, I am lukewarm
> with option 2.
>
>  ------------------------------
> *From:* Dorothy Stanley [mailto:[email-masked]]
> *Sent:* Tuesday, November 28, 2006 3:11 PM
> *To:* Pat Calhoun (pacalhou)
> *Cc:* Michael Montemurro; [email-masked]
> *Subject:* Re: [Capwap] Proposed resolution to Issue 177 WTP Reboot
> Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01 operations
>
> >  Do you anticipate the AC may decide not to allow the join to proceed
> > because of the reboot statistics? Note that accepting the join is now rather
> > trivial compared to the actual DTLS session that had to be established
> > beforehand.
> >
> >
> > Pat Calhoun
> >  ------------------------------
> > *From:* Dorothy Stanley [mailto:[email-masked]]
> > *Sent:* Tuesday, November 28, 2006 2:47 PM
> > *To:* Pat Calhoun (pacalhou)
> > *Cc:* Michael Montemurro; [email-masked]
> > *Subject:* Re: [Capwap] Proposed resolution to Issue 177 WTP Reboot
> > Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01 operations
> >
> >  Pat,
> >
> > In the current draft, the AC has no indication of the stability of the
> > WTP before it accepts the Join Request. The value for adding
> > WTP Reboot statistics to the Join Request is  to provide the reboot
> > statistics,
> > if they are available.
> >
> > There seemed to be three options to addressing this comment:
> > 2) Provide the option for the WTP to send the Reboot statistics to the
> > AC in the Join Request
> > 3) Require the WTP to send the Reboot statistics.to the AC in the Join
> > Request
> >
> > I proposed option 2, allowing the WTP to provide them if available. This
> > option
> > On 10/9/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
> > >
> > >  I personally prefer to start maintaining configuration and status
> > > state on the WTP after the join is complete. Is there a problem that arises
> > > with the current draft? Is this just a personal preference, or is there a
> > > bug?
> > >
> > >
> > > Pat Calhoun
> > >  ------------------------------
> > > *From:* Dorothy Stanley [mailto:[email-masked]]
> > > *Sent: *Friday, September 29, 2006 2:22 PM
> > > *To:* Michael Montemurro
> > > *Cc:* [email-masked]
> > > *Subject:* [Capwap] Proposed resolution to Issue 177 WTP Reboot
> > > Statisticsbelongs in the Join/was Re: A commentary on CAPWAP-01 operations
> > >
> > >  All,
> > >
> > > Issue 177, "WTP Reboot Statistics belongs in the Join"
> > > is listed below:
> > >
> > > *29) WTP Reboot Statistics belongs in the Join, and the reasons listed
> > > are not clear enough.
> > >
> > > <PRC> Doesn't really matter whether this is included in the
> > > configuration or the join, but if the WG agrees to move it. We can
> > >
> > >
> > > clarify some of the reasons, as long as it provides value.*
> > >
> > > Believing that there may be times when it is desirable for the WTP to
> > > provide
> > > information to the AC about its stability, the proposed resolution to
> > > Issue 177 is
> > > to insert the following text at the end of
> > > The following message element may be included in the Join Request
> > > message:
> > > - WTP Reboot Statistics, see Section 4.4.44.
> > >
> > > Comments please,
> > >
> > > Thanks,
> > >
> > > Dorothy
> > >
> > >
> > > On 6/30/06, Michael Montemurro <[email-masked]> wrote:
> > > >
> > > > David, Pat,
> > > >
> > > > I created issues 150-198 to deal with the points in David's email.
> > > > Happy hunting!
> > > >
> > > > Mike
> > > >
> > > >
> > > >  On 6/27/06, Pat Calhoun (pacalhou) <[email-masked] > wrote:
> > > > >
> > > > > Going through David's lengthy document, he has raised an
> > > > > interesting
> > > > > number of points that I believe require issues to be created. At
> > > > > one
> > > > > point I'm paraphrasing Dave's comments in order to be brief, and
> > > > > 1) Can message elements be in any order? (I believe they should
> > > > > be)
> > > > >
> > > > > <PRC> Yes, and I suspect we need to include text to make it more
> > > > > obvious.
> > > > >
> > > > >
> > > > > 2) Are all specified message elements required? (The obvious
> > > > > answer is
> > > > > "yes", but this document doesn't discuss versioning. For example,
> > > > > what
> > > > > if in a new version of CAPWAP an additional message element was to
> > > > > be
> > > > > added. Would a new message type be created and the additional
> > > > > message
> > > > > element added to it, or the existing type reused?)
> > > > >
> > > > > <PRC> This is a great question, and one that does need to be
> > > > > addressed
> > > > > in the spec. In the Diameter protocol we dealt with this issue by
> > > > > including a "Mandatory to implement" bit. If any AVP was received,
> > > > > whose
> > > > > bit was set, yet was not recognized, then the request had to be
> > > > > rejected.
> > > > >
> > > > > <PRC> We could consider something similar here, but I believe with
> > > > > the
> > > > > firmware download component of the protocol it may be less of an
> > > > > issue -
> > > > > although not guaranteed. I would hope (and expect) that as the
> > > > > CAPWAP
> > > > > protocol extends, the AC would push new firmware to the WTP. This
> > > > > does
> > > > > require that the initial part of the state machine be fairly
> > > > > static, and
> > > > > this could be an area where the "Mandatory to implement" bit could
> > > > > be
> > > > > useful as it would allow the AC to fall back to older protocol
> > > > > behavior.
> > > > >
> > > > > 3) CAPWAP-01 doesn't do a good job of indicating which message
> > > > > elements
> > > > > can be repeated.
> > > > >
> > > > > <PRC> Another good point. When we list the message elements, we
> > > > > should
> > > > > note whether the frequently is 0-1 (meaning absent or once), 1
> > > > > (only
> > > > > once) or 0+ (meaning any number of them could be present.
> > > > >
> > > > >
> > > > > 4) Can "additional" message elements be added to a message? (I
> > > > > believe
> > > > > so for reporting capabilities, statistics, and     events. For
> > > > > configuration, there is nothing in the protocol that says what
> > > > > happens
> > > > > when one end gets an configuration     element it doesn't know
> > > > > about.
> > > > > Should it be ignored, and the other elements processed, or should
> > > > > the
> > > > > <PRC> The "Mandatory to implement" bit above could address this
> > > > > issue.
> > > > > If an unrecognized message element is found to have the bit set,
> > > > > then
> > > > > the whole message needs to be rejected. If the bit is not set, the
> > > > >
> > > > > 5) The config has a concept of "default value" for each
> > > > > configuration
> > > > > attribute. However, the default values are not clearly specified.
> > > > > This
> > > > > needs to be resolved to be able to support "default values".
> > > > >
> > > > > <PRC> Another good point raised by David.
> > > > >
> > > > >
> > > > > 6) the documentation of which "binding specific" message elements
> > > > > are to
> > > > > be included with CAPWAP messages is not consistent, and is
> > > > > difficult to
> > > > > follow.
> > > > >
> > > > > <PRC> Has this been addressed in the latest (-02) document?
> > > > >
> > > > >
> > > > > 7) There are some message elements that cause "actions". This
> > > > > approach
> > > > > to protocol design is problematic and should be eliminated.
> > > > >
> > > > > <PRC> Could you be more specific as well as provide guidance on
> > > > > what you
> > > > > would like to see?
> > > > >
> > > > >
> > > > > 8) The message types are inconsistently named, and do not follow
> > > > > the
> > > > > conventions of well designed protocols. Can the operations be
> > > > > named
> > > > > consistently with the following terminology:
> > > > >   1) request/response (used to get/set/perform action)
> > > > >   2) report/ack (use to tell the other side something)
> > > > >
> > > > > <PRC> Could you provide your thoughts on which messages fall
> > > > > within
> > > > > 9) Many of the configuration items, and status items are not
> > > > > listed in
> > > > > one section with definitions. (Well make it two sections - one for
> > > > > CAPWAP and the other which is "binding" specific.) For example,
> > > > > not all
> > > > > of the time period lengths are identified and specified in section
> > > > > 4.5.
> > > > >
> > > > > <PRC> Unfortunately, the document has gone back and forth a few
> > > > > times
> > > > > and before we opt to change the structure of the document, I'd
> > > > > like to
> > > > > ensure that we have broad agreement on what we want - with the
> > > > > understanding that we will never make everyone happy.
> > > > >
> > > > >
> > > > > 10) each operation should have listed in which states it can be
> > > > > sent and
> > > > > received
> > > > >
> > > > > 11) All strings, such as WTP location, should be changed from
> > > > > US-ASCII
> > > > > 12) The term "mobile" is not really accurate when describing
> > > > > wireless
> > > > > interfaces, since wireless does not imply      mobile. Can we just
> > > > > use
> > > > > <PRC> I agree we should use the term Station, or STA for short.
> > > > >
> > > > >
> > > > > 13) The WTP Descriptor message element contains too much
> > > > > information,
> > > > > lacks clarity on the WTP encryption field and includes version
> > > > > numbers,
> > > > > <PRC> To the first point, I disagree. I think there is value in
> > > > > knowing
> > > > > everything about the WTP. The AC vendors can expose whatever
> > > > > information
> > > > > they want, but I don't believe anything is unnecessary.
> > > > >
> > > > > <PRC> To the second point, this is one of those areas where the
> > > > > concept
> > > > > of the technology binding creates complexity. Given that we cannot
> > > > > simply discuss 802.11i at this point, the only thing we can do is
> > > > > punt
> > > > > to another section in the technology binding section. That said, I
> > > > > agree
> > > > > with Dave that the 802.11 binding section is too light in this
> > > > > area.
> > > > > However, I would much prefer that instead of trying to address
> > > > > this
> > > > > specific issue, we discuss whether we should even be supporting
> > > > > the mode
> > > > > of operation where 802.11i is performed in the AC - especially
> > > > > with the
> > > > > introduction of DTLS to secure the data plane. Right now, it just
> > > > > feels
> > > > > like we have too many options and I am worried that
> > > > > interoperability
> > > > > will be severely impacted (not to mention protocol complexity).
> > > > >
> > > > > <PRC> To the last point, I have no issues with including text
> > > > > stating
> > > > > that the version numbers should be in string form.
> > > > >
> > > > >
> > > > > 14) The WTP Descriptor information is not required at Join time.
> > > > >
> > > > > <PRC> Well, as far as I can tell, I think there's value in knowing
> > > > > whether the WTP can even be supported by the AC. So the more info
> > > > > is
> > > > > provided by the WTP, the better the AC can determine whether it
> > > > > should
> > > > > just ignore the WTP or not. This could be done because it knows
> > > > > that the
> > > > > firmware running on the WTP is not compatible, and it has no new
> > > > > firmware to download.
> > > > >
> > > > >
> > > > > 15) Are the values in the WTP Frame Encryption a capabilities bit,
> > > > > or an
> > > > > enum?
> > > > >
> > > > > <PRC> Looks like an enum to me. Not sure what Dave would prefer
> > > > > the text
> > > > > to read. There are various other similar comments throughout,
> > > > > which I
> > > > > will not repeat here.
> > > > >
> > > > >
> > > > > 16) The Discovery Response is broken. The AC SHOULD NOT be
> > > > > providing any
> > > > > info to a WTP (or something that claims to be a WTP). Also, the AC
> > > > > should tell the WTP what to do next, with choices: 1) Ok to try to
> > > > > join,
> > > > > 2) don't try to join, 3) try                     discover on a
> > > > > list of
> > > > > returned ACs)
> > > > >
> > > > > <PRC> I don't believe there is an issue with sending the AC's
> > > > > information to the WTP, but would solicit input from the list.
> > > > > That
> > > > > said, some of the information in the AC Descriptor is required,
> > > > > such as
> > > > > the current load on the AC. No point is trying to join if he AC
> > > > > <PRC> I believe if the AC does not return the response, then it
> > > > > implies
> > > > > (2). Otherwise, it is (1). (3) is handled during the join or
> > > > > configure
> > > > > 19) The text does not make it clear that the contents of the WTP
> > > > > Location is informative only, and as Dave calls it, a
> > > > > "scratchpad".
> > > > >
> > > > > <PRC> Well, to be honest, I thought the example "next to the
> > > > > fridge"
> > > > > made it clear that the information did not derive from any
> > > > > scientific
> > > > > formula. The description also states this is a user-defined. I
> > > > > believe
> > > > > <PRC> I believe you may be correct that with the transition to
> > > > > DTLS,
> > > > > 21) need to send "common name" as found in the WTP CERT so that
> > > > > the AC
> > > > > can verify
> > > > >
> > > > > <PRC> The protocol currently relies on the MAC address being the
> > > > > key
> > > > > that binds the certificate to the WTP. I don't see a need to
> > > > > change
> > > > > this.
> > > > >
> > > > >
> > > > > 22) Result code in Join Response is not sufficient, for instance
> > > > > WTP HW
> > > > > not supported.
> > > > >
> > > > > <PRC> Well, the protocol does not require this because the
> > > > > Discovery
> > > > > Response would never be sent (as the protocol stands today).
> > > > >
> > > > >
> > > > > 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary.
> > > > >
> > > > > <PRC> Agreed.
> > > > >
> > > > >
> > > > > 24) Change Echo to Keepalive or heartbeat.
> > > > >
> > > > > 25) What if all of the message elements do not fit within a single
> > > > > CAPWAP control frame.
> > > > >
> > > > > 26) AC Name with Index is all messed up...
> > > > >
> > > > > <PRC> Not really. You simply include more than one, and the index
> > > > > field
> > > > > is clearly the priority. Don't understand the Multi-AC comment. No
> > > > >
> > > > > 27) WTP Board Data belongs in the Join, not configure.
> > > > >
> > > > > <PRC> Agreed, but wonder even more why we are duplicating this
> > > > > information across both the WTP Descriptor and the WTP Board Data
> > > > > message elements.
> > > > >
> > > > >
> > > > > 28) The WTP Static IPv4 Address should not have the Static bit,
> > > > > but
> > > > > instead state that 0.0.0.0 means a static address is not to be
> > > > > used.
> > > > >
> > > > > <PRC> I don't have an issue with this request, but in the end we
> > > > > have
> > > > > the same function. The reason why I state this is that we can
> > > > > refine
> > > > > this protocol until the cows come home, and at one point we need
> > > > > to draw
> > > > > a line in the sand.
> > > > >
> > > > >
> > > > > 29) WTP Reboot Statistics belongs in the Join, and the reasons
> > > > > listed
> > > > > are not clear enough.
> > > > >
> > > > > <PRC> Doesn't really matter whether this is included in the
> > > > > configuration or the join, but if the WG agrees to move it. We can
> > > > >
> > > > > clarify some of the reasons, as long as it provides value.
> > > > >
> > > > >
> > > > > 30) The IEEE 802.11 WTP Radio Configuration message element's
> > > > > BSSID
> > > > > 30) The IEEE 802.11 WTP Radio Configuration message element's
> > > > > Country
> > > > > <PRC> The text points to the actual MIB element in the 802.11-1999
> > > > > standard, which very clearly defines the contents of the field. I
> > > > > don't
> > > > > think there's value in replicating the format of this field in the
> > > > >
> > > > > CAPWAP standard.
> > > > >
> > > > >
> > > > > 31) There seems like an awful lot of additional configuration
> > > > > message
> > > > > <PRC> Having built a protocol based on this, it's not clear to me
> > > > > what's
> > > > > missing. I think it would be useful if you provided concrete
> > > > > details on
> > > > > what's missing.
> > > > >
> > > > >
> > > > > 32) Configuration Status is just plain broken because any
> > > > > configuration
> > > > > change operation may fail and there is no           response to
> > > > > the
> > > > > configuration changes specified in this command.
> > > > >
> > > > > <PRC> There certainly is - I guess I don't understand the concern.
> > > > >
> > > > >
> > > > > 33) Use of Change State Event should instead be Radio Admin State.
> > > > >
> > > > >
> > > > > <PRC> Perhaps the two are not described properly. The first is
> > > > > used by
> > > > > the WTP to inform the AC that something has occurred with a radio.
> > > > > The
> > > > > second is used by the AC to enable/disable a radio.
> > > > >
> > > > >
> > > > > 34) Report Timer needs to be in section 4.5 or 11
> > > > >
> > > > > <PRC> ok
> > > > >
> > > > >
> > > > > 35) Should Idle Timeout be per radio, or per WTP, and should the
> > > > > value
> > > > > <PRC> Per WTP, and yes. I believe it is fine as it is.
> > > > >
> > > > >
> > > > > 36) WTP Fallback isn't well defined, and should be removed.
> > > > >
> > > > > <PRC> Disagree. I believe it is necessary to create enough
> > > > > resiliency in
> > > > > the protocol/service.
> > > > >
> > > > >
> > > > > 37) How are the "Rate Set" and "Supported Rates" encoded.
> > > > >
> > > > > 38) AC Timestamp doesn't belong in the configuration, but instead
> > > > > in the
> > > > > join.
> > > > >
> > > > > 39) Add MAC ACL Entry - this is so strange and is being managed
> > > > > like no
> > > > > 40) Decryption Error Report Period is not defined in section 4.5or 11
> > > > >
> > > > > <PRC> ok, and note that the information has been moved to the IEEE
> > > > >
> > > > > 41) Configuration Update Response. today, there are primarily two
> > > > > types
> > > > > of configuration models. The first is when config is changed, it
> > > > > is only
> > > > > changed in the volatile copy (the memory or running). An explicit
> > > > > command is needed to save the config to nonvolatile storage. The
> > > > > second
> > > > > model has config both running (volatile) and saved (nonvolatile)
> > > > > config
> > > > > changed when a config change is made. And there might be a special
> > > > > command to have a config change apply to only one. In this case,
> > > > > there
> > > > > is no need for a "save config to nonvolatile" command. It is not
> > > > > clear
> > > > > what is suppose to be supported here in CAPWAP, and how does
> > > > > CAPWAP
> > > > > support devices with no or very limited nonvolatile storage for
> > > > > config!
> > > > >
> > > > > <PRC> CAPWAP does not support WTPs with no nonvolatile storage.
> > > > > The
> > > > > protocol has the AC push configs to the WTP, which saves them at
> > > > > the
> > > > > time they are received. I do not believe anything else is
> > > > > required.
> > > > >
> > > > >
> > > > > 42) Configuration Update Response includes the Result Code message
> > > > > element, which includes values that do not appear to be relevant
> > > > > for
> > > > > this message, and there are plenty of other failure cases
> > > > >
> > > > > <PRC> ok, but note that we are sharing a common message element.
> > > > > Any
> > > > > suggestions on how to address your issue?
> > > > >
> > > > >
> > > > > 43) Change State Event Report. This seems a little silly to be
> > > > > sent in
> > > > > the "configure" state. It seems only appropriate for the "run"
> > > > > state.
> > > > > Some might argue that even in the "run" state it shouldn't be sent
> > > > > after
> > > > > a "config update" request that changes the operational state.
> > > > > However,
> > > > > in the "run" state, it may take a while to have the operational
> > > > > state
> > > > > change to follow the admin state. Thus, I think it is OK in the
> > > > > "run"
> > > > > <PRC> I believe this was addressed in -02.
> > > > >
> > > > >
> > > > > 44) Clear Config Request. this operation has several problems,
> > > > > which
> > > > > include:
> > > > >    1) currently, the CAPWAP-01 spec says that this can only be
> > > > > done in
> > > > > the "run" state. This is silly. It should also be possible in the
> > > > > "configure" state.
> > > > > <PRC> I wonder why the AC would even consider clearing the WTP's
> > > > > state
> > > > > before it even knows how it is configured.
> > > > >
> > > > >    2) the value of "manufacturing defaults" is not defined, and a
> > > > > poor
> > > > > term to use, since it implies that that each manufacturer can have
> > > > > different values. If so, then the AC will have no knowledge of the
> > > > > config on the WTP! The problem of "default config values" has
> > > > > already be
> > > > > mentioned above. After each config attribute has been defined with
> > > > > a
> > > > > default value, then the proper term would be "CAPWAP config
> > > > > defaults".
> > > > > <PRC> Yes, you've raised this point already, and I agree that it
> > > > > does
> > > > > need to be addressed.
> > > > >
> > > > >    3) This operation is not defined to have a response. This is
> > > > > broken,
> > > > > since any config change can fail. Also, it is not defined what
> > > > > happens
> > > > > next. Does this cause the WTP to reboot an start a "clean
> > > > > discovery"?
> > > > > 45) Image Data Request. Yes, there are actually three different
> > > > > "Image
> > > > > Data Request" messages. Which one is determined          by which
> > > > > of the
> > > > > three message elements is contained. This is completely silly!
> > > > > There
> > > > > should be three separate operations! Additionally, how does the
> > > > > WTP know
> > > > > which image to get? The AC should be making that decision.
> > > > >
> > > > > <PRC> I believe the WTP is the only device that knows what it's
> > > > > filename
> > > > > should be. Why would an AC vendor know about file naming
> > > > > conventions
> > > > > used by the WTP vendors? I believe your other issues are discussed
> > > > > in
> > > > > the next items.
> > > > >
> > > > >
> > > > > 46) Image Data Response. this is silly. This operation can fail!
> > > > > There
> > > > > needs to be message element that indicates the          result.
> > > > >
> > > > > <PRC> How so? This is only used to send firmware to the WTP. Not
> > > > > clear
> > > > > what could fail... Reading the image from flash?
> > > > >
> > > > >
> > > > > 47) Image Data Request. when starting over again at the WTP start
> > > > > state,
> > > > > the WTP shouldn't use the "normal" discovery process, but instead
> > > > > "fast
> > > > > track" a connection back to the AC that just downloaded the image.
> > > > > With
> > > > > a little more          work, we could probably figure out a way to
> > > > > reuse
> > > > > the old DTLS session.
> > > > >
> > > > > <PRC> To what gain? What is so expensive about the discovery, and
> > > > > what
> > > > > happened if the AC was not longer reachable?
> > > > >
> > > > >
> > > > > 48) opcode - if this is here, might as well also have a value that
> > > > >
> > > > > indicates last block of the image file, instead of looking at the
> > > > > block
> > > > > size.
> > > > >
> > > > > <PRC> But we're just changing for the sake of changing - the
> > > > > protocol
> > > > > works as-is.
> > > > >
> > > > >
> > > > > 49) since this operation does not have the block number as a
> > > > > parameter,
> > > > > the WTP must determine the block number via the CAPWAP message
> > > > > header
> > > > > sequence number.  NOTE: DTLS does not provide in-order delivery of
> > > > > packets. Also, this requires the WTP to remember state. This
> > > > > message
> > > > > element should be re-engineered to have the following subfields:
> > > > > [edited]
> > > > >
> > > > > <PRC> The control header includes a sequence number, and while we
> > > > > can
> > > > > change the current protocol to match your recommendations, the
> > > > > protocol
> > > > > 50) Image Data Response. this is silly. This operation can
> > > > > fail!  For
> > > > > example, the WTP can run out of space to store          the block,
> > > > > or
> > > > > there could be a failure in writing the block to storage. (Or as
> > > > > "Image
> > > > > Data Request"(9.1a) is presently specified, the checksum match
> > > > > could
> > > > > fail.) There needs to be message element that indicates the
> > > > > result.)
> > > > > Note: don't need a block number field, since request and responses
> > > > > are
> > > > > paired.
> > > > >
> > > > > 51) Image Data Request. silly beyond belief
> > > > >
> > > > > <PRC> Beauty is in the eye of the beholder ;-). Seriously, the
> > > > > protocol
> > > > > does work, so what exactly are you looking for?
> > > > >
> > > > >
> > > > > 52) Image Data Response. This is silly. This operation can fail!
> > > > > There
> > > > > needs to be message element that indicates the          result.
> > > > >
> > > > > <PRC> See above comment.
> > > > >
> > > > > 53) Reset Request. ...
> > > > >
> > > > > <PRC> The comment is irrelevant now that Clear Config has changed.
> > > > >
> > > > >
> > > > > 54) Reset Response. this is silly. This operation can fail! There
> > > > > needs
> > > > > to be message element that indicates the          result.
> > > > >
> > > > > <PRC> I sense a trend. I will stop including these messages from
> > > > > now on.
> > > > >
> > > > >
> > > > > 55)Duplicate IPv4 Address. how often is this reported if the
> > > > > condition
> > > > > remains?
> > > > >
> > > > > <PRC> Only required once, I think, but we may want to include some
> > > > > text
> > > > > covering that.
> > > > >
> > > > >
> > > > > 56) the list of events seems understated!
> > > > >
> > > > > 57) Data Transfer Request. Nice to have - remove.
> > > > >
> > > > > <PRC> Disagree. Providing diagnostics capabilities is required.
> > > > >
> > > > >
> > > > > 58) Mobile Config Request. the actual details of how this works on
> > > > > both
> > > > > splitMAC and especially localMAC are not well specified. That is,
> > > > > only
> > > > > the figures and text in sections 11.1.1 and 11.1.2 provide any
> > > > > clue as
> > > > > to events that would cause an AC to send this message type. Also,
> > > > > there
> > > > > are restrictions on combinations of parameters that can be
> > > > > included in
> > > > > the message.
> > > > >
> > > > > <PRC> I wonder whether other folks agree that more details are
> > > > > required.
> > > > >
> > > > >
> > > > > 59) it doesn't say if one message can be used to update more than
> > > > > one
> > > > > STA. It should be able.
> > > > >
> > > > > <PRC> No, otherwise you end up with the problem of associating
> > > > > specific
> > > > > message elements with a given mobile. One mobile per request.
> > > > >
> > > > >
> > > > > 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included
> > > > > so
> > > > > this message element can be matched with a (4.4.8)Add Mobile
> > > > > message
> > > > > element?
> > > > >
> > > > > <PRC> I believe this is to your previous point, but the protocol
> > > > > assumes
> > > > > one mobile per request.
> > > > >
> > > > >
> > > > > 61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the
> > > > > AC? If
> > > > > so, then why is this an 802.11 message element
> > > > >
> > > > > <PRC> Intended to be a way to push policies to the WTP to
> > > > > prioritize
> > > > > mobile traffic.
> > > > >
> > > > >
> > > > > 62) IEEE 802.11 WLAN Config Request. why is a new message type
> > > > > that is
> > > > > 802.11 specific needed to modify 802.11 WLANs? It seems like the
> > > > > existing "(8.4)Configuration Update Request" message could be
> > > > > used.
> > > > >
> > > > > 63) note here there are information elements to create, delete,
> > > > > and
> > > > > modify WLANs. However, for message type "(10.1)Mobile Config
> > > > > Request",
> > > > > there is only add and delete (and the "add" used to modify).
> > > > >
> > > > > <PRC> Correct. The protocol requires the AC to resend a new add
> > > > > with a
> > > > > different policy. No specific reason, but if this is deemed
> > > > > 64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to
> > > > > BSSIDs
> > > > > <PRC> What exactly would you like to see?
> > > > >
> > > > >
> > > > > Pat Calhoun
> > > > > > From: David T. Perkins [mailto:[email-masked]]
> > > > > > Subject: [Capwap] A commentary on CAPWAP-01 operations
> > > > > >
> > > > > > HI,
> > > > > >
> > > > > > I've attached a long file that summarizes the operations in
> > > > > > CAPWAP-01.
> > > > > >
> > > > > > Enjoy,
> > > > > > /david t. perkins
> > > > > >